content wird mit http-response nicht mitgesendet

[Christian]

Hallo alle,
ich komme hier einfach nicht weiter und wäre über Vorschläge, Überlegungen, oder Erklärungen wirklich äußerst glücklich. Ich versuche ein kleines PHP-Skript zu schreiben, das sich mittels HTTP auf einer Internetseite anmelden kann und Daten abrufen kann. Ähnlich wie eine Art Proxy.

Zum Verständnis habe ich mich mit Firefox und laufenden Live HTTP Headers auf der Seite eingeloggt, um zu sehen, ob Firefox die gleichen Requests schickt, wie ich es manuell durchführe.

Bis zu folgendem Response schicken Firefox und mein Skript das gleiche:

HTTP/1.1 302 Found\r\n
Date: Mon, 24 Nov 2008 21:09:01 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
X-Powered-By: PHP/4.3.10\r\n
Set-Cookie: name=deleted; expires=Sun, 25-Nov-2007 21:09:00 GMT; path=/\r\n
Set-Cookie: sessionid=deleted; expires=Sun, 25-Nov-2007 21:09:00 GMT; path=/\r\n
Expires: Mon, 26 Jul 1997 05:00:00 GMT\r\n
Last-Modified: Mon, 24 Nov 2008 21:09:01 GMT\r\n
Cache-Control: post-check=0, pre-check=0\r\n
Pragma: no-cache\r\n
Set-Cookie: name=34485; expires=Mon, 24-Nov-2008 21:44:01 GMT; path=/\r\n
Set-Cookie: sessionid=a601b21fea9f31fdc2f306c5cd2a4a43; expires=Mon, 24-Nov-2008 21:44:01 GMT; path=/\r\n
Location: info.html\r\n
Content-Encoding: gzip\r\n
Vary: Accept-Encoding\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n
1a\r\n

0\r\n
\r\n

Diesen Content habe ich mit hexdec und gzinflate entschlüsselt und er war leer. (falls ich da nichts falsch gemacht habe.)

Der Browser schickt nun einen GET-Request an die URI /head.php?showmus=1

Wo im gegebenen Response liest der Browser diese URI ab?? Ich finde sie nicht.

Mein Request richtete sich also nach der angegebenen Location: info.html

Geschickt hatte ich folgenden Request:

GET /info.html HTTP/1.1\r\n
Host: ...\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Cookie: name=34485; sessionid=a601b21fea9f31fdc2f306c5cd2a4a43\r\n
\r\n

Die Response vom Server sieht dann so aus:

HTTP/1.1 200 OK\r\n
Date: Mon, 24 Nov 2008 21:09:13 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
Last-Modified: Thu, 22 May 2008 12:34:51 GMT\r\n
ETag: "f0e84-1dd-4835686b"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 477\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html\r\n
\r\n

Die Content-Length ist 477, aber ich erhalte dann keinen "Content". Muß man den irgendwie manuell abfragen?

Was mache ich da nur falsch?

Wäre super, wenn mir jemand weiterhelfen könnte.

Vielen Dank schon einmal :)

[ChrisB]

Hi,

Bis zu folgendem Response schicken Firefox und mein Skript das gleiche:

HTTP/1.1 302 Found\r\n
...
Location: info.html\r\n

Der Browser schickt nun einen GET-Request an die URI /head.php?showmus=1

Dazu hat er, zumindest wenn er obigen Response empfangen hat, aus HTTP-Sicht keinen Grund.

Wo im gegebenen Response liest der Browser diese URI ab?? Ich finde sie nicht.

Sie steht auch nicht in den HTTP-Headern.
Vielleicht erhaelt er die Aufforderung zum Wechsel zur genannten Ressource nicht per HTTP.

Mein Request richtete sich also nach der angegebenen Location: info.html

Wenn du info.html anforderst, wieso wirst du dann auf info.html per 302 weitergeleitet?

Sicher, dass der Server "vernuenftig" arbeitet?

Die Content-Length ist 477, aber ich erhalte dann keinen "Content". Muß man den irgendwie manuell abfragen?

Zeig uns erst mal, wie du das Einlesen ueberhaupt machst.

Und die realen Adressen, die du abfragst, waeren vielleicht auch hilfreich.

MfG ChrisB

[Christian]

Hi,
erstmal vielen Dank für die Antwort :)

Hi,

Bis zu folgendem Response schicken Firefox und mein Skript das gleiche:

HTTP/1.1 302 Found\r\n
...
Location: info.html\r\n

Der Browser schickt nun einen GET-Request an die URI /head.php?showmus=1

