最新的 Chrome 和 Chromium 似乎会在 OS X 和 Linux 上自动为我解压 .tar.gz 文件。使用wget
相同的 URL 时,它会显示:
$ wget http://mydomain/dir/file.tar.gz
...
HTTP request sent, awaiting response... 200 OK
Length: ... [application/octet-stream]
...
验证文件类型:
$ file file.tar.gz
file.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
对使用 Chrome 或 Chromium 下载的文件执行相同操作时:
$ file file.tar.gz
file.tar.gz: POSIX tar archive
请注意,Chrome/Chromium 显然保留了文件名,但对其进行了扩展(文件大小比 wget 下载的文件大约大 4 倍)。
作为网站管理员,我如何防止 Chrome/Chromium 解压该文件?
更新:
根据curl -I http://mydomain/dir/file.tar.gz
我们的 Apache/Tomcat 组合响应
Content-Encoding: x-gzip
尝试过.tar.gz
的其他网站的文件无法被 Chrome 解压,并且不会报告Content-Encoding: x-gzip
标头,因此似乎存在某种关系。
答案1
您的网络服务器可能会发送带有标头.tar.gz
的文件content-encoding: gzip
,导致网络浏览器认为应用 gzip 层只是为了节省带宽,而您真正想要发送的是存档。Chrome 会在另一端解压缩它,就像它对收到的任何其他经过 gzip 压缩的文件( 、、等).tar
一样(但它不会修改文件名)。.html
.js
.css
要解决此问题,请确保您的 Web 服务器提供.tar.gz
不带标头的文件content-encoding: gzip
。
更多信息:https://code.google.com/p/chromium/issues/detail?id=83292
答案2
根据我们的托管服务提供商的说法,该标头Content-Encoding: x-gzip
是由 Tomcat 前面的 Apache 引起的。删除以下行:
LoadModule deflate_module modules/mod_deflate.so
从其配置上解决了这个问题。