IE6 vergisst manchmal Cookies zu senden...

[Andreas Korthaus]

Hallo

Kürzlich haben ja einige Leute ähnliche Probleme beschrieben, nämlich dass in PHP-Scripten hin und wieder $_POST und $_SESSION leer sind:
http://forum.de.selfhtml.org/archiv/2004/5/80821/

Und zwar habe ich ein Session-basiertes Login, und auf Rechnern mit einem bestimmten Browser/OS werde ich ständig ausgeloggt, und das kein Stück reproduzierbar, wenn ich dieselben Klicks nach denen ich einmal rausgeflogen bin wiederhole, passiert vielleicht gar nichts, oder ich fliege schon mittendrin raus. Mal geht es 100 Klicks gut, mal nur 2.

Jetzt habe ich nochmal den Rechner genommen, auf dem mir das Problem   aufgefallen war. Hierbei handelt es sich um ein Notebook mit WinXP Professional SP1 + IE6 SP1 (Auf einem anderen System, ebenfalls mit IE6 SP1, nur WinXP Home, passiert dasselbe. Auf Win2000 konnte ich es bisher komischerweise nicht provozieren).

Um das Problem eingrenzen zu können habe ich auf dem Rechner Ethereal (http://www.ethereal.com/download.html) installiert, um zu verfolgen, wie sich IE und Apache unterhalten. Dadurch konnte ich sehen _wieso_ ich ausgeloggt wurde. Und zwar sollte der IE eigentlich bei jedem Request den Session-Cookie mitsenden, macht manchmal aber eben nicht - ohne ersichtlichen Grund. Wenn PHP keine Session-ID erhält, fliege ich natürlich raus - klar! Gut, aber woran kann das liegen? Wie gesagt lässt sich das Problem nicht wirklich eng einkreisen, da nicht reproduzierbar, aber ich kann es besonders provozieren.

Ich muss in sehr vielen Formularen

ectype="multipart/form-data"

verwenden, daher kann ich nicht wirklich sagen ob es hiermit zusammenhängt. Dazu kommt, dass ich des öfteren per Javascript Popups öffne, in denen die Session ebenfalls gelten soll. Das Problem tritt meist in diesem Zusammenhang auf. Ich öffen ein Popup, und auf einmal sendet der IE keinen Cookie mit dem entsprechenden HTTP-Request. Öffne ich beim nächsten "Reproduktions-Versuch" exakt dieses Popup über denselben Klick nochmal, funktioniert auf einmal alles, und auch umgekehrt passiert sowas. Ich kann es dann 10 mal probieren und es geht jedes mal. Wenn ich oft genug Popups öffne und Formulare abschicke... dann ist es nur eine Frage der Zeit bis es wieder passiert. Aber wann und wo ist überhaupt nicht vorhersehbar.

Aber es passiert auch folgendes:

Manchmal öffne ich ein Popup, und schicke das Formular im Opener-Fenster gleichzeitig ab, damit die evtl. eingegebenen Daten nicht aus Versehen verloren gehen. Das geht auch zig mal gut, aber manchmal - ohne ersichtlichen Grund, fliege ich hier aus beiden Fenstern raus! Das heißt, sowohl beim GET-Request zum Öffnen des Popups, als auch beim POST-Request zum Speichern der Formulardaten im Opener-Fenster, wird der Session-Cookie nicht mitgesendet, gleichzeitig!

Es hat in jedem Fall irgendwas mit den als Popup geöffneten Fenstern zu tun.

Dass allerdings POST-Daten verloren gehen habe ich bisher nicht mitbekommen. Diese werden immer mitgeschickt bei mir. Ob die auch ankommen habe ich bisher nicht kontrolliert, aber ich hatte diesbezüglich bisher keine Probleme. Das Problem liegt definitiv beim IE im Zusammenhang mit Fenstern und Cookies. Natürlich könnte ich jetzt in alle Javascripte die Session-ID in die Links einbauen, aber eigentlich wollte ich mich auf Cookies verlassen, weil ich die gerade für Session-IDs für nahezu ideal halte. Das kann ich dann aber wohl leider vergessen...

Ich überlege mir auch schon fieberhaft Alternativen, aber die einzige Idee die ich hätte ist die Verwendung der SSL-Session ID als Session-ID für PHP, aber dann läuft die Software ja definitiv nur noch über SSL, was natürlich im produktiv-Betrieb der Fall sein wird, aber zum Testen... mal sehen. Habt Ihr vielleicht noch eine Idee?

Oder kennt jemand das Problem und weiß vielleicht sogar wie man es beheben kann? Das Problem trat bisher wirklich nur mit dieser einen Browser-OS Kombination auf. Sehr seltsam...

Mit dem IE stehe ich eh auf Kriegsfuß, denn netterweise hat der IE5 SP4 ein kleines Problem mit gzip-Komprimierung. Das klappt _eigentlich_ wunderbar, aber ich hatte eine einzige Seite, wo er reproduzierbar immer eine leere Seite ausgegeben hat, die Quelltext-Ansicht zeigte, dass nur die 1. Hälfte des Quelltextes vorhanden war, es hört irgendwo recht unmotiviert und ohne irgendwelchen kritischen Code in der Nähe nach einem <td> einfach auf, und meldete einen unbekannten Fehler.

Schalte ich die gzip-Komprimierung ab, funktioniert alles wunderbar.
Komprimierung lasse ich durch PHP durchführen, und zwar per php.ini Eintrag:

zlib.output_compression = On

Viele Grüße
Andreas

[Tom]

Hello,

nochmal mein Tipp:

schau Dir wirklich auf dem Server die gesendeten Header an.

getallheaders() http://de3.php.net/manual/de/function.getallheaders.php

hilft dabei. Lass die Header doch mal eine weile loggen.

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

Tom

[Andreas Korthaus]

Hallo!

nochmal mein Tipp:

schau Dir wirklich auf dem Server die gesendeten Header an.

getallheaders() http://de3.php.net/manual/de/function.getallheaders.php

hilft dabei. Lass die Header doch mal eine weile loggen.

Aber was soll das bringen? Ich habe sämtliche Header auf HTTP Ebene mit Ethereal mitgeloggt. Das Problem ist, dass der IE hin und wieder ohne ersichtlichen Grund den Session-Cookie nicht mitsendet. Was soll ich da serverseitig noch großartig herausbekommen? Ich sehe ja auch die Header die der Server gesendet hat. Aber darin finde ich nichts besonderes.
Worauf sollte ich denn Deiner Meinung nach achten? Die einzige mir bekannte Möglichkeit serverseitig zu verhindern dass der Client einen Cookie sendet, besteht darin, per set-cookie dem Client denselben Cookie mit Ablaufdatum in der Vergangenheit zu schicken. Sowas passiert aber nicht. Es wird zwar jedesmal per set-cookie ein Cookie gesetzt, aber ohne Ablaufzeitpunkt, also sollte solange das Fenster geöffnet bleibt, der Cookie immer mitgesendet werden - macht der auch meist, nur eben manchmal nicht, wodurch der Server einen neuen Cookie setzt, und ich so aus der Session fliege.
Die alte Session befindet sich natürlich noch im /tmp Verzeichnis, aber das bringt mir nichts wenn der Browser ja jetzt einen neuen Cookie sendet, den PHP dannmit einer anderen, leeren Session assoziiert.

Zu Ethereal habe ich im übrigen größeres Vertrauen als zu getallheaders() ;-)

