O Chrome e o Chromium mais recentes parecem descompactar arquivos .tar.gz automaticamente para mim no OS X e Linux. Ao usar wgetcom a mesma URL, mostra:
$ wget http://mydomain/dir/file.tar.gz
...
HTTP request sent, awaiting response... 200 OK
Length: ... [application/octet-stream]
...
Verificando o tipo de arquivo:
$ file file.tar.gz
file.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
Ao fazer o mesmo para o arquivo baixado com Chrome ou Chromium:
$ file file.tar.gz
file.tar.gz: POSIX tar archive
Observe que o Chrome/Chromium obviamente manteve o nome do arquivo, mas o expandiu (o tamanho do arquivo é cerca de 4 vezes maior do que o arquivo baixado pelo wget).
Como administrador do site, como posso evitar que o Chrome/Chromium descompacte o arquivo?
Atualizar:
De acordo com curl -I http://mydomain/dir/file.tar.gznosso combo Apache/Tomcat responde com
Content-Encoding: x-gzip
Arquivos testados .tar.gzde outros sites não são descompactados pelo Chrome e não informam o Content-Encoding: x-gzipcabeçalho, então parece haver uma relação.
Responder1
Seu servidor web provavelmente está enviando o .tar.gzarquivo com um content-encoding: gzipcabeçalho, fazendo com que o navegador presuma que uma camada gzip foi aplicada apenas para economizar largura de banda, e o que você realmente pretendia enviar era o .tararquivo. O Chrome descompacta-o do outro lado, como faria com qualquer outro arquivo ( .html, .js, .css, etc.) que recebe gzipado (no entanto, ele obedientemente não modifica o nome do arquivo).
Para corrigir isso, certifique-se de que seu servidor web forneça .tar.gzarquivos sem o content-encoding: gzipcabeçalho.
Mais informações:https://code.google.com/p/chromium/issues/detail?id=83292
Responder2
De acordo com nosso provedor de hospedagem o cabeçalho Content-Encoding: x-gzipfoi causado pelo Apache na frente do nosso Tomcat. Removendo a seguinte linha:
LoadModule deflate_module modules/mod_deflate.so
desde sua configuração resolveu o problema.