Dazu hat er, zumindest wenn er obigen Response empfangen hat, aus HTTP-Sicht keinen Grund.

Wo im gegebenen Response liest der Browser diese URI ab?? Ich finde sie nicht.

Sie steht auch nicht in den HTTP-Headern.
Vielleicht erhaelt er die Aufforderung zum Wechsel zur genannten Ressource nicht per HTTP.

Wie können Daten noch übertragen werden? Hatte wohl fälschlicherweise angenommen, daß Browser und Server nur per HTTP komunizieren. Und wie kann man diese Daten auslesen? Geht das per PHP?

Mein Request richtete sich also nach der angegebenen Location: info.html

Wenn du info.html anforderst, wieso wirst du dann auf info.html per 302 weitergeleitet?

info.php habe ich erst angefordert nach der 302. Vorher war es noch eine andere Adresse.

Sicher, dass der Server "vernuenftig" arbeitet?

Also wenn ich mich mit dem Browser einlogge, dann funktioniert alles einwandfrei.

Die Content-Length ist 477, aber ich erhalte dann keinen "Content". Muß man den irgendwie manuell abfragen?

Zeig uns erst mal, wie du das Einlesen ueberhaupt machst.

Und die realen Adressen, die du abfragst, waeren vielleicht auch hilfreich.

MfG ChrisB

Also das Einlesen der Daten mache ich so:

Das chunked entschlüssel ich mit hexdec. Ich habe nun extra nochmal eine Funktion aus dem Netz genommen, um die Wahrscheinlichkeit eines Fehlers an dieser Stelle zu mindern. (Quelle ist PHP Manual für fsockopen, Beitrag von "mikey at badpenguins dot com" (danke^^))
Ändert mein Problem aber auch nicht, leider.

  
    function unchunkHttpResponse($str=null) {  
        if (!is_string($str) or strlen($str) < 1) { return false; }  
        $eol = "\r\n";  
        $add = strlen($eol);  
        $tmp = $str;  
        $str = '';  
        do {  
            $tmp = ltrim($tmp);  
            $pos = strpos($tmp, $eol);  
            if ($pos === false) { return false; }  
            $len = hexdec(substr($tmp,0,$pos));  
            if (!is_numeric($len) or $len < 0) { return false; }  
            $str .= substr($tmp, ($pos + $add), $len);  
            $tmp  = substr($tmp, ($len + $pos + $add));  
            $check = trim($tmp);  
            } while(!empty($check));  
        unset($tmp);  
        return $str;  
    }  

Nachdem ich mit fsockopen die Verbindung herstestellt habe und den HTTP-Response per fread gelesen und in der Variable $content gespeichert habe, suche ich das Ende des Headers und speichere mir Header und Body ab:

  
    $headend = strpos($content,"\r\n\r\n")+4;  
    $head = substr($content,0,$headend);  
    $body = substr($content,$headend,strlen($content)-$headend);  

Jetzt wird $body entschlüsselt:

  
    // Chunked Data Decode  
    if (strpos($head, "Transfer-Encoding: chunked")) {  
        $body = unchunkHttpResponse($body);  
    }  
  
    // gzip Data decode  
    if (strpos($head, "Content-Encoding: gzip")) {  
        $body = gzinflate(substr($body,10));  
    }  

Das funktionierte für mich auf der gleichen Seite nen HTTP-Response früher und ein korrekter Body wird zurückgeliefert.
Beim oben beschriebenen 302-Response mit dem kurzen Inhalt bekomme ich dadurch einen leeren String.

Ich ziehe ja hier die 10 Zeichen ab. Habe es schon mit 0 bis 15 Zeichen versucht, da kommt sonst nie was sinnvolles zurück.

Danke nochmal/schonmal :)
Gruß,
Christian

[ChrisB]

Hi,

Vielleicht erhaelt er die Aufforderung zum Wechsel zur genannten Ressource nicht per HTTP.

Wie können Daten noch übertragen werden? Hatte wohl fälschlicherweise angenommen, daß Browser und Server nur per HTTP komunizieren.

Ich meinte die Anweisung zur "Weiterleitung" - die koennte auch per Meta-Tag oder JavaScript aus dem Antwortdokument heraus erfolgt sein.

Wenn du info.html anforderst, wieso wirst du dann auf info.html per 302 weitergeleitet?

info.php habe ich erst angefordert nach der 302. Vorher war es noch eine andere Adresse.

Damit wird mir nicht klarer, was du machst, im Gegenteil.

Also, wer fordert was an, und wann und wo wird umgeleitet?

Also wenn ich mich mit dem Browser einlogge, dann funktioniert alles einwandfrei.

