PHP fsockopen tar.gz

[Brocken]

Hallo,

ich stehe vor einem Problem, und komme nicht recht weiter. Es geht um folgendes:

Ich lade von einem per htaccess-Datei geschütztem Bereich ein tar.gz-Archiv runter. Dazu nutze ich die fsockopen-Funktion von PHP :

  
header("Content-type: text/html");  
$sock = fsockopen($host, 80, $errno, $errstr, 5); // 80 = Port, 5 = Timeout  
fputs($sock, "GET ".$uri." HTTP/1.1\r\n");  
fputs($sock, "Host: ".$host."\r\n");  
fputs($sock, "Authorization: Basic ".base64_encode($user.":".$pass)."\r\n");  
fputs($sock, "Connection: close\r\n\r\n");  
while(!feof($sock))  
  $targz .= fgets($sock, 4096); // Antwort lesen  
fclose($sock);  

Den so erhaltenen String speichere ich mit der Funktion file_put_contents("dateiname.tar.gz",$targz) auf dem Server ab.

Das Funktioniert alles problemlos. Nur wenn ich dieses Archiv entpacken will, erhalte ich von der Shell folgende Fehlermeldung:

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error exit delayed from previous errors

Das Archiv ist also fehlerhaft. Ziehe ich das Archiv herkömmlich via Browser ist es gültig. Das heisst, ich mache beim Speichern wohl einen Fehler. Muss ich den String $targz noch irgendwie umwandeln? Ich habe ich schon von hex zu bin umgewandelt, aber das brachte mir auch keinen Erfolg. Die Fehlermeldung blieb die gleiche.

Vielleicht kann mir jemand einen Tip geben?

Danke! Brocken

[ChrisB]

Hi,

Das Archiv ist also fehlerhaft. Ziehe ich das Archiv herkömmlich via Browser ist es gültig. Das heisst, ich mache beim Speichern wohl einen Fehler.

Dann sollte doch wohl das allererste, was du machst, ein Vergleich zweier solcher Versionen ein und der gleichen Ressource sein.
Welche Unterschiede fallen dir im HEX-Editor auf?

MfG ChrisB

[Brocken]

Hi,

Dann sollte doch wohl das allererste, was du machst, ein Vergleich zweier solcher Versionen ein und der gleichen Ressource sein.
Welche Unterschiede fallen dir im HEX-Editor auf?

Also mir fallen zwei Sachen auf:

1. die so gewonnenene Datei ist etwas größer. Und zwar um diesen Teil

HTTP/1.1 200 OK
Date: Thu, 01 Jul 2010 15:44:47 GMT
Server: Apache
Last-Modified: Thu, 01 Jul 2010 15:22:03 GMT
ETag: "7468005-1c746c-48a55084d9cc0"
Accept-Ranges: bytes
Content-Length: 1864812
Connection: close
Content-Type: application/x-gzip
Content-Encoding:

Das heisst, ich speichere diese Server-Response auch mit ab...das will ich natürlich nicht. Wie könnte man das denn verhindern?

Brocken

[ChrisB]

Hi,

Also mir fallen zwei Sachen auf:

Mir auch. Erstens, dass du bis zwei zählst, um dann nur einen Aspekt zu nennen.

Das heisst, ich speichere diese Server-Response auch mit ab...

Natürlich, die bekommst du als erstes geliefert, wenn du mit fsockopen einen HTTP-Request machst.

das will ich natürlich nicht. Wie könnte man das denn verhindern?

Man macht sich zu Nutze, dass man weiss, dass die HTTP-Header bekanntlich mit einem doppelten \r\n beendet werden.

MfG ChrisB

[Brocken]

Ausserdem stimmen die Zeichen nicht überein.

Die letzte Zeite sollte im HEX-Editor z.b. so lauten:

8B 12 7C 00 88 3D 03

in meinem runtergeladenen File lautet sie:

76 44 00 48  41 03

[Der Martin]

Hallo,

Die letzte Zeite sollte im HEX-Editor z.b. so lauten:
8B 12 7C 00 88 3D 03
in meinem runtergeladenen File lautet sie:
76 44 00 48  41 03

die für diesen Unterschied vermutlich entscheidende Information, nämlich den Wert des Headers Content-Encoding, hast du im vorigen Posting leider weggekürzt.

Ciao,
 Martin

[Brocken]

Hi Martin,

die für diesen Unterschied vermutlich entscheidende Information, nämlich den Wert des Headers Content-Encoding, hast du im vorigen Posting leider weggekürzt.

ui, stimmt, hier ist sie:

Content-Encoding: x-gzip

[Brocken]

Danke Euch,

ChrisBs Tipp war Gold wert.
Vielen Dank

[EKKi]

Mahlzeit Brocken,

ChrisBs Tipp war Gold wert.

Das sind sie fast immer ... die meisten Fragesteller brauchen allerdings etwas länger, um das zu erkennen. ;-)

MfG,
EKKi

[suit]

ChrisBs Tipp war Gold wert.

Das sind sie fast immer ... die meisten Fragesteller brauchen allerdings etwas länger, um das zu erkennen. ;-)

Wenn sie nicht vorher ausfallen oder gar beleidigen werden ;)

[Der Martin]

Hallo,

die für diesen Unterschied vermutlich entscheidende Information, nämlich den Wert des Headers Content-Encoding, hast du im vorigen Posting leider weggekürzt.
ui, stimmt, hier ist sie:
Content-Encoding: x-gzip

aha, da haben wir das Schweinerle.
Dann wird dein Browser beim Download vermutlich automatisch "transparent" die gzip-Kompression entpacken und die Daten entpackt speichern. Dein PHP-Script tut das nicht, sondern speichert gzip-komprimierte Daten.

ChrisBs Tipp war Gold wert.

Welcher jetzt konkret?

So long,
 Martin

[Brocken]

Hallo Martin,

dass ich den Response-Header abschneiden muss... da hätte ich auch mal selber draufkommen können. Jetzt weiß ich das...

Hier nochmal der Tip von ChrisB

Das heisst, ich speichere diese Server-Response auch mit ab...

Natürlich, die bekommst du als erstes geliefert, wenn du mit fsockopen einen HTTP-Request machst.

das will ich natürlich nicht. Wie könnte man das denn verhindern?

Man macht sich zu Nutze, dass man weiss, dass die HTTP-Header bekanntlich mit einem doppelten \r\n beendet werden.

Schönes WM-Wochenende!

brocken

[suit]

Man macht sich zu Nutze, dass man weiss, dass die HTTP-Header bekanntlich mit einem doppelten \r\n beendet werden.

Jein: "an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields [...] In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected."

Hier sollte der Client also die beiden ersten CRLF ignorieren, erst die vierte Zeile (bzw das vierte CRLF) stellt das Ende des Headers dar.

CRLFCRLFHost: example.comCRLFCRLF

Freilich ist das nicht Pflicht und in deinem Fall wahrscheinlich auch nicht relevant.