Problem: $_POST und $_SESSION manchmal leer...

[Esben Smid]

Hallo Leute,

wir haben ein PHP generiertes HTML-Formular laufen, dass sich nach Vervollständigen selbst aufruft, eine neues Formular darstellt und sich wieder selbst aufruft und so weiter (method="POST").

Gelegentlich scheitert aber die Übertragung des Query-Strings, sowohl $_GET als auch $_POST als auch die $_SESSION sind dann vollständig leer. Drückt man auf AKTUALISIEREN im Browser (IE6), klappt es meist, manchmal muss man zweimal aktualisieren.
Zuerst dachte ich, das Formular wäre fehlerhaft (z.B. fehlendes </form>-Tag), dem ist aber nicht so. Es scheint eher, als würde der PHP Parser sich "verschlucken".

Ganz selten passiert noch was anderes, ich weiß nicht, ob das mit dem $_POST-Problem zusammenhängt: Das Formular wird dann nur teilweise ausgegeben, mittendrin bricht die Ausgabe ab.

Beide Probleme traten auf zwei unterschiedlich konfigurierten CONFIXX/LINUX/APACHE Servern auf, auf WIN/APACHE besteht das Problem nicht.

Hat jemand eine Idee?
Dank im Voraus und Grüße,
Esben

[srob]

Gelegentlich scheitert aber die Übertragung des Query-Strings, sowohl $_GET als auch $_POST als auch die $_SESSION sind dann vollständig leer. Drückt man auf AKTUALISIEREN im Browser (IE6), klappt es meist, manchmal muss man zweimal aktualisieren.

Hallo Esben,

dieses Phänomen kenne ich auch. Leider kann ich weder Ursache noch Lösungsansatz bieten. Meine bisherigen Beobachtung hinsichtlich der Symptome:

Das Verhalten ist stochastisch; manchmal kann man das Formular zweidutzendmal durchnudeln, bis der Effekt auftritt, manchmal schon beim ersten Absenden des Formulars. So weit ich feststellen kann, tritt es ausschließlich beim IE (5.0/5.5/6.0 auf 2000/XP) auf. Mit Mozilla, Netscape und Operas bin ich nicht in der Lage, es zu reproduzieren. Allerdings habe ich Feedbacks von Nutzern, die beim Abrufen einer servergenerierten PDF (Übergabe einer Vereinsnummer via POST) ein leeres Dokument mit einer auf die gescheiterte POST-Übergabe hinweisenden Fehlermeldung erhalten; davon ist einer mit Netscape 7.0/XP.

hth Robert

[Andreas Korthaus]

Hallo!

Gelegentlich scheitert aber die Übertragung des Query-Strings, sowohl $_GET als auch $_POST als auch die $_SESSION sind dann vollständig leer. Drückt man auf AKTUALISIEREN im Browser (IE6), klappt es meist, manchmal muss man zweimal aktualisieren.

Ich weiß nicht ob ich dasselbe Problem habe, jedenfalls hatte ich diese Woche andauernd ein sehr peinliches Problem, nämlich dass man aus dem Login-Bereich rausgeflogen ist - einfach so. Und zwar kommt es nicht zu einer Konstellation dass der User ausgeloggt wird, sondern auf einmal wird die Session-ID nicht übergeben, der User bekommt eine (leere) neue, und schwups ist er draußen. Das hatte ich bisher noch nie, und nur jetzt auf einmal mit IE (6). Leider hatte ich keine Gelegenheit das Problem einzukreisen, es ist auch nicht reproduzierbar. Mal tritt es hier auf, mal da, mal geht es 100 Requests gut, mal passiert es jeden 2.
Die Session, die der User gehabt hat, die ist noch da und liegt unverändert im /tmp - Verzeichnis, aber das bringt mir natürlich herzlich wenig. Ich würde vermuten dass der IE hier und da mal Cookies unterschlägt, obwohl ich das eigentlich nicht glauben kann, es kann ja auch ein Problem mit PHP oder Apache sein.
Ich werde jetzt erstmal Ethereal anschmeißen und beten dass das Problem reproduzierbar ist ;-)

