content wird mit http-response nicht mitgesendet

[Christian]

Hi,

Das entscheidende Merkmal eines Formulars, nämlich das form-Eement, hast du uns hier geschickt unterschlagen. Aber anscheinendhast du method="POST" und action="/index2.php" da stehen.

argh, ja habe ich vergessen, sry :/
<form method="post" action="/index2.php">

Der Content-Block wäre als reiner Hexdump wahrscheinlich informativer als mit dieser erzwungenen Unicode-Transcription.

Hier habe ich mir mal den Hexdump zurückgeben lassen vom body des 302 Responses:

Zuerst also chunked encoded data:
0000  31 61 20 0d 0a 1f 8b 08  00 00 00 00 00 00 03 02   1a ...‹. ........
0010  00 00 00 ff ff 03 00 00  00 00 00 00 00 00 00 0d   ...ÿÿ... ........
0020  0a 30 0d 0a 0d 0a                                  .0....

Dann als unchunked encoded data:
0000  1f 8b 08 00 00 00 00 00  00 03 02 00 00 00 ff ff   .‹...... ......ÿÿ
0010  03 00 00 00 00 00 00 00  00 00                     ........ ..

Unchunked decoded ist es bei mir ein leerer String.

Einen Fehler macht der Server auf jeden Fall schon: Er gibt mit dem Location-Header keine absolute URL an. Die meisten Clients kommen wohl damit zurecht, korrekt ist es aber nicht. Vermutlich eine Schlamperei des aufgerufenen PHP-Scripts.

Hmm ok. Würde es trotzdem gerne versuchen mich per PHP einzuloggen. Is natürlich ärgerlich, wenn der Server schlampt und ich dann auf mehr Dinge achten muß.

Das ist kein ASCII, das ist der zwanghafte Versuch eines Programms, gzip-codierte Daten als Unicode zu interpretieren.

Wie kann ich die Daten sonst noch sinnvoll interpretieren? Wie entnehme ich am besten den Informationsgehalt dieser Daten?

Das hat ihm der Teufel gesagt.

*gg*

Es wäre tatsächlich hochinteressant zu wissen, wo der Firefox das her hat. Vielleicht noch eine in index2.php eingebundene Ressource (iframe), die er trotz des Redirect noch pflichtbewusst anfordert?

habe nun alles nach irgendwelchen Frames durchsuchen lassen. Da finde ich nix an Frames. Ebenso keine Javascripts.

Aha. Er hat anscheinend vorher schon info.html angefordert, und irgendwas darin veranlasst ihn, jetzt auch noch head.php anzufordern. Warum ist weder der Request für info.html noch der zugehörige Response protokolliert?
Womit hast du diese HTTP-Protokolle bekommen? Die LiveHTTP-Extension für Firefox gibt wirklich nur die Header wieder, lediglich bei POST-Requests zeigt sie auch die Daten (aber AFAIR nur vom Request, nicht vom Response).

Ich habe das ganze mit den Live HTTP headers für Firefox mitprotokollieren lassen. Dann müßte dieses Programm Requests und Responses auslassen. Das kann ich schwer beurteilen. Es werden dort nur die Header angezeigt. Der Inhalt fehlt.
Stimmt, ist echt komisch, daß der Referer schon auf info.html ist.

Oder das von dir verwendete Tool hielt es nicht für nötig, diese Daten zu protokollieren.

Ich gebe den kompletten Response-String per var_dump aus. Den Response-String erhalte ich per

  
    while(!feof($fp)) {  
        $content .= fread($fp, 1025); // habe mal extra alles aneinanderhängen lassen,  
                                      // damit ich auch wirklich keine Daten beim zusammenfügen verpasse.  
    }  
    fclose($fp);  

Nein. Das muss ungefragt im Anschluss an den Header kommen.

Irgendwie kommt da nix. Ich weiß einfach nicht, was ich da falsch mache, oder was anders gemacht werden muß.

Vollständig? Keine Ahnung. Verständlich? Naja, ich verstehe weder, was dein Browser da anstellt, noch den Server ...

Ja ich will's auch verstehen, was da vor sich geht ^^

Danke wiedermal und schonmal,
Gruß,
Christian