Aha, es ist also ein Einloggen erforderlich.
Wie nimmst du dieses Einloggen bei deinem Versuch, die Ressource ueber PHP einzulesen, denn vor?

Das funktionierte für mich auf der gleichen Seite nen HTTP-Response früher und ein korrekter Body wird zurückgeliefert.
Beim oben beschriebenen 302-Response mit dem kurzen Inhalt bekomme ich dadurch einen leeren String.

Sendet der Server mit der 302-Antwort denn ueberhaupt noch ein Dokument mit?

MfG ChrisB

[Christian]

Jo sry, habe ich wohl alles etwas unklar beschrieben. Ich bemühe mich nochmal alles der Reihe nach zu schildern.

Ich habe als Ausgangspunkt eine Internetseite mit einem Formular. Man muß mit diesem Formular Daten Senden, um sich einzuloggen. Das Formular sieht so aus:

  
<table align="center" background="/pics/online.gif" width="790" cellpadding="9">  
<tr><td>  
  <table>  
    <tr>  
      <td>  
        &nbsp;&nbsp;&nbsp;Name/Passwort:  
      </td>  
      <td valign="top">  
        <input type="text" name="NICK" size="11">&nbsp;  
        <input type="password" name="PW" maxlength="15" size="9">&nbsp;  
        <input type="submit" name="LOGIN" value="Login">&nbsp;  
      </td>  
    </tr>  
  </table>  
</td></tr>  
</table>  

Ich schicke also meinen Request mit POST an die Seite:

POST /index2.php HTTP/1.1\r\n
Host: ...\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Referer: http://.../index2.php\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 36\r\n\r\n
NICK=christian&PW=30chk5&LOGIN=Login\r\n
\r\n

(ich verschicke das, indem ich die php-befehle "fsockopen" und "fwrite" benutze).

der server antwortet mir mit dem folgenden Response:

HTTP/1.1 302 Found\r\n
Date: Mon, 24 Nov 2008 21:09:01 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
X-Powered-By: PHP/4.3.10\r\n
Set-Cookie: name=deleted; expires=Sun, 25-Nov-2007 21:09:00 GMT; path=/\r\n
Set-Cookie: sessionid=deleted; expires=Sun, 25-Nov-2007 21:09:00 GMT; path=/\r\n
Expires: Mon, 26 Jul 1997 05:00:00 GMT\r\n
Last-Modified: Mon, 24 Nov 2008 21:09:01 GMT\r\n
Cache-Control: post-check=0, pre-check=0\r\n
Pragma: no-cache\r\n
Set-Cookie: name=34485; expires=Mon, 24-Nov-2008 21:44:01 GMT; path=/\r\n
Set-Cookie: sessionid=a601b21fea9f31fdc2f306c5cd2a4a43; expires=Mon, 24-Nov-2008 21:44:01 GMT; path=/\r\n
Location: info.html\r\n
Content-Encoding: gzip\r\n
Vary: Accept-Encoding\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n
1a\r\n

0\r\n
\r\n

Das ist alles, was ich zurückbekomme. Außer dem Header also nur diesen kurze ASCII Code, welcher das mit gzip verschlüsselte Dokument darstellt, wenn ich mich nicht irre. (also ich habe den ASCII Code hier als Bild eingefügt. Sonst nimmt das Forum das hier nicht an.)
Wenn ich den ASCII Code entschlüssle mit gzip, wie in meinem vorherigen Beitrag beschrieben, dann erhalte ich einen leeren String.

Wenn man sich per Browser (getestet mit Firefox) einloggt, dann ist bis hier her alles genauso, wie ich es mit meinem php-skript mache.

Auf diesen 302 Response sendet Firefox nun aber den folgenden Request:

GET /head.php?showmus=1 HTTP/1.1\r\n
Host: ...\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Referer: http://.../info.html\r\n
Cookie: name=34485; sessionid=a601b21fea9f31fdc2f306c5cd2a4a43\r\n
\r\n

Ich habe nicht verstanden, warum der Browser diesen Request schickt. Ich weiß nicht, woher er die Adresse "/head.php?showmus=1" hat.

Deswegen hatte ich einen anderen Request auf die obere 302 Response geschickt und zwar folgenden:

GET /info.html HTTP/1.1\r\n
Host: ...\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Cookie: name=34485; sessionid=a601b21fea9f31fdc2f306c5cd2a4a43\r\n
\r\n

Die Response vom Server sieht dann so aus:

