Seite 1 von 1
HTTP-Encodings
Verfasst: Dienstag 4. April 2006, 07:47
von N317V
Edit (Leonidas): Thread aus ToDo Extractor herausgesplitet.
Wollt's mir eigentlich auch anschauen, da ich auch mit solchen speziellen Kommentaren arbeite, aber ich bekomm immer folgende Fehlermeldung:
Content Transformation Error (transformation_error)
Proxy cannot apply content transformation.
This could be caused by a misconfiguration, or possibly a response with an unknown content encoding.
Jemand ne Ahnung? Wäre nicht das erste .tar.gz, das ich runterlade.
Verfasst: Dienstag 4. April 2006, 08:51
von Rebecca
Hey BlackJack,
nuetzliches Skript, das du da geschrieben hast. Das mit der Abstufung nach Wichtigkeit mittels Ausrufezeichen ist eine tolle Idee. Ich schreibe naemlich auch immer sowas in meine Kommentare...
Verfasst: Dienstag 4. April 2006, 15:42
von Leonidas
N317V hat geschrieben:Jemand ne Ahnung?
Ohne Proxy runterladen?
Verfasst: Dienstag 4. April 2006, 15:47
von N317V
Leonidas hat geschrieben:N317V hat geschrieben:Jemand ne Ahnung?
Ohne Proxy runterladen?
Wird wohl aus unserem Firmennetz nicht möglich sein. Hat auch immer mit Proxy funktioniert. Hab ich danach sogar nochmal auf einer anderen Website getestet.
Verfasst: Dienstag 4. April 2006, 16:12
von Leonidas
N317V hat geschrieben:Leonidas hat geschrieben:N317V hat geschrieben:Jemand ne Ahnung?
Ohne Proxy runterladen?
Wird wohl aus unserem Firmennetz nicht möglich sein.
Na dann daheim runterladen, oder auf Besserung hoffen (Besserung seitens deines Proxies oder seitens BlackJacks Server).
Verfasst: Mittwoch 5. April 2006, 07:35
von BlackJack
Rebecca hat geschrieben:Das mit der Abstufung nach Wichtigkeit mittels Ausrufezeichen ist eine tolle Idee.
Die Idee habe ich von Eclipse geklaut.
Verfasst: Mittwoch 5. April 2006, 07:45
von BlackJack
Zum "misconfigured": Der Server sendet diese Header:
Code: Alles auswählen
HTTP/1.1 200 OK
Date: Wed, 05 Apr 2006 06:42:19 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-16 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_perl/1.999.21 Perl/v5.8.4
Last-Modified: Mon, 03 Apr 2006 20:00:15 GMT
ETag: "1875c3-339a-3d3211c0"
Accept-Ranges: bytes
Content-Length: 13210
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/x-tar
Content-Encoding: x-gzip
Ist da irgendwas offensichtlich falsches bei? Für mich sieht's normal aus.
Verfasst: Mittwoch 5. April 2006, 07:51
von modelnine
Content-Type: application/x-tar
Content-Encoding: x-gzip
Das sieht irgendwie seltsam aus. Er schickt ja kein tar in Content-Encoding gzip über die Leitung, sondern ein .tar.gz, sprich eigentlich "application/octet-stream". Für .tar.gz gibts auch einen MIME-Type, soweit ich weiß, aber zur Not sollte es auch octet-stream tun, damit der Proxy eben nicht mehr zwischenmuckt und probiert was damit zu machen.
Ich geh davon aus dass der Proxy den die Firma von N137V benutzt probiert das Content-Encoding aufzulösen, das aber nicht hinkriegt (weil der Inhalt eben ein .tar.gz, und kein HTTP-gegzipptes .tar-File ist), und deswegen eine Macke kriegt.
Aber, wie gesagt, das ist reine Spekulation.
Verfasst: Mittwoch 5. April 2006, 16:16
von CM
Sehr schön - gerade runtergeladen und eingesetzt. Habe nur "meine" TODO-Zeichen ergänzen müssen.
Danke,
Christian
Verfasst: Mittwoch 5. April 2006, 22:21
von BlackJack
modelnine hat geschrieben:Content-Type: application/x-tar
Content-Encoding: x-gzip
Das sieht irgendwie seltsam aus. Er schickt ja kein tar in Content-Encoding gzip über die Leitung, sondern ein .tar.gz, sprich eigentlich "application/octet-stream". Für .tar.gz gibts auch einen MIME-Type, soweit ich weiß, aber zur Not sollte es auch octet-stream tun, damit der Proxy eben nicht mehr zwischenmuckt und probiert was damit zu machen.
Ich geh davon aus dass der Proxy den die Firma von N137V benutzt probiert das Content-Encoding aufzulösen, das aber nicht hinkriegt (weil der Inhalt eben ein .tar.gz, und kein HTTP-gegzipptes .tar-File ist), und deswegen eine Macke kriegt.
Aber, wie gesagt, das ist reine Spekulation.
Das führt im schlimmsten Fall aber eigentlich nur dazu, dass man ein *.tar.gz auf der Platte hat, was in Wirklichkeit nur noch ein *.tar ist, weil der Browser (oder Proxy) beim Übertragen schon entpackt hat.
Verfasst: Mittwoch 5. April 2006, 22:52
von modelnine
Das führt im schlimmsten Fall aber eigentlich nur dazu, dass man ein *.tar.gz auf der Platte hat, was in Wirklichkeit nur noch ein *.tar ist, weil der Browser (oder Proxy) beim Übertragen schon entpackt hat.
Eben nicht. Content-Encoding: gzip != .gz-Packformat, die Optionen die beim Packen für die Zustandsmaschine verwendet werden sind andere, und ich habs zumindest schon gehabt dass Browser Content-Encoding: gzip, was mit den Standardoptionen des zlib-Konstruktors erzeugt wurde, nicht entpacken konnten. Und ich würd davon ausgehen, dass hier etwas ähnliches am Werk ist.
Aber, wie gesagt: reine Spekulation.
Verfasst: Donnerstag 6. April 2006, 04:47
von mitsuhiko
modelnine hat geschrieben:Das führt im schlimmsten Fall aber eigentlich nur dazu, dass man ein *.tar.gz auf der Platte hat, was in Wirklichkeit nur noch ein *.tar ist, weil der Browser (oder Proxy) beim Übertragen schon entpackt hat.
Eben nicht. Content-Encoding: gzip != .gz-Packformat, die Optionen die beim Packen für die Zustandsmaschine verwendet werden sind andere, und ich habs zumindest schon gehabt dass Browser Content-Encoding: gzip, was mit den Standardoptionen des zlib-Konstruktors erzeugt wurde, nicht entpacken konnten. Und ich würd davon ausgehen, dass hier etwas ähnliches am Werk ist.
Wenn ich ein tag durch gzip jage hab ich ein trag.gz. Content-Encoding gzip sollte doch genau der umgekehrte weg sein. Oder funktioniert das gzip da anders?
Verfasst: Donnerstag 6. April 2006, 05:59
von modelnine
Oder funktioniert das gzip da anders?
Ja. Die Zustandsmaschine (im Endeffekt die Kompressionsstärke), die Flush-Häufigkeit und der Algorithmus (soweit ich weiß) wird speziell gewählt bei Content-Encoding: gzip. Nichts was sich nicht auch mittels zlib.compress() erzeugen würde, aber nur indem man die Zustandsmaschine entsprechend einstellt. gzip benutzt die Standardoptionen von zlib. Zumindest hatte ich diesen Fehler mal mit einem Browser, der Content-Encoding: gzip (was naiv mit zlib.compress() verpackt war) nicht anzeigen wollte, und ich könnte mir vorstellen dass hier was ähnliches am Werk ist.
Verfasst: Donnerstag 6. April 2006, 23:27
von BlackJack
modelnine hat geschrieben:Das führt im schlimmsten Fall aber eigentlich nur dazu, dass man ein *.tar.gz auf der Platte hat, was in Wirklichkeit nur noch ein *.tar ist, weil der Browser (oder Proxy) beim Übertragen schon entpackt hat.
Eben nicht. Content-Encoding: gzip != .gz-Packformat,
Doch, wenn da gzip steht, dann ist auch gzip wie in RFC1952 beschrieben gemeint.
HTTP 1.1 RFC hat geschrieben:gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
die Optionen die beim Packen für die Zustandsmaschine verwendet werden sind andere, und ich habs zumindest schon gehabt dass Browser Content-Encoding: gzip, was mit den Standardoptionen des zlib-Konstruktors erzeugt wurde, nicht entpacken konnten. Und ich würd davon ausgehen, dass hier etwas ähnliches am Werk ist.
`zlib` wäre aber Content-Encoding: deflate und nicht gzip.
Verfasst: Freitag 7. April 2006, 00:16
von modelnine
`zlib` wäre aber Content-Encoding: deflate und nicht gzip.
zlib erstellt beides, eben je nach Parametern. Content-Encoding: deflate ist es auf jeden Fall
nur wenn man explizit verbietet dass eine andere Komprimierung (als der deflate-Algorithmus) benutzt wird, gzip dekomprimierbar ist es nach einfügen eines kleinen Headers auf jeden Fall ohne dass man Argumente hinzufügt. Wenn Du magst schreib ich morgen ein Beispiel dafür.