zusätzlicher Request mit Mozilla1.3, IE5.0, NN4.78

[AlexBausW]

Hallo alle,

Ich habe Probleme mit der Kommunikation meines Mozilla1.3at auf Win98SE mit einem Webshop (auf Suse7.3 mit perl5.6.1 und Apache1.3.29 suexec) über Proxies (Webwasher3.3 -> Sambar5.2) im lokalen Netz per DSL ins WWW. (Ich hoffe das sind die Daten aller Beteiligten  :))

Wenn man eine Bestellung ausführen will, bekommt man zuerst noch mal alle Artikel angezeigt. Anschließend wird ein Formular angefordert, in das der Kunde seine Daten eintragen soll. Im Vordergrund ist der Ablauf bis dahin vollkommen in Ordnung.

Im Hintergrund lädt mir aber der Mozilla die Seite ein zweites Mal per GET-Request mit leicht verändertem Accept-Header.
Dadurch das dabei die POST-Parameter verloren gehen, wird eine neue Session erzeugt und eine Umleitung auf die angeforderte URL erzeugt, die mit einer Fehlermeldung wegen nicht übertragener Parameter antwortet. Die Antwort landet aber anscheinend im Datennirwana, da die geladene Kundendatenformularseite nicht ersetz und auch kein neues Fenster mit der neuen Seite geladen wird.

In einer früheren Version hatte ich auf der ersten Seite des Bestellvorgangs ein Formular, daß per GET die nächste Seite anforderte. Bei dem zusätzlichen Request "hing" sich dann aber der Prozess des CGI-Programms bei Ausgabe des Formulars (für die Kundendaten) so auf, daß ziemlich genau fünf Minuten lang kein weiterer CGI-Prozess gestartet werden konnte (wobei der hängende Prozess aber keinerlei CPU- bzw Memory-Last verursachte und auch keine Fehlermeldung ausgab). Unter anderen Domains (die auf dem selben Server anderen Kunden/Usern zugeordnet sind) konnten aber weiterhin CGI-Programme aufgerufen werden.

Das lässt mich zu der Vermutung kommen, dass suexec hier weitere CGI-Prozesse für den entsprechenden User unterbunden hat, bzw. keine weiteren Prozess starten konnte (Mit dem genauen Zusammenspiel zwischen Apache, Perl und suexec kenne ich mich leider nicht genauer aus).

Mit der LiveHeaders-Funktion in meinem Mozilla habe ich folgenden HTTP-Dialog aufgezeichnet:

=========================================================

http://www.genealogie-shop.de/cgi-bin/order.cgi

POST http://www.genealogie-shop.de/cgi-bin/order.cgi HTTP/1.0
Host: www.genealogie-shop.de
User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.3) Gecko/20030312
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: de,de-at;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close
Proxy-Connection: close
Referer: http://www.genealogie-shop.de/cgi-bin/order.cgi?action=list&sid=1075992158xfWL9JJ30187
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
action=udat&sid=1075992158xfWL9JJ30187

HTTP/1.x 200 OK
Date: Thu, 05 Feb 2004 15:50:37 GMT
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.6l PHP/4.3.4
Content-Type: text/html; charset=iso-8859-1
Proxy-Connection: Close
Connection: Close
----------------------------------------------------------
http://www.genealogie-shop.de/cgi-bin/order.cgi#

GET http://www.genealogie-shop.de/cgi-bin/order.cgi HTTP/1.0
Host: www.genealogie-shop.de
User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.3) Gecko/20030312
Accept: video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: de,de-at;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close
Proxy-Connection: close
Referer: http://www.genealogie-shop.de/cgi-bin/order.cgi

HTTP/1.x 302 Found
Date: Thu, 05 Feb 2004 15:50:39 GMT
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.6l PHP/4.3.4
Location: http://www.genealogie-shop.de:80/cgi-bin/order.cgi?sid=1075996239j04iJDe4248
Content-Type: text/html; charset=iso-8859-1
Proxy-Connection: Close
Connection: Close
----------------------------------------------------------
http://www.genealogie-shop.de/cgi-bin/order.cgi?sid=1075996239j04iJDe4248

GET http://www.genealogie-shop.de/cgi-bin/order.cgi?sid=1075996239j04iJDe4248 HTTP/1.0
Host: www.genealogie-shop.de:80
User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.3) Gecko/20030312
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: de,de-at;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close
Proxy-Connection: close
Referer: http://www.genealogie-shop.de/cgi-bin/order.cgi

HTTP/1.x 200 OK
Date: Thu, 05 Feb 2004 15:50:39 GMT
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.6l PHP/4.3.4
Content-Type: text/html; charset=iso-8859-1
Proxy-Connection: Close
Connection: Close

============================================================

Außer Opera7.11/Win32 zeigen dieses Verhalten auch noch IE5 und NN4 mit und ohne zwischengeschalteten WebWasher. :( Also liegt es vielleicht doch an irgendetwas, was man abschalten könnte *hoff*). Kennt jemand dieses Phänomen, oder kann es irgendwie aus der Kommunikation ableiten? Beschreibt irgendeine RFC das Verhalten (es machen schließlich NN4 und IE5 auch), die ich mir unbedingt durchlesen sollte, deren Nummer ich aber nicht kenne?

Kleine wichtige Zusatzinformation: In einer früheren Version arbeitete der Shop mit CSV-Dateien als Datenbank (übrigens schnell und reibungslos ;). Jetzt wo die Problem auftauchen, ist MySQL das DBMS, welches die Daten liefert. Aber ich vermute den Verursacher woanders, weis aber nicht wo.