Worauf spielst Du hier an? Welche Informationen könnte mit getallheaders() bringen, was ein kompletter Dump der TCP und HTTP Pakete per Ethereal nicht könnte?

Grüße
Andreas

[Tom]

Hello,

sind denn für die Session auch DOMAIN und PATH angegeben worden?
Ich erinnere mich an so ein Problem bei meinem CMS, ganz am Anfang, als wir noch experimentiert haben. Da gabs auch Probleme mit der Namensauflösung (lokale Hosts contra Mini-DNS vom Server) Immer, wenn nicht über Cache zugegriffen wurde, gabs auch den entfernten DNS-Zugriff und dann gabs Knoten.

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

Tom

[Andreas Korthaus]

Hi Tom!

sind denn für die Session auch DOMAIN und PATH angegeben worden?

Sind alles Default-Einstellungen, z.B.:

Set-Cookie: sid=4c747ff6999008f6001790004677c665; path=/

Ich erinnere mich an so ein Problem bei meinem CMS, ganz am Anfang, als wir noch experimentiert haben. Da gabs auch Probleme mit der Namensauflösung (lokale Hosts contra Mini-DNS vom Server) Immer, wenn nicht über Cache zugegriffen wurde, gabs auch den entfernten DNS-Zugriff und dann gabs Knoten.

