从文件名末尾删除 .gz 。

设置内容编码：gzip 在 .gz 文件上，当您打算让最终用户下载时 - 最后以 - a .gz 文件;例如下载一个 .tar.gz 的源码包。

这不是你正在做的事相反，本质上......但我怀疑你看到了一个企图解决这个问题的症状。

实际上，我描述的配置应该只是当你gzip一个已经gzip的文件（当然，你不应该这样做）的情况下...但是它被（iirc）默认的Apache web服务器配置长期固守。旧的错误报告似乎表明，Firefox开发者很难理解 Content-Encoding：gzip 应该做什么，特别是关于下载。他们有点痴迷，似乎认为浏览器在保存到磁盘时不应该撤销内容编码，因为保存到磁盘与渲染下载的内容不同。对我来说，这是一个废话，对RFC的过于直接的解释。

我怀疑你看到的是这个老问题的遗产。 b
$ b

与您的概念相反，使用 Content-Encoding存储文件是非常正确的：gzip .gz 扩展名......实际上，如果没有 .gz code>扩展名，因为 .gz 意味着（至少对于Firefox来说）下载用户应该想要下载压缩的内容并以压缩格式保存。

I have .gz files stored on AWS s3.

Using the s3 REST-API, I'm generating authenticated links that point to individual files. I'm also setting the content-header options such that browsers requesting these urls will decompress and download the gzipped files as attachments.

The generated s3 url looks like so:

https://MY_BUCKET.s3.amazonaws.com/PATH_TO/file.ext.gz
  ?AWSAccessKeyId=MY_KEY
  &Expires=DATE_TIME
  &Signature=MY_SIGNATURE
  &response-content-disposition=attachment%3B%20filename%3D%22file.ext%22
  &response-content-encoding=gzip
  &response-content-type=application%2Foctet-stream
  &x-amz-security-token=MY_TOKEN

The links behave as expected in: (All on OSX) Chrome (42.0.2311), Safari (8.0.6), Opera (29.0),

but NOT Firefox (38.0.1)

Firefox downloads and renames the file correctly but fails to decompress the gzipped file.

The response headers of a GET request to the authenticated urls look like so:

Accept-Ranges:bytes
Content-Disposition:attachment; filename="file.ext"
Content-Encoding:gzip
Content-Length:928
Content-Type:application/octet-stream
Date:SOME_DATE_TIME
ETag:"MY_ETAG"
Last-Modified:SOME_OTHER_DATE_TIME
Server:AmazonS3
x-amz-expiration:expiry-date="ANOTHER_DATE_TIME"
x-amz-id-2:MY_AMZ_ID
x-amz-request-id:MY_AMZ_REQUEST_ID
x-amz-server-side-encryption:AES256

Does Firefox look for different headers and/or header values to indicate decompression?

The solution appears to be removing .gz from the end of the filename.

It's a common misconfiguration to set Content-Encoding: gzip on .gz files when you intend for the end user to download -- and end up with -- a .gz file; e.g. downloading a .tar.gz of source package.

This isn't what you are doing... It's the opposite, essentially... but I suspect you're seeing a symptom of an attempt to address that issue.

In fact, the configuration I described should only be the case when you gzipped an already-gzipped file (which, of course, you shouldn't do)... but it was entrenched for a long time by (iirc) default Apache web server configurations. Old bug reports seem to suggest that the Firefox developers had a hard time grasping what should be done with Content-Encoding: gzip, particularly with regard to downloads. They were a bit obsessed, it seems, with the thought that the browser should not undo the content encoding when saving to disk, since saving to disk wasn't the same as "rendering" the downloaded content. That, to me, is nonsense, a too-literal interpretation of an RFC.

I suspect what you see is a legacy of that old issue.

Contrary to your conception, it's quite correct to store a file with Content-Encoding: gzip without a .gz extension... arguably, in fact, it's more correct to store such content without a .gz extension, because the .gz implies (at least to Firefox, apparently) that the downloading user should want the compressed content downloaded and saved in the compressed form.