Chrom: Verhindern Sie das Auspacken von tar.gz

3289
Thomas S.

Das neueste Chrome und Chromium scheint .tar.gz-Dateien automatisch für mich unter OS X und Linux zu entpacken. Bei Verwendung wgetderselben URL wird Folgendes angezeigt:

$ wget http://mydomain/dir/file.tar.gz ... HTTP request sent, awaiting response... 200 OK Length: ... [application/octet-stream] ...

Überprüfen des Dateityps:

$ file file.tar.gz file.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)

Wenn Sie dasselbe für die mit Chrome oder Chromium heruntergeladene Datei tun:

$ file file.tar.gz file.tar.gz: POSIX tar archive

Beachten Sie, dass Chrome / Chromium den Dateinamen offenbar beibehalten hat, ihn jedoch erweitert hat (die Dateigröße ist ~ 4-mal größer als die von der Wget-Datei heruntergeladene Datei).

Wie kann ich als Website-Administrator verhindern, dass Chrome / Chromium die Datei entpackt?

Aktualisieren:

Laut curl -I http://mydomain/dir/file.tar.gzunserer Apache / Tomcat Combo antwortet mit

Content-Encoding: x-gzip

Versuchte .tar.gzDateien von anderen Websites werden von Chrome nicht entpackt und geben den Content-Encoding: x-gzipHeader nicht an. Es scheint also eine Beziehung zu geben.

3

2 Antworten auf die Frage

5
Maximillian Laumeister

Wahrscheinlich sendet Ihr Webserver die .tar.gzDatei mit einem content-encoding: gzipHeader. Dies bedeutet, dass der Webbrowser davon ausgeht, dass eine gzip-Ebene nur zum Einsparen von Bandbreite angewendet wurde. Was Sie wirklich senden wollten, war das .tarArchiv. Chrome un-gzips es auf der anderen Seite, wie es bei jeder anderen Datei ( .html, .js, .css, etc.), dass es gzipped erhält (es ist dutifully nicht die Dateinamen ändern obwohl).

Um dies zu beheben, stellen Sie sicher, dass Ihr Webserver .tar.gzDateien ohne content-encoding: gzipHeader bereitstellt.

Weitere Informationen: https://code.google.com/p/chromium/issues/detail?id=83292

Ich habe den Tomcat bereits geändert, um `application / octet-stream` für` gz'-Dateien zu senden (siehe Ausgabe von 'wget'). Es hat sich nichts geändert. Abgesehen davon scheint es sich bei Chrome um ein neues Feature zu handeln - ich kann mich nicht erinnern, dass es vor 3 Monaten bereits entpackte Dateien hatte. Thomas S. vor 9 Jahren 0
@ThomasS. Soweit ich weiß, liegt Ihr Problem beim Senden des Headers `content-coding: gzip`. Es hat nichts mit dem Inhaltstyp` application / octet-stream 'zu tun. Mit anderen Worten, ich empfehle Ihnen, den Header "Content-Encoding" und nicht den Header "Content-Type" zu ändern. Maximillian Laumeister vor 9 Jahren 2
Der Fehler ist als behoben markiert, aber ich habe das gleiche Problem im Jahr 2018 gefunden, jedoch mit der Erweiterung ".tgz". Beispiel-URL: https://www.lysator.liu.se/~jc/wotsap/download/wotsap-0.7.tgz Jonathan Cross vor 5 Jahren 0
0
Thomas S.

Laut unserem Hosting-Provider wurde der Header Content-Encoding: x-gzipdurch den Apache vor unserem Tomcat verursacht. Folgende Zeile entfernen:

LoadModule deflate_module modules/mod_deflate.so

von seiner Konfiguration gelöst das Problem.

Verwandte Probleme