Последние Chrome и Chromium, похоже, автоматически распаковывают файлы .tar.gz для меня на OS X и Linux. При использовании 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, очевидно, сохранил имя файла, но расширил его (размер файла примерно в 4 раза больше, чем у файла, загруженного wget).
Как администратор веб-сайта, могу ли я запретить 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 был применен только для экономии пропускной способности, и что на самом деле вы намеревались отправить архив .tar. Chrome распаковывает его на другой стороне, как и любой другой файл ( .html, .js, .css, и т. д.), который он получает сжатым gzip (хотя он добросовестно не изменяет имя файла).
Чтобы исправить это, убедитесь, что ваш веб-сервер обслуживает .tar.gzфайлы без content-encoding: gzipзаголовка.
Больше информации:https://code.google.com/p/chromium/issues/detail?id=83292
решение2
По данным нашего хостинг-провайдера заголовок Content-Encoding: x-gzipбыл вызван Apache перед нашим Tomcat. Удаляем следующую строку:
LoadModule deflate_module modules/mod_deflate.so
из его конфигурации проблема решена.