Nein, es lag exakt an diesem Problem: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q300895

Grüße
Andeas

[Philipp Hasenfratz]

Halihallo Andreas

[...]
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q300895
http://support.microsoft.com/default.aspx?scid=kb;EN-US;185978
  (jedoch IE<5)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;323752
  (Tipp: Versuch es mal mit P3P, das ist zwar theoretisch keine
   Lösung, aber Praktisch liesse sich der IE vielleicht austricksen)

Was steht bei dir in Extras-Internetoptionen-Datenschutz-Erweitert?
Vielleicht testweise die automatische Cookiebehandlung ausschalten
und erneut versuchen (obgleich dies natürlich keine kundentaugliche
Lösung wäre...).

Wenn ich du wäre, würde ich es mal mit einem P3P-Header versuchen.
Das wäre zumindest für den Kunden eine super Lösung, denn damit hat
er nix zu tun ;-)
Ein "normales Problem" ist es ja nicht, also kann man auch nicht mit
einer "normalen Lösung" rechnen. Man muss den IE irgendwie
austricksen...

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q300895

Naja, die Anforderungen dort müssen bei mir alle nicht gegeben sein. Im IE5.x habe ich es auch noch nicht beobachtet...

http://support.microsoft.com/default.aspx?scid=kb;EN-US;185978
  (jedoch IE<5)

Wenn das nur um diese Versionen ging wär mir das erheblich lieber ;-)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;323752
  (Tipp: Versuch es mal mit P3P, das ist zwar theoretisch keine
   Lösung, aber Praktisch liesse sich der IE vielleicht austricksen)

"The P3P standard notes that if a FRAMESET or a parent window references another site inside a FRAME or inside a child window, the child site is considered third party content. "

Ah, da scheinen wir der Sache näher zu kommen... aber wenn dem so wäre müsste es ja eigentlich reproduzierbar sein - was es nicht ist. ABer vielleicht gibt es da ja einn Bug in der Implementierung, ich werde es mir in jedem Fall mal näher ansehen.

Was steht bei dir in Extras-Internetoptionen-Datenschutz-Erweitert?
Vielleicht testweise die automatische Cookiebehandlung ausschalten
und erneut versuchen (obgleich dies natürlich keine kundentaugliche
Lösung wäre...).

Hm, hab mal alles auf akzeptieren gesetzt, und Session Cookies immer akzeptieren, bringt nix, fliege trotzdem raus. In diesem Fall sogar ohne Javascript und ohne extra Fenster. Ich hab erst ein bisschen rumklicken müssen, mit Popups... hat alles geklappt, am Ende war nur noch das ursprüngliche Fenster auf, ich klicke auf einen Link und: "bitte einloggen". Das allerkomischste an der Sache, ich hatte an einem Windows2000 (SP4) PC mit ebenfalls IE6 SP1 (wobei ich gerade nicht 100%ig sicher bin ob auch SP1, aber ich denke schon) versucht den Fehler erneut auszulösen - und ich habe es auch nach einigen 100 Versuchen nicht geschafft. Ich habe es noch nie mit Mozilla geschafft, und auch sonst nicht. Nur mit 2 Notebooks, beide WinXP SP1 und IE SP1. Und damit passiert das teilweise ständig. Und wie ich jetzt gesehen habe senden diese zwischendurch einfach den Cookie nicht mit, auch nicht zur eigentlichen Seite, muss nicht immer ein Popup sein, ich habe nur das Gefühl dass Popups das Problem verstärken. Aber das sind alles Mutmaßungen, das Problem ist eben nicht wirklich 1:1 reproduzierbar.