Gruß Alex

[AlexBausW]

Hallo Ich,

Hoffentlich stehe ich nicht bei so vielen Stammpostern auf der Blacklist, daß mich keiner liest. ;)

[unerwünschter doppelter HTTP-Request]

Außer Opera7.11/Win32 zeigen dieses Verhalten auch noch IE5 und NN4 mit und ohne zwischengeschalteten WebWasher.

Hmmm, ich glaube das klingt missverständlich. Ich meinte eigentlich, alle mir zur Verfügung stehenden Browser außer Opera und Lynx (Lynx verwendet keine Proxies) zeigen hier dieses Phänomen.

Vielleicht kann jemand obiges bestätigen. Wenn dieses Verhalten nicht reproduziert werden kann, wäre mir auch schon geholfen. Dann müsste ich

Testen kann man das mit einem HTTP-sniffer unter http://www.genealogie-shop.de/. Einfach einen Artikel in den Warenkorb legen, den Bestellvorgang durchführen und nach dem Kundendatenformular wieder zurück zur Startseite gehen (wer dringend etwas benötigt, kann natürlich auch etwas bestellen. :) Dies soll aber _keine_Werbung_ sein).

Gruß Alex

[AlexBausW]

Hallo Ich,

[unerwünschter doppelter HTTP-Request]

Da hätte ich auch früher drauf kommen können/müssen.

1. Request:
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1

2. Request:
Accept: video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1

Durch langes (eher langsames) Überlegen bin ich darauf gekommen, daß die Browser im zweiten Request vielleicht wirklich ein Bild anfordern wollen (womit das im Lynx von vorneherein nicht funktionieren kann), welches die selbe URL wie das zuerst angeforderte Dokument hat. Das erklärt schon mal den geänderten Accept-Header. (Da hättet ihr aber auch mit Leichtigkeit selbst drauf kommen können *tststs* ;-))

Und tatsächlich habe ich in den entsprechenden Templates zum Kundendatenformular eine Platzhaltergrafik gefunden, die einfach "#" - also http://...../order.cgi# - referenziert (das dokumentiert auch das LiveHTTPHeaders-Plugin, von mir allerdings unbeachtet). Das erklärt auch, wohin die gesendeten  Daten "verschwunden" sind (Etheral hätte mir sicherlich mehr verraten  :).

Opera merkt sich anscheinend, daß unter der selben URL bereits ein Dokument vom Typ text/html ausgeliefert wurde und holt dies entweder aus dem Cache oder erst gar nicht vom Server ab, da ja bei einem zweiten Request kein Bild von dort zu erwarten ist.

Davon ausgehend, daß die Templates bereits vor der Umstellung auf die andere Datenhaltung verwendet wurden, bedeutet dies, daß auch früher schon "doppelte" Requests abgesetzt wurden. Aber leider erklärt es noch nicht, wieso sich Apache/suexec/order.cgi in der Datenbankversion "aufhängen", nicht aber in der CSV-Version. Zumal der Hänger exakt bei der Ausgabe des Templates passiert, wo nur "print $content;" steht.

Ausgabe eines Timestamps direkt davor erfolgt sofort, und die Ausgabe eines Timestamps direkt nach der Anweisung erfolgt im Abstand von 5min. Content-Type und der obere Teil der HTML-"Seite" sind bis dahin schon längst ausgegeben und sollte dank "$|=1;" auch ausgeliefert worden sein (auch hier hätte mir Etheral sicherlich mehr gesagt, aber das habe ich dank LiveHTTPHeaders geglaubt nicht zu benötigen - was für das eigentliche Problem ja auch zutrifft). Könnte der Apache trotzdem vielleicht den Accept-Header mit dem generierten Content-Type vergleichen und deshalb die Ausgabe irgendwie behindern? Hat irgendjemand eine Idee? Weis irgendjemand etwas genaues?

Da jetzt aber zumindest der Shop wieder so funginiert wie er soll, werde ich dieser durchaus interressanten Frage mal in einer ruhigen Minute (und davon habe ich in nächster Zeit nur noch welche für dringende Angelegenheiten und das Forum ;) versuchen auf den Grund zu gehen (das sollte ich ja - jetzt wo ich weis wie es geht - auch bei mir kneipe und ausleine reproduzieren können :)).

Gruß Al*sichgeradeziemlichentbloedethabend*ex

[Christian Kruse]

Hallo Alex,

Davon ausgehend, daß die Templates bereits vor der Umstellung auf die
andere Datenhaltung verwendet wurden, bedeutet dies, daß auch früher schon
"doppelte" Requests abgesetzt wurden. Aber leider erklärt es noch nicht, wieso
sich Apache/suexec/order.cgi in der Datenbankversion "aufhängen", nicht aber
in der CSV-Version. Zumal der Hänger exakt bei der Ausgabe des Templates
passiert, wo nur "print $content;" steht.

Wie gross ist denn der Inhalt von $content? Und ist zu der Zeit sicher die
Erzeugung des Contents bereits geschehen?

Könnte der Apache trotzdem vielleicht den Accept-Header mit dem
generierten Content-Type vergleichen und deshalb die Ausgabe
irgendwie behindern?

Nein, eigentlich eher nicht. Zumindest in meiner Test-Installation auf
dem Server nicht. Hast du schonmal suEXEC mit --with-suexec-logfile kompiliert?
Was sagt das Error-Log?

Grüße,
 CK