Firefox无法解压缩gzip文件 [英] Firefox fails to decompress gzip files

问题描述

我有AWS S3上存储的.gz文件。

使用s3 REST-API，我正在生成指向单个文件的已验证链接。我还设置了内容头选项，以便浏览器请求这些URL将解压并下载gzip文件作为附件。

生成的s3 url如下所示：

/ p>

  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 
& amp; response -content-encoding = gzip 
& response-content-type = application％2Foctet-stream 
& x-amz-security-token = MY_TOKEN 
  

链接的行为如下所示：（OSX上的所有）Chrome（42.0.2311），Safari（8.0.6），Opera（29.0）但是不是Firefox（38.0.1）

Firefox正确下载并重命名文件，但是无法解压gzip文件。

一个GET请求的响应头部到认证的URL看起来像这样：

  Accept-Ranges：bytes 
 Content-Disposition：attachment;文件名=file.ext
内容编码：gzip 
内容长度：928 
内容类型：application / octet-stream 
日期：SOME_DATE_TIME 
 ETag ：MY_ETAG
 Last-Modified：SOME_OTHER_DATE_TIME 
服务器：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 
  

Firefox是否查找不同的标题和/或标题值来指示解压缩？

解决方案

从文件名末尾删除 .gz 。

设置<$ c $是一种常见的错误配置c>内容编码：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.

这篇关于Firefox无法解压缩gzip文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！