Wenn ich du wäre, würde ich es mal mit einem P3P-Header versuchen.
Das wäre zumindest für den Kunden eine super Lösung, denn damit hat
er nix zu tun ;-)
Ein "normales Problem" ist es ja nicht, also kann man auch nicht mit
einer "normalen Lösung" rechnen. Man muss den IE irgendwie
austricksen...

Davon habe ich zwar keine Ahnung, aber wenn das denn was bringen könnte, ich werde es in jedem Fall mal versuchen. Danke Dir!

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

http://support.microsoft.com/default.aspx?scid=kb;EN-US;323752
  (Tipp: Versuch es mal mit P3P, das ist zwar theoretisch keine
   Lösung, aber Praktisch liesse sich der IE vielleicht austricksen)

"The P3P standard notes that if a FRAMESET or a parent window references another site inside a FRAME or inside a child window, the child site is considered third party content. "

Ah, da scheinen wir der Sache näher zu kommen... aber wenn dem so wäre müsste es ja eigentlich reproduzierbar sein - was es nicht ist. ABer vielleicht gibt es da ja einn Bug in der Implementierung, ich werde es mir in jedem Fall mal näher ansehen.

Ich gehe davon aus, dass es ein Bug in der Implementierung ist,
genau deswegen mein Rat, es mit verschiedenen (praktischen, nicht
jedoch theoretischen) Lösungsansätzen zu versuchen. Das Problem
dürfte kein Problem sein, zumal es in anderen Browsern nicht
reproduzierbar ist und eigentlich formal korrekt ist (wenn ich es
denn richtig und komplett verstanden habe).
Ich denke nicht, dass es ein Problem mit P3P ist, ansonsten müsste es
auch auf den neuen NS reproduzierbar sein. Ich könnte mir jedoch
vorstellen, dass die normale Cookiebehandlung im IE durch eine
P3P-Cookie-Behandlung ersetzt wird, welche ggf. "besser"
funktioniert. Ich denke, es wäre einfach ein Versuch wert, vielleicht
liesse sich das Problem dadurch lösen (obwohl es theoretisch wie
gesagt eingentlich gar nichts oder nur bedingt damit zu tun hat).

Hm, hab mal alles auf akzeptieren gesetzt, und Session Cookies immer akzeptieren, bringt nix, fliege trotzdem raus. In diesem Fall sogar ohne Javascript und ohne extra Fenster. Ich hab erst ein bisschen rumklicken müssen, mit Popups... hat alles geklappt, am Ende war nur noch das ursprüngliche Fenster auf, ich klicke auf einen Link und: "bitte einloggen". Das allerkomischste an der Sache, ich hatte an einem Windows2000 (SP4) PC mit ebenfalls IE6 SP1 (wobei ich gerade nicht 100%ig sicher bin ob auch SP1, aber ich denke schon) versucht den Fehler erneut auszulösen - und ich habe es auch nach einigen 100 Versuchen nicht geschafft.

Hm. Also alles gleich (auch IE Version und SP), bis auf das OS?
Lässt sich dieses Problem auch auf einem komplett gleich
installierten Rechner (gleiches OS, gleicher IE) reproduzieren?

Gibt es vielleicht einen einfachen Code, den du posten könntest,
sodass wir anderen es bei uns testen können?

Wenn ich du wäre, würde ich es mal mit einem P3P-Header versuchen.
Das wäre zumindest für den Kunden eine super Lösung, denn damit hat
er nix zu tun ;-)
Ein "normales Problem" ist es ja nicht, also kann man auch nicht mit
einer "normalen Lösung" rechnen. Man muss den IE irgendwie
austricksen...
Davon habe ich zwar keine Ahnung, aber wenn das denn was bringen könnte, ich werde es in jedem Fall mal versuchen. Danke Dir!

Ein Versuch ist es sicher Wert ;-)

