Jemand ne Ahnung? Wäre nicht das erste .tar.gz, das ich runterlade.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.
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.Leonidas hat geschrieben:Ohne Proxy runterladen?N317V hat geschrieben:Jemand ne Ahnung?
Na dann daheim runterladen, oder auf Besserung hoffen (Besserung seitens deines Proxies oder seitens BlackJacks Server).N317V hat geschrieben:Wird wohl aus unserem Firmennetz nicht möglich sein.Leonidas hat geschrieben:Ohne Proxy runterladen?N317V hat geschrieben:Jemand ne Ahnung?
Die Idee habe ich von Eclipse geklaut.Rebecca hat geschrieben:Das mit der Abstufung nach Wichtigkeit mittels Ausrufezeichen ist eine tolle Idee.
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-gzipDas 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.Content-Type: application/x-tar
Content-Encoding: x-gzip
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.modelnine hat geschrieben: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.Content-Type: application/x-tar
Content-Encoding: x-gzip
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.
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.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.
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?modelnine hat geschrieben: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.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.
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.Oder funktioniert das gzip da anders?
Doch, wenn da gzip steht, dann ist auch gzip wie in RFC1952 beschrieben gemeint.modelnine hat geschrieben:Eben nicht. Content-Encoding: gzip != .gz-Packformat,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.
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.
`zlib` wäre aber Content-Encoding: deflate und nicht gzip.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 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.`zlib` wäre aber Content-Encoding: deflate und nicht gzip.