Grüße
Andreas

[srob]

Hallo Andreas,

Ich weiß nicht ob ich dasselbe Problem habe, jedenfalls hatte ich diese Woche andauernd ein sehr peinliches Problem, nämlich dass man aus dem Login-Bereich rausgeflogen ist - einfach so.

Ja, das geht in denselben Bereich, so etwas habe ich auch gelegentlich... "Peinlich" ist ein treffender Ausdruck; dazu paßt, daß in den PHP-Bug-Reports der Status der meisten Reports bezüglich verlorener POST- und SESSION-Variablen lautet:

bogus

Da fühle ich mich doch richtig ernstgenommen!

hth Robert

[Andreas Korthaus]

Hi!

Ja, das geht in denselben Bereich, so etwas habe ich auch gelegentlich... "Peinlich" ist ein treffender Ausdruck; dazu paßt, daß in den PHP-Bug-Reports der Status der meisten Reports bezüglich verlorener POST- und SESSION-Variablen lautet:

bogus

Da fühle ich mich doch richtig ernstgenommen!

Bist Du denn sicher dass es an PHP liegt? Hast Du z.B. den IE als Fehlerquelle ausschließen können? Und auch Deine Scripte? Soweit bin ich leider noch nicht ;-)
Beim IE hatte ich letztens nämlich ziemlich blöde Probleme, so hat er z.B. nur die Hälfte des Quelltextes einer gzip-Komprimierten Seite gelesen und auch nur die Hälfte angezeigt, die Quelltext-Ansicht im IE hörte dann apprupt bei <tr>... auf. Und das trat nur bei einem bestimmten IE (5) mit irgend nem SP auf...

Grüße
Andreas

[srob]

Hallo Andreas!

Bist Du denn sicher dass es an PHP liegt? Hast Du z.B. den IE als Fehlerquelle ausschließen können? Und auch Deine Scripte? Soweit bin ich leider noch nicht ;-)

Nein, ich denke nicht an PHP als Problemzone. In den Bug Reports habe ich nachgesehen, um Hinweise auf die mögliche Ursache zu finden. Ich habe die Browser im Verdacht; problematisch ist allerdings die mangelnde Reproduzierbarkeit[1] und die Tatsache, daß - zumindest außerhalb meines Büros - anscheinend nicht nur der IE betroffen ist. Meine Script-Programmierung würde ich niemals pauschal ausschließen, allerdings meine ich bei relativ simplen, selbstaufrufenden Formularen die Abläufe einigermaßen im Griff zu haben; ein weiteres Argument ist die insgesamt hohe Stabilität der Interpretation (manchmal hundert Durchläufe ohne Problem, dann Peng!).

hth Robert

[1] Was ich im ersten Posting zu erwähnen vergaß: gelegentlich lösen sich nur die POST-Variablen in Luft auf, während $_SESSION noch existent ist. Das hat dazu geführt, daß ich zur Erhöhung der Stabilität an manchen Stellen kritische Daten per POST und per SESSION weitertransportiere. Und wenn ich mit solchen Frickeleien anfangen muß, fühle ich mich nicht sehr wohl in meiner Haut...

[Tom]

Hello,

Bau Dir mal ein separates Testscript mit, dass mit getallheaders() den Request-Header ausgibt. http://de3.php.net/manual/de/function.getallheaders.php
Es könnte an einem Formatproblem des IE6 liegen.

Welche Argumente hat der <Form>-Tag? Du solltest auf jeden Fall den enctype="multipart/form-data" vorschreiben. Der IE6 macht da nämlich manchmal was er will und PHP kann das Environment fürs Script dann nicht zusammenbauen.

Testscript:

<?php  ### headerlist.php ###

/* setcookie() will add a response header on its own */
setcookie('foo', 'bar');

/* Define a custom response header
   This will be ignored by most clients */