Vorschläge:
 - Was ist mit normalen Cookies (über setcookie())
   Teste mal einige Varianten: Session-Cookie, Expires-Time, ...
 - Du verwendest kein Programm, dass die Systemzeit periodisch
   ändert, oder? - Dies könnte dazu führen, dass die Cookies zu früh,
   zu spät gelöscht werden und würde zu den unreproduzierbaren
   Phänomenen führen.
 - Sieh dir mal die Cookie-Datei in Temporary Internet Files an.
   Bleibt die bestehen, oder wurde sie aus unerfindlichen Gründen
   gelöscht?
   Hm. Habe ich interessenshalber gleich bei mir versucht. Ich sehe
   gar keinen Cookie (werden wohl im RAM behalten), was bei Session-
   Cookies ja auch Sinn macht.
 - Du sendest nicht mehr als 20 Cookies pro Domain?
   Vielleicht legt der IE die Schranke auch kleiner oder höher an...
 - Kommst du an die Schranke von 300 Cookies insgesamt? - Trotzdem
   sollte auch dann kein Problem entstehen, da immer die neusten
   gespeichert werden (sollten).

Naja, ich schreibe einfach, was mir dazu in den Sinn kommt,
konstruktiv kann ich aber nix beitragen, leider.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

Ich denke nicht, dass es ein Problem mit P3P ist, ansonsten müsste es
auch auf den neuen NS reproduzierbar sein. Ich könnte mir jedoch
vorstellen, dass die normale Cookiebehandlung im IE durch eine
P3P-Cookie-Behandlung ersetzt wird, welche ggf. "besser"
funktioniert. Ich denke, es wäre einfach ein Versuch wert, vielleicht
liesse sich das Problem dadurch lösen (obwohl es theoretisch wie
gesagt eingentlich gar nichts oder nur bedingt damit zu tun hat).

Hm, ich klammere mich ja an jeden Strohhalm ;-)
Nur habe ich mit P3P bisher nix zu tun gehabt, muss mich da erstmal informieren wie so ein Header dann im Detail aussehen muss...

Hm. Also alles gleich (auch IE Version und SP), bis auf das OS?
Lässt sich dieses Problem auch auf einem komplett gleich
installierten Rechner (gleiches OS, gleicher IE) reproduzieren?

Ja, auf 2 Notebooks, das sind die einzigen Rechner mit WinXP mit denen ich es probiert habe, ich arbeite sonst nicht mit WinXP. Bei beiden passiert das ständig, beide wurden von 2 verschiedenen Leuten ganz unabhängig und erst vor kurzer Zeit installiert, das eine Notebook von mir, da ist so ziemlich nichts drauf. Schon gar keine Tools die da irgendwie reinfummeln könnten. Keine Firewall oder sowas...

Das große Problem ist einfach, dass man es nicht 1:1 reproduzieren kann, dann wäre ich schon einen großen Schritt weiter.

Gibt es vielleicht einen einfachen Code, den du posten könntest,
sodass wir anderen es bei uns testen können?

Hm, wenn sich das Problem nicht irgendwie lösen lässt werde ich mich mal hinsetzen und den Code so weit es geht vereinfachen, zur Zeit ist das leider nicht möglich.

Vorschläge:

• Was ist mit normalen Cookies (über setcookie())
     Teste mal einige Varianten: Session-Cookie, Expires-Time, ...

ja, mache ich mal

• Du verwendest kein Programm, dass die Systemzeit periodisch
     ändert, oder? - Dies könnte dazu führen, dass die Cookies zu früh,
     zu spät gelöscht werden und würde zu den unreproduzierbaren
     Phänomenen führen.

nein, sicherlich nicht. Außerdem sollte das auf Session-Cookies keinen Einfluss haben, da hier ja kein Ablauf-Zeitpunkt definiert wird. Die Cookies werden ja nur im RAM gehalten und beim Schließen des Fensters gelöscht. Ich hatte schonmal dran gedacht, dass der IE unter bestimmten Umständen beim Schließen des Popups den Cookie aus dem RAM löscht, so dass das Opener-Fenster diesen nicht mehr senden kann. Aber das konnte ich bisher nicht verifizieren.

