Firefox fails to decompress gzip files

Question

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?

Answer 1

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.