header("X-Sample-Test: foo");

/* Specify plain text content in our response */

header('Content-type: text/plain');

echo "<pre>";
/* What headers are going to be sent? */
if(function_exists("headers_list"))
{
  print_r(headers_list());
}
elseif(function_exists("apache_response_headers"))
{
  print_r(apache_response_headers());
}
else
{
  echo "\nkeine Header-Listing-Funktion verfügbar\n";
}
echo "</pre>";

?>

Liebe Grüße aus http://www.braunschweig.de

Tom

[srob]

Hallo Tom,

danke für Deine Hinweise! Im Augenblick fehlt mir die Zeit, mich damit zu beschäftigen...

Welche Argumente hat der <Form>-Tag? Du solltest auf jeden Fall den enctype="multipart/form-data" vorschreiben.

Meine Form-Elemente sehen in der Regel so aus:

<form id="frmArtEdit" enctype="multipart/form-data" method="post" action="artedit_art.php">

Ich habe aus Neugierde mal schnell über das betroffene Projekt drübergegrept und 37 Scripte mit Formularen gefunden; zu meinem Erstaunen habe ich nicht überall ein Argument "enctype", ich bin nicht sicher, ob sich diese Scripte mit den problembehafteten decken. Das werde ich mir wohl noch mal vorknöpfen!

hth Robert

[Harry]

Holladiewaldfee,

<form id="frmArtEdit" enctype="multipart/form-data" method="post" action="artedit_art.php">

Die Sau ist grob gesagt der enctype. Der Effekt tritt erst ab 4.2.0 auf, nachdem die Behandlung von $_POST neu in PHP implementiert wurde. Ich habe damals zu den ersten gehört, die den Bug entdeckt und gemeldet haben.

Ergebnis: Viel rumgewurschtel im Bugreport, irgendwann als "fixed" markiert, aber Pustekuchen, Bug immer noch (wenn auch seltener) aufgetreten, meine Bitte auf Wiederöffnung des Bugreports in den Wind geblasen.

Gerüchteweise habe ich auch gehört, daß der Fehler (in selteneren Fällen) auf ohne den extra Enctype auftritt, einmal meine ich sogar es selbt beobachtet zu haben. Damals bin ich aus einem Login-Bereich der allereinfachsten Sorte rausgeflogen - selbst nach dreimaliger Überprüfung habe ich keinen Fehler gefunden, der das hätte hervorrufen können, nur der Verlust von $_SESSION ...

Na gut, wie gesagt, der $_POST-Bug ist als "fixed" markiert, geistert aber immer noch ab und zu durch die Welt. Interessant ist, daß vor allem der IE besonders stark davon betroffen zu sein scheint, allerdings haben ich und andere das Verhalten auch schon bei Mozilla (keine Ahnung mehr, welche Version das damals war) und Opera beobachtet, wenn auch deutlich seltener.

Daß darüberhinaus keine (komplett funktionellen) Workarounds existieren macht die Sache _extrem_ ärgerlich. Die zur Schau gestellte Arroganz und Ignoranz der PHP-Entwickler setzt dem ganzen die Krone auf und macht PHP summa sumarum für den betroffenen Einsatzbereich untauglich. Traurig, aber wahr.

Ciao,

Harry
 PS: In den "Anfangszeiten" dieses Bugs ist von fünf IE-Requests vielleicht einer durchgekommen ...

[Andreas Korthaus]

Hallo!

<form id="frmArtEdit" enctype="multipart/form-data" method="post" action="artedit_art.php">

Die Sau ist grob gesagt der enctype. Der Effekt tritt erst ab 4.2.0 auf,

