AlexBausW: Erledigt (*argl*), aber neue Frage

Beitrag lesen

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

--
>> Dass in eine if Schleife zu packen schafft mein 10 jähriges Patenkind. [...]
> Mhhh, wenn man if in Schleifen packt, muss man sich auch nicht wundern, wenn die Patenkinder verwöhnte Luder werden. [...]
[TomIRL und Tom in ?t=64084&m=364291]
ss:) zu:} ls:} fo:| de:[ va:| ch:| sh:( n4:& rl:° br:& js:| ie:| fl:| mo:}