HTTP/1.1 200 OK\r\n
Date: Mon, 24 Nov 2008 21:09:13 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
Last-Modified: Thu, 22 May 2008 12:34:51 GMT\r\n
ETag: "f0e84-1dd-4835686b"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 477\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html\r\n
\r\n

Der Server schickt mir hier keinerlei Daten nach dem Header mit. Also kein Dokument, oder sonstwas, obwohl "Content-Length" = 477 ist.

Das verstehe ich nicht.

Muß ich da nochmal nachfragen, um den Inhalt (also das Dokument) zu erhalten?

Ich hoffe ich konnte mein Problem vollständig und verständlich vermitteln :)

Wäre super, wenn Du, oder sonst wer mir weiterhelfen könnte.

Viele Grüße,
Christian

[Der Martin]

n'Abend!

Das Formular sieht so aus:

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.

POST /index2.php HTTP/1.1\r\n
Host: ...\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Referer: http://.../index2.php\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 36\r\n\r\n
NICK=christian&PW=30chk5&LOGIN=Login\r\n
\r\n

Sieht für mich vernünftig aus.

HTTP/1.1 302 Found\r\n
Date: Mon, 24 Nov 2008 21:09:01 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
X-Powered-By: PHP/4.3.10\r\n
Set-Cookie: name=deleted; expires=Sun, 25-Nov-2007 21:09:00 GMT; path=/\r\n
Set-Cookie: sessionid=deleted; expires=Sun, 25-Nov-2007 21:09:00 GMT; path=/\r\n
Expires: Mon, 26 Jul 1997 05:00:00 GMT\r\n
Last-Modified: Mon, 24 Nov 2008 21:09:01 GMT\r\n
Cache-Control: post-check=0, pre-check=0\r\n
Pragma: no-cache\r\n
Set-Cookie: name=34485; expires=Mon, 24-Nov-2008 21:44:01 GMT; path=/\r\n
Set-Cookie: sessionid=a601b21fea9f31fdc2f306c5cd2a4a43; expires=Mon, 24-Nov-2008 21:44:01 GMT; path=/\r\n
Location: info.html\r\n
Content-Encoding: gzip\r\n
Vary: Accept-Encoding\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n
1a\r\n

0\r\n
\r\n

Der Content-Block wäre als reiner Hexdump wahrscheinlich informativer als mit dieser erzwungenen Unicode-Transcription.
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.

Das ist alles, was ich zurückbekomme. Außer dem Header also nur diesen kurze ASCII Code, welcher das mit gzip verschlüsselte Dokument darstellt, wenn ich mich nicht irre. (also ich habe den ASCII Code hier als Bild eingefügt. Sonst nimmt das Forum das hier nicht an.)

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

Wenn ich den ASCII Code entschlüssle mit gzip, wie in meinem vorherigen Beitrag beschrieben, dann erhalte ich einen leeren String.

Ups.

Wenn man sich per Browser (getestet mit Firefox) einloggt, dann ist bis hier her alles genauso, wie ich es mit meinem php-skript mache.

Sollte so sein.

Auf diesen 302 Response sendet Firefox nun aber den folgenden Request:

GET /head.php?showmus=1 HTTP/1.1\r\n
...

Das hat ihm der Teufel gesagt.
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?

Referer: http://.../info.html\r\n

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?

GET /info.html HTTP/1.1\r\n
Host: ...\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Cookie: name=34485; sessionid=a601b21fea9f31fdc2f306c5cd2a4a43\r\n
\r\n

HTTP/1.1 200 OK\r\n
Date: Mon, 24 Nov 2008 21:09:13 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
Last-Modified: Thu, 22 May 2008 12:34:51 GMT\r\n
ETag: "f0e84-1dd-4835686b"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 477\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html\r\n
\r\n

Der Server schickt mir hier keinerlei Daten nach dem Header mit.

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).

Also kein Dokument, oder sonstwas, obwohl "Content-Length" = 477 ist.

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

Muß ich da nochmal nachfragen, um den Inhalt (also das Dokument) zu erhalten?

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

Ich hoffe ich konnte mein Problem vollständig und verständlich vermitteln :)

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

So long,
 Martin