Ah, welcher ist denn genau falsch, und welcher richtig, und wieso habe ich das bisher ausschließlich auf einem System mit winXP und IE6 beobachtet? Wir hatten 2 Laptops, beide WinXP mit IE6-SP1, beide gingen an einen DSL-Router ganz normal ins Netz, und hatten plötzlich Probleme wie ich sie noch nie vorher erlebt hatte. Ich habe mir den Betroffenen Code 100 mal durchgesehen, ich habe den weitestgehend vereinfacht... und der Server lief schon seit Monaten so und nicht anders durch, ist aber erst wie gesagt in den letzten 3 Tagen aufgefallen (sonst arbeite ich auch nicht mit WinXP oder IE), aber auch sonst ist es niemandem aufgefallen vorher. Daher hatte ich irgendwie die Befürchtung das irgendwas auf dem Server volläuft - aber was? Was etwas ärgerlich ist, der Server wurde heute Nacht für eine geplante Wartung runtergefahren und neu gestartet. Möglicherweise wurden hierdurch irgendwelche Voraussetzungen verändert.

nachdem die Behandlung von $_POST neu in PHP implementiert wurde.

Hm. Bin mir gar nicht sicher dass es nur bei POST passiert. Ich habe auch noch eine Rewrite-Rule des Apachen dazuwischen, hm ist wirklich schwierig.

Ich habe damals zu den ersten gehört, die den Bug entdeckt und gemeldet haben.

Du bist Dir ganz sicher dass es sich hier um einen PHP-Bug handelt? Tritt das mit allen Browsern auf? Hast Du mal mit Ethereal geguckt ob der Browser auch alles richtig macht? Leider ist meine Architektur etwas komplexer, so dass ich nicht ohne weiteres sagen könnte was sich da genau abgespielt hat, dazu müsste ich mir die HTTP-Header ansehen - was allerdings zur Zeit nicht klappt da nicht reproduzierbar.

Ergebnis: Viel rumgewurschtel im Bugreport, irgendwann als "fixed" markiert, aber Pustekuchen, Bug immer noch (wenn auch seltener) aufgetreten, meine Bitte auf Wiederöffnung des Bugreports in den Wind geblasen.

Hm, ist halt die Frage ob es wirklich ein PHP-Bug ist. Ich meine, wenn es ein Fehler in PHP ist, dann müsste sich dieses Fehlverhalten doch reproduzieren lassen, und das schaffe ich z.B. nicht. Gestern habe ich es sicher 50 mal geschafft - ungewollt...
Wenn ich halt 100% denselben Request an den Server schicke, dann muss der Server ja eigentlich auch 100% dasselbe damit machen, oder? Ich würde als erstes gerne mal sehen, ob man den Client komplett ausschließen kann, das heißt - Verhalten reproduzieren, während Ethereal eingeschaltet ist, und die Pakete genaz genau ansehen. Wenn das OK ist, kann man auf dem Server gucken, das heißt gewisse Dinge loggen, vor allem bestimmte Umgebungs-Variablen, Header, Zeitpunkt...
Dann weiß man - kommen die Daten vielleicht gar nicht bis ins Script? Vielleicht ein Problem mit der Server-Schnittstelle?...

Gerüchteweise habe ich auch gehört, daß der Fehler (in selteneren Fällen) auf ohne den extra Enctype auftritt, einmal meine ich sogar es selbt beobachtet zu haben.

Also sicher bin ich da nicht, ich bin mir nichtmal sicher ob es nur in Formularen auftritt, das wollte ich alles heute "erforschen", und schon klappt wieder alles wie geschmiert...
enctype verwende ich des öfteren, weil ich öfter Dateien hochlade.

Damals bin ich aus einem Login-Bereich der allereinfachsten Sorte rausgeflogen - selbst nach dreimaliger Überprüfung habe ich keinen Fehler gefunden, der das hätte hervorrufen können, nur der Verlust von $_SESSION ...

Mein Problem ist: Ich bin eingeloggt, mache schöne Sachen mit der Session, schreibe dies und das da rein, und auf einmal, kann die Session-ID nicht zugeordnet werden, und ich bekomme eine neue, und schon fliege ich raus, und kann auf meine alte Session nicht mehr zugreifen. Die ist natürlich noch existent, aber ich habe ja jetzt eine neue Session-ID...