• Du sendest nicht mehr als 20 Cookies pro Domain?
     Vielleicht legt der IE die Schranke auch kleiner oder höher an...

nein, nur diesen einen.

• Kommst du an die Schranke von 300 Cookies insgesamt? - Trotzdem
     sollte auch dann kein Problem entstehen, da immer die neusten
     gespeichert werden (sollten).

hm, kann ich mir kaum vorstellen. Er sendet den einen Cookie ja zig mal, und auf einmal nicht mehr, und speichert dann auch sofort wieder den neuen, denn PHP in diesem Fall setzt.

Naja, ich schreibe einfach, was mir dazu in den Sinn kommt,
konstruktiv kann ich aber nix beitragen, leider.

Sicher ist das konstruktiv, denn ich tappe im Moment total im Dunkeln und bin Dir für Deine Ideen sehr dankbar!

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Ich denke nicht, dass es ein Problem mit P3P ist, ansonsten müsste es
auch auf den neuen NS reproduzierbar sein. Ich könnte mir jedoch
vorstellen, dass die normale Cookiebehandlung im IE durch eine
P3P-Cookie-Behandlung ersetzt wird, welche ggf. "besser"
funktioniert. Ich denke, es wäre einfach ein Versuch wert, vielleicht
liesse sich das Problem dadurch lösen (obwohl es theoretisch wie
gesagt eingentlich gar nichts oder nur bedingt damit zu tun hat).
Hm, ich klammere mich ja an jeden Strohhalm ;-)
Nur habe ich mit P3P bisher nix zu tun gehabt, muss mich da erstmal informieren wie so ein Header dann im Detail aussehen muss...

header("P3P: CP="NOI DEVa TAIa OUR BUS UNI"");
header("Set-Cookie: test=value; path=/;");

Versuch es einfach mal damit, das sollte funktionieren. Oder mit dem
in der MSDN-Seite vorgeschlagenen P3P: CP="CAO PSA OUR".

Das große Problem ist einfach, dass man es nicht 1:1 reproduzieren kann, dann wäre ich schon einen großen Schritt weiter.

Natürlich, denn dann wäre es ein "normales Problem" und somit im
Normalfall "normal" zu lösen :-)

• Du verwendest kein Programm, dass die Systemzeit periodisch
     ändert, oder? - Dies könnte dazu führen, dass die Cookies zu früh,
     zu spät gelöscht werden und würde zu den unreproduzierbaren
     Phänomenen führen.
  nein, sicherlich nicht. Außerdem sollte das auf Session-Cookies keinen Einfluss haben, da hier ja kein Ablauf-Zeitpunkt definiert wird.

Wer weiss ;-)
Aber natürlich, "normalerweise" nicht... Normalerweise sollte dieses Problem aber auch nicht existieren :-)
Zudem sind ja Session-Cookies in PHP nicht zwingend Browsersitzungs-
Cookies, ist jedoch IMHO per Default so eingestellt.

Die Cookies werden ja nur im RAM gehalten und beim Schließen des Fensters gelöscht. Ich hatte schonmal dran gedacht, dass der IE unter bestimmten Umständen beim Schließen des Popups den Cookie aus dem RAM löscht, so dass das Opener-Fenster diesen nicht mehr senden kann. Aber das konnte ich bisher nicht verifizieren.

Richtig, das wäre theoretisch auch eine mögliche Ursache, praktisch
scheint ist es mir noch nie aufgetreten und das ist ja auch richtig
und gut so.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

header("P3P: CP="NOI DEVa TAIa OUR BUS UNI"");
header("Set-Cookie: test=value; path=/;");

Versuch es einfach mal damit, das sollte funktionieren. Oder mit dem
in der MSDN-Seite vorgeschlagenen P3P: CP="CAO PSA OUR".

Vielen Dank, ich werde es gleich testen!

Das große Problem ist einfach, dass man es nicht 1:1 reproduzieren kann, dann wäre ich schon einen großen Schritt weiter.