[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

[Christian]

Hi nochmal,

aaahhh jetzt hab ich's :)
danke nochmal mit dem Tipp einen hexdump zu erstellen.
Ich Depp dachte var_dump gibt alles aus.

beim Response

HTTP/1.1 200 OK\r\n
Date: Mon, 24 Nov 2008 21:09:13 GMT\r\n
Server: Apache/1.3.33 (Unix) (Gentoo/Linux) PHP/4.3.10 mod_gzip/1.3.26.1a\r\n
Last-Modified: Thu, 22 May 2008 12:34:51 GMT\r\n
ETag: "f0e84-1dd-4835686b"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 477\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html\r\n
\r\n

dachte ich, es wird ein leerer String als body mit zurückgeschickt. Mit var_dump war der String immer leer, aber es waren noch ascii zeichen vorhanden, die var_dump ignoriert hat.

Jetzt mit der PHP-Funktion sprintf und %s sehe ich endlich den Inhalt, der mir vorher leer erschienen war.
Mann das war echt dumm von mir.

Jetzt verstehe ich auch was der Firefox macht. Er muß den gleichen Request, wie ich wohl schicken, aber das wird nicht von Live HTTP Headers aufgezeichnet.
Danach kommt man wirklich auf eine Seite, von der aus man aufgefordert wird /head.php?showmus=1 zu laden, was dann Live HTTP Headers wieder mit aufzeichnet.

Da hattest Du mit Deinen Vermutungen völlig recht. Respekt!

Danke Dir nochmals und allen, die sich Gedanken, etc. gemacht haben.

Jetzt kann ich endlich weiter an meinem Proxy arbeiten. Juhuu :)

Gruss
Christian

P.S.: Falls irgendwer ähnliche Probleme hat beim Programmieren eines Proxys, oder eines Programmes, das sich auf irgendeiner Internetseite einloggt, so kann er gerne hier posten. Da ich nun schon recht lange an meinem Programm rumtüftle ist es vielleicht irgendein Problem, das ich auch schon hatte und wobei ich dann weiterhelfen kann.

[Der Martin]

Hallo Christian,

Ich Depp dachte var_dump gibt alles aus.

das tut es "eigentlich" auch.

beim Response
[...]
dachte ich, es wird ein leerer String als body mit zurückgeschickt. Mit var_dump war der String immer leer, aber es waren noch ascii zeichen vorhanden, die var_dump ignoriert hat.

Mit ASCII-Zeichen meinst du Steuerzeichen?

Jetzt mit der PHP-Funktion sprintf und %s sehe ich endlich den Inhalt, der mir vorher leer erschienen war.

Dann stelle doch hier bitte nochmal beide Ausgaben zum Vergleich direkt gegenüber, damit wir für die Nachwelt dokumentiert haben, wo var_dump() Schwächen hat. Ich könnte mir vorstellen, dass es mit den Nullbytes in Schwierigkeiten kommt.

Jetzt verstehe ich auch was der Firefox macht. Er muß den gleichen Request, wie ich wohl schicken, aber das wird nicht von Live HTTP Headers aufgezeichnet.

Und das ist *sehr* eigenartig. Mir ist bis jetzt noch nicht aufgefallen, dass die LiveHTTP-Extension einzelne Vorgänge übergeht. Wenn sowas noch einmal auftaucht, solltest du die Situation sofort einfrieren und entweder hier zur Diskussion stellen oder direkt als Bug beim Autor der Extension melden.

Da hattest Du mit Deinen Vermutungen völlig recht. Respekt!

Danke ... ein wenig Erfahrung, ein bisschen Logik ... ;-)

Schönen Sonntag noch,
 Martin

[Christian]

Hi,

Mit ASCII-Zeichen meinst du Steuerzeichen?

Keine Ahnung so genau. Kann gut sein, daß es Steuerzeichen sind. Es kommt jedenfalls ein String mit Zeichen zurück, die in var_dump und echo nicht ausgegeben werden. Am besten hat das entschlüsseln mit der Funktion htmlentities funktioniert.
Wie kann ich denn feststellen, welche Zeichen das genau sind? Dann kann ich das gerne testen und Resultate hier aufschreiben.

Und das ist *sehr* eigenartig. Mir ist bis jetzt noch nicht aufgefallen, dass die LiveHTTP-Extension einzelne Vorgänge übergeht. Wenn sowas noch einmal auftaucht, solltest du die Situation sofort einfrieren und entweder hier zur Diskussion stellen oder direkt als Bug beim Autor der Extension melden.

Das macht Live-HTTP-Headers jedes Mal, wenn ich es in derselben Situation verwende.

Es ist so, daß eine Seite geladen wird, die aus mehreren Frames besteht.
Modell:
Seite 1 besteht aus Frame 1, Frame 2 und Frame 3.
Beim Laden von Seite 1 zeigt Live-HTTP-Headers zeigt nicht an, daß ein Request an Seite 1 geschickt wurde, sondern nur die Requests an die Adressen von Frame 1-3.

KA, ob das immer so ist. Ich werde das bei Zeiten testen.