Los últimos Chrome y Chromium parecen descomprimir archivos .tar.gz automáticamente en OS X y Linux. Cuando se usa wgetcon la misma URL, muestra:
$ wget http://mydomain/dir/file.tar.gz
...
HTTP request sent, awaiting response... 200 OK
Length: ... [application/octet-stream]
...
Verificando el tipo de archivo:
$ file file.tar.gz
file.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
Al hacer lo mismo con el archivo descargado con Chrome o Chromium:
$ file file.tar.gz
file.tar.gz: POSIX tar archive
Tenga en cuenta que Chrome/Chromium obviamente mantuvo el nombre del archivo, pero lo expandió (el tamaño del archivo es ~4 veces mayor que el del archivo descargado con wget).
Como administrador del sitio web, ¿cómo puedo evitar que Chrome/Chromium descomprima el archivo?
Actualizar:
Según curl -I http://mydomain/dir/file.tar.gznuestro combo Apache/Tomcat responde con
Content-Encoding: x-gzip
Chrome no descomprime los archivos probados .tar.gzde otros sitios web y no informan el Content-Encoding: x-gzipencabezado, por lo que parece haber una relación.
Respuesta1
Es probable que su servidor web envíe el .tar.gzarchivo con un content-encoding: gzipencabezado, lo que hace que el navegador web asuma que se aplicó una capa gzip solo para ahorrar ancho de banda y que lo que realmente pretendía enviar era el .tararchivo. Chrome lo descomprime en el otro lado como lo haría con cualquier otro archivo ( ,,, .htmletc. ) que recibe comprimido (aunque obedientemente no modifica el nombre del archivo)..js.css
Para solucionar este problema, asegúrese de que su servidor web proporcione .tar.gzarchivos sin el content-encoding: gzipencabezado.
Más información:https://code.google.com/p/chromium/issues/detail?id=83292
Respuesta2
Según nuestro proveedor de alojamiento, el encabezado Content-Encoding: x-gzipfue causado por Apache delante de nuestro Tomcat. Eliminando la siguiente línea:
LoadModule deflate_module modules/mod_deflate.so
desde su configuración resolvió el problema.