Na gut, wie gesagt, der $_POST-Bug ist als "fixed" markiert, geistert aber immer noch ab und zu durch die Welt. Interessant ist, daß vor allem der IE besonders stark davon betroffen zu sein scheint, allerdings haben ich und andere das Verhalten auch schon bei Mozilla (keine Ahnung mehr, welche Version das damals war) und Opera beobachtet, wenn auch deutlich seltener.

Hat niemand mal "HTTP-Mitschnitte" von der Kommunikation (http://www.ethereal.com/download.html), oder hat jemand einen Tipp wie man den Fehler besonders zuverlässig reproduzieren kann?

Daß darüberhinaus keine (komplett funktionellen) Workarounds existieren macht die Sache _extrem_ ärgerlich. Die zur Schau gestellte Arroganz und Ignoranz der PHP-Entwickler setzt dem ganzen die Krone auf und macht PHP summa sumarum für den betroffenen Einsatzbereich untauglich. Traurig, aber wahr.

Die Entwickler haben ständig mit Problemen anderer Leute zu tun, die gar nichts mit PHP zu tun haben, da kann sowas schonmal passieren. Und solange man den Bug nicht leichter reproduzieren kann wird es auch sehr, sehr schwer diesen zu beheben.

Viele Grüße
Andreas

[Harry]

Holladiewaldfee,

Die Sau ist grob gesagt der enctype. Der Effekt tritt erst ab 4.2.0 auf,
Ah, welcher ist denn genau falsch, und welcher richtig, und wieso habe ich das bisher ausschließlich auf einem System mit winXP und IE6 beobachtet?

Meine Beobachtungen waren: Alle Browser, Win98, Win2k, WinXP, FreeBSD 4.4, 4.6. Da ich danach mit der Seite nicht mehr weitergearbeitet habe weiß ich nicht, wie sich's bei anderen Versionen verhält, ich tippe aber ähnlich. Allerdings muß ich eingestehen daß der Server immer ein Apache war und ich kann auch nicht mehr sagen, ob ein 2er Apache dabei war, ich glaube aber schon.

http://bugs.php.net/bug.php?id=17958 war damals einer der Bug-Reports, wo es um diesen Bug ging. Da gab's aber noch mehr ...

Das Script mit dem ich den Fehler damals hatte (ob er heute noch auftritt weiß ich nicht, muß ich mal wieder ausprobieren), ließ sich wirklich bis auf das absolute Grundgerüst runter vereinfachen:

--
<html>
<head><title>TEST</title></head>
<body>
<?php vardump($_POST); ?>
<form action="<?= $_SERVER['PHP_SELF'] ?>" method="post" enctype="multipart/form-data">
<input type="hidden" name="blahr" value="x">
<input type="submit" value="ok">
</form>
</body>
</html>
--

Wichtig war nur, daß der enctype dabei war.
$_POST war öfter mal leer. Als ich damals probehalber ein Downgrade auf 4.1.x gemacht hab lief die Sache wieder ohne Probleme.

Irgendjemand hatte damals auch versucht das mit Ethereal durchzuziehen, und wenn ich mich recht erinnere hat der Browser die Daten halbwegs korrket abgeschickt (müßte auch noch der eine oder andere Thread im Archiv rumgammeln, gab's damals ein oder zwei dazu).

nachdem die Behandlung von $_POST neu in PHP implementiert wurde.
Hm. Bin mir gar nicht sicher dass es nur bei POST passiert. Ich habe auch noch eine Rewrite-Rule des Apachen dazuwischen, hm ist wirklich schwierig.

Ich hatte keine dazwischen. Und wie gesagt, obiger Code ist extrem einfach ...

Ich habe damals zu den ersten gehört, die den Bug entdeckt und gemeldet haben.
Du bist Dir ganz sicher dass es sich hier um einen PHP-Bug handelt?

Oder Apache im Zusammenspiel mit der neuen PHP-Version, also im Endeffekt doch PHP.

Tritt das mit allen Browsern auf?

Ja, allerdings mit dem IE deutlich häufiger als mit den anderen - was mich auch etwas stutzig macht.

Hast Du mal mit Ethereal geguckt ob der Browser auch alles richtig macht?

Ne.

Leider ist meine Architektur etwas komplexer, so dass ich nicht ohne weiteres sagen könnte was sich da genau abgespielt hat, dazu müsste ich mir die HTTP-Header ansehen - was allerdings zur Zeit nicht klappt da nicht reproduzierbar.

Meine war damals auch sehr komplex, da ging es um ein CM-System. Aber Du kannst ja mal bei Dir probieren, was obiger Code anrichtet. Und - das Ergebnis ist wirklich nicht immer reproduzierbar.

Hm, ist halt die Frage ob es wirklich ein PHP-Bug ist. Ich meine, wenn es ein Fehler in PHP ist, dann müsste sich dieses Fehlverhalten doch reproduzieren lassen, und das schaffe ich z.B. nicht. Gestern habe ich es sicher 50 mal geschafft - ungewollt...

Die Probleme fingen bei fast allen mit 4.2.0 an ... da hegt man schon irgendwie den Verdacht, daß PHP daran nicht ganz unbeteiligt ist.

Wenn ich halt 100% denselben Request an den Server schicke, dann muss der Server ja eigentlich auch 100% dasselbe damit machen, oder?

Das ist genau das, was einen Haufen Leute aus der Bahn geworfen hat - mich eingeschlossen. Nimm mal obiges Formular und hau ein paar mal hintereinander auf Submit - bei mir war es damals so, daß - je nach Browser - mal "x" dastand und mal halt nicht.

Dann weiß man - kommen die Daten vielleicht gar nicht bis ins Script? Vielleicht ein Problem mit der Server-Schnittstelle?...

Das ist auch meine Theorie, daß mit 4.2.0 irgendwas an der Schnittstelle geändert wurde, daß irgendwie zeitkritisch ist. Allerdings kenne ich mich da zu wenig mit den Interna aus, um das beurteilen zu können.

Ciao,

Harry

[Andreas Korthaus]

Hi!

Das ist auch meine Theorie, daß mit 4.2.0 irgendwas an der Schnittstelle geändert wurde, daß irgendwie zeitkritisch ist. Allerdings kenne ich mich da zu wenig mit den Interna aus, um das beurteilen zu können.

Danke für die Hinweise, eigentlich muss das ja zu beheben sein...

Grüße
Andreas

[e7]

Hi,

Bist Du denn sicher dass es an PHP liegt? Hast Du z.B. den IE als Fehlerquelle ausschließen können? Und auch Deine Scripte? Soweit bin ich leider noch nicht ;-)
Beim IE hatte ich letztens nämlich ziemlich blöde Probleme, so hat er z.B. nur die Hälfte des Quelltextes einer gzip-Komprimierten Seite

Ich nehme auch an, dass das am IE liegt. War mal vor ein paar Monaten an einem Rechner (Win2000, IE6), bei dem ging das Posten hier im SelfHTML-Forum nicht - und das wird denke ich mal HTML-Konform sein. Dann musste ich den Post meistens zwei oder dreimal abschicken, dass auch Daten übermittelt wurden...

E7

[Esben Smid]

Klingt, als hätten wir alle das selbe Problem.
Wir haben es schon seit Monaten, wobei wir erst jetzt durch Zufall festgestellt haben, dass auch die $_POST und nicht nur die $_SESSION leer ist, vorher dachten wir an ein Session-Problem und konnten ebenfalls nirgends Hilfe bekommen. Mit Cookies hat es wohl nichts zu tun, die benutzen wir mittlerweile nicht mehr...

Wir lösen das Problem im Moment durch einen automatischen Reload, wenn keine POST-Vars da sind, schön ist das aber nicht, weil der User den Reload einer POST-Übertragung ja bestätigen muss.

Grüße: Esben

[Andreas Korthaus]

Hallo!

Klingt, als hätten wir alle das selbe Problem.

Naja, mit POST hatte ich bisher keine schwierigkeiten, und habe es bisher nach ca. 200 Versuchen nicht wieder geschafft das Problem (welches in den letzten 3 Tagen grob geschätzt 100 mal aufgetreten ist) zu reproduzieren. Ich kann mich auf den Kopf stellen, jetzt wo ich in Ruhe testen kann funktioniert alles prima, selber Browser, software unverändert... man, man, man. Einziger Unterschied, diesmal auf einem Rechner mit Win2000 anstatt WinXP. Aber dann werde ich wohl gleich auf dem Laptop testen...

Was mir aufgefallen ist - PHP sendet in jedem Response-Header nochmal extra den aktuellen Session-Cookie, aber gut - daran sollte es nicht liegen.

Was genau verwendet Ihr für Versionen?

Serverseitig: Linux 2.4, Apache 1.3.29, mod_php 4.3.5
Clientseitig: Windows XP-SP1, IE6-SP1

Nicht reproduzieren konte ich es bisher unter
Windows 2000-SP4, IE6-SP1
Windows 2000-SP4, Firefox 0.8
Windows XP-SP1, Firefox 0.8
Linux 2.4, Firefox 0.8

Das hießt hier ist es bisher nie aufgetreten.

Wir haben es schon seit Monaten, wobei wir erst jetzt durch Zufall festgestellt haben, dass auch die $_POST und nicht nur die $_SESSION leer ist, vorher dachten wir an ein Session-Problem und konnten ebenfalls nirgends Hilfe bekommen.

Also POST hatte ich noch kein Problem. Das Problem wird sehr ärgerlich wenn man in Sessions ein paar Daten speichert, die man vorhger mühsam eingegeben hat - auf einmal ist die Zuordnung zur Session aus irgendeinem Grund nicht mehr möglich, und das würde ich mir gerne mal auf HTTP-Ebene ansehen, aber dazu muss ich es erstmal wieder reproduziert bekommen...

Mit Cookies hat es wohl nichts zu tun, die benutzen wir mittlerweile nicht mehr...

Hm. Hast Du Dir mal angesehen was genau auf HTTP-Ebene passiert wenn es dazu kommt? Das wäre mal sehr hilfreich zu wissen, weil dies Rückschlüsse erlaubt ob es jetzt überhaupt ein Client- oder ein Server-Problem ist, denn hier bin ich mir nicht wirklich sicher.

Ich kann nur dringend empfehlen Ethereal zu installieren, ist kein Problem (zumindest wenn der Rechner über eine Netzwerkkarte angebunden ist): http://www.ethereal.com/download.html

Damit kann man genau sehen: Was sendet der IE, und was andwortet der Apache.

Wir lösen das Problem im Moment durch einen automatischen Reload, wenn keine POST-Vars da sind, schön ist das aber nicht, weil der User den Reload einer POST-Übertragung ja bestätigen muss.

Nein, wirklich nicht.

Grüße
Andreas

[Tom]

Hello,

Was mir aufgefallen ist - PHP sendet in jedem Response-Header nochmal extra den aktuellen Session-Cookie, aber gut - daran sollte es nicht liegen.

Und hast Du die Sessionnummern mal verglichen? Sind die identisch?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Andreas Korthaus]

Hi Tom!

Was mir aufgefallen ist - PHP sendet in jedem Response-Header nochmal extra den aktuellen Session-Cookie, aber gut - daran sollte es nicht liegen.

Und hast Du die Sessionnummern mal verglichen?

Ja

Sind die identisch?

Nein.

Im Augenblick stehe ich wirklich etwas ratlos davor...
Wenn ich es doch wenigstens reproduzieren könnte.

Grüße
Anrdeas

[Andreas Korthaus]

Hi Tom!

Sind die identisch?
Nein.

äm, sind natürlich identisch wollte ich sagen ;-)

Grüße
Andreas