Natürlich, denn dann wäre es ein "normales Problem" und somit im
Normalfall "normal" zu lösen :-)

Ich schaffe es jetzt doch das Problem 1:1 zu reproduzieren. Man braucht nur 2 Clicks. Mit einem öffne ich ein Popup (Javascript), in diesem Fall sendet der IE den Cookie an den Server. Dann schließe ich das Popup, und ab da sendet der IE den Cookie nicht mehr, egal was ich mache. Da ich zuvor das Popup oft im Hintergrund weiter offen hatte, und es nur unter bestimmten Bedingungen automatisch geschlossen wurde, habe ich das erst jetzt zufällig bemerkt.

Ich öffen das Popup wie folgt:

<input type="button" onclick="window.open('/popup.php','popup-name','width=400,height=450,scrollbars=yes')" value="popup-link">

Ich bastele gleich mal ein Stück Code woran ich das zeigen/weiter testen kann, da ich mir nicht vorstellen kann dass dieses Problem unter allen Umständen auftritt.

• Du verwendest kein Programm, dass die Systemzeit periodisch
     ändert, oder? - Dies könnte dazu führen, dass die Cookies zu früh,
     zu spät gelöscht werden und würde zu den unreproduzierbaren
     Phänomenen führen.
  nein, sicherlich nicht. Außerdem sollte das auf Session-Cookies keinen Einfluss haben, da hier ja kein Ablauf-Zeitpunkt definiert wird.

Wer weiss ;-)
Aber natürlich, "normalerweise" nicht... Normalerweise sollte dieses Problem aber auch nicht existieren :-)

"Normalerweise" gehört der IE verboten ;-)
Man sollte mal eine Studie machen über den volkswirtschaftlichen Schaden den IE und OE so anrichten...

Zudem sind ja Session-Cookies in PHP nicht zwingend Browsersitzungs-
Cookies, ist jedoch IMHO per Default so eingestellt.

Ja, bei mir ist es jedenfalls so. Anders macht es in den meisten Fällen auch wenig Sinn, IMHO.

Die Cookies werden ja nur im RAM gehalten und beim Schließen des Fensters gelöscht. Ich hatte schonmal dran gedacht, dass der IE unter bestimmten Umständen beim Schließen des Popups den Cookie aus dem RAM löscht, so dass das Opener-Fenster diesen nicht mehr senden kann. Aber das konnte ich bisher nicht verifizieren.

Richtig, das wäre theoretisch auch eine mögliche Ursache, praktisch
scheint ist es mir noch nie aufgetreten und das ist ja auch richtig
und gut so.

Es scheint aber wirklich was hiermit zu tun zu haben. Ist jetzt die Frage ob es immer so ist, oder ob es in meinem Fall irgendeinen besonderen Umstand gibt der dieses Fehlverhalten hervorruft.

Ich werde das Testen und berichten... ;-)

*ich liebe das Gefühl wenn man dem Ziel merklich näher kommt* ;-)

Viele Grüße
Andreas

[Andreas Korthaus]

Hi Philipp!

Ich schaffe es jetzt doch das Problem 1:1 zu reproduzieren.

So, jetzt habe ich es endgültig. Es hat mit einem der von Dir zuvor verlinkten Probleme zu tun: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q300895

Das heißt, das Problem taucht in der Tat nur dann auf, wenn man über eine HTML- Datei im lokalen Dateisystem, die Software Online per Link öffnet. Genau das haben wir gemacht, für Präsentations-Zwecke haben wir ein paar Links in eine HTML-Datei geschrieben, die lokal liegt und direkt auf verschiedene Adressen auf dem Server verweist. Das erklärt auch warum ich es nur auf den Rechnern reproduzieren kann ;-)

Die Datei sieht z.B. so aus:

home.html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>test</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<a href="http://knet-systems.de/tmp/ie-test.php">popup-test</a>
<br>
</body>
</html>

Wenn man die z.B. als Startseite auf dem lokalen Rechner festlegt, und dann auf den Link klickt, merkt man, wenn man auf den Link klickt und dort das Popup öffnet und wieder schließt, dass beim erneuten Öffnen eine andere Session-ID im Popup erscheint.

