Die neuesten Versionen von Chrome und Chromium scheinen .tar.gz-Dateien unter OS X und Linux automatisch für mich zu entpacken. Bei Verwendung wgetmit derselben 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 offensichtlich beibehalten, ihn aber erweitert hat (die Dateigröße ist etwa viermal größer als die der über wget heruntergeladenen 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-Kombination antwortet
Content-Encoding: x-gzip
Versuchte .tar.gzDateien von anderen Websites werden von Chrome nicht entpackt und melden den Header nicht Content-Encoding: x-gzip, es scheint also einen Zusammenhang zu geben.
Antwort1
Ihr Webserver sendet die .tar.gzDatei wahrscheinlich mit einem content-encoding: gzipHeader, sodass der Webbrowser annimmt, dass eine Gzip-Ebene nur angewendet wurde, um Bandbreite zu sparen, und dass Sie eigentlich das .tarArchiv senden wollten. Chrome entpackt die Datei auf der anderen Seite wie jede andere Datei ( .html, .js, .css, usw.), die es gzippt empfängt (der Dateiname wird jedoch brav nicht geändert).
Um dies zu beheben, stellen Sie sicher, dass Ihr Webserver .tar.gzDateien ohne content-encoding: gzipHeader bereitstellt.
Mehr Info:https://code.google.com/p/chromium/issues/detail?id=83292
Antwort2
Laut unserem Hosting-Anbieter Content-Encoding: x-gzipwurde der Header durch den Apache vor unserem Tomcat verursacht. Entfernen Sie die folgende Zeile:
LoadModule deflate_module modules/mod_deflate.so
aus seiner Konfiguration wurde das Problem gelöst.