Das Beispiel ist so weit vereinfacht wie möglich, z.B. hängt PHP beim ersten Request sicherheitshalber auch an alle Links die Session-ID an, was bei Javascript natürlich nicht funktioniert. Wenn man aber das Dokument vorher aktualisiert ist die Session-ID nicht mehr an die Links gehängt, und wenn man danach entsprechend das Popup öffnet und schließt, kann man sehen, dass auch im Opener die Session-ID verloren geht, wenn man dann auf den Link klickt. (sorry, ist etwas verwirrend formuliert, ist aber auch ein blödes Problem ;-))

Also letztendlich tritt dieses Problem nur in einer _sehr_ außergewöhnlichen Situation auf, ich denke das habe ich mir jetzt ganz gut eingeprägt ;-)

Ich werde dann wohl alles so lassen wie es ist, denn eigentlich funktioniert es ja wunderbar. Immer wieder nett wie lange man für so eine dämliche Erkenntnis brauchen kann... Hätte ich das vorher gewusst hätte ich mir einige sehr peinliche Vorstellungen erspart ;-)

In jedem Fall vielen Dank!

Es war Dein erster Link der mich letztendlich auf diese abstruse Idee brachte ;-)

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

So, jetzt habe ich es endgültig. Es hat mit einem der von Dir zuvor verlinkten Probleme zu tun: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q300895

*argh*
Lags daran... Du hast recht, der IE gehört "normalerweise"
verboten.

Das heißt, das Problem taucht in der Tat nur dann auf, wenn man über eine HTML- Datei im lokalen Dateisystem, die Software Online per Link öffnet. Genau das haben wir gemacht, für Präsentations-Zwecke haben wir ein paar Links in eine HTML-Datei geschrieben, die lokal liegt und direkt auf verschiedene Adressen auf dem Server verweist. Das erklärt auch warum ich es nur auf den Rechnern reproduzieren kann ;-)

Ärger dich jetzt bloss nicht darüber, im Nachhinein ist bekanntlich
alles immer sonnenklar ;-)

Die Datei sieht z.B. so aus:

Jep. Ist auch bei mir reproduzierbar: IE6+WinXP.

In jedem Fall vielen Dank!
Es war Dein erster Link der mich letztendlich auf diese abstruse Idee brachte ;-)

Es freut mich, dass ich trotz meiner Unkenntnis dennoch etwas
zur Lösung beitragen konnte :-)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi!

So, jetzt habe ich es endgültig. Es hat mit einem der von Dir zuvor verlinkten Probleme zu tun: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q300895

*argh*
Lags daran...

Und erst jetzt, beim 2. Lesen sehe ich die Zusammenhänge und dass alles 1:1 passt. Aber da musste ich wohl erstmal drauf kommen, das hörte sich beim 1. Lesen alles so unwahrscheinlich an... ;-)

Du hast recht, der IE gehört "normalerweise"
verboten.

;-)

Ärger dich jetzt bloss nicht darüber, im Nachhinein ist bekanntlich
alles immer sonnenklar ;-)

Tja, was mich am meisten ärgert sind die blöden Zufälle, ich stand teilweise vor meiner eigenen Software und wusste nicht mehr was ich noch dazu sagen sollte, denn wenn man gerade was mit Popups zeigen will und dann da weiter macht wo man zuvor rausgeflogen ist, fliegt man natürlich wieder raus... peinlich sag ich Dir... und am Ende lag es nichtmal an mir, sondern am blöden IE...

Die Datei sieht z.B. so aus:

Jep. Ist auch bei mir reproduzierbar: IE6+WinXP.

Hm, die Datei würde ich an Deiner Stelle nicht als Startseite lassen ;-)

Es freut mich, dass ich trotz meiner Unkenntnis dennoch etwas
zur Lösung beitragen konnte :-)

"beitragen" ist gut, Du hast mir die Lösung in Deiner 2. Zeile auf dem Silbertablett präsentiert, aber ich hab etwas gebraucht bis ich da durchgeblickt habe ;-)

Grüße
Andreas