使用 Content-Encoding 需要注意的事项：gzip答案

【问题标题】：Things to watch out for with Content-Encoding: gzip使用 Content-Encoding 需要注意的事项：gzip
【发布时间】：2012-08-23 03:20:00
【问题描述】：

我创建了一个托管在 S3 存储桶上的静态网站。我的资产文件（css 和 js 文件）用 gzip 压缩和压缩。文件名本身是file_gz.js 或file_gz.css，并带有Content-Encoding: gzip 标头。

到目前为止，我已经在各种浏览器上测试了该网站，并且运行良好。资产与其压缩版本一起交付，页面看起来没有任何不同。

我看到的唯一问题是，由于这是一个 S3 存储桶，因此当客户端（浏览器）不支持 gzip 编码时没有故障保护。相反，HTTP 请求将失败，并且不会对页面应用样式或 javascript 增强功能。

有没有人知道设置Content-Encoding: gzip有什么问题？所有浏览器都正确支持吗？我需要附加任何其他标题才能使其正常工作吗？

【问题讨论】：

【解决方案1】：

现代浏览器几乎全面支持编码内容。但是，假设所有用户代理都会这样做是不安全的。您的实现的问题在于它完全忽略了 HTTP 的内置方法来避免这个问题：内容协商。您有两种选择：

您可以继续对此问题视而不见，希望每个访问您的内容的用户代理都能够解码您的 gzip 资源。不幸的是，几乎可以肯定情况并非如此。浏览器并不是唯一的用户代理，“头脑风暴”的解决问题的方法很少是一个好主意。
实施一种解决方案，以协商是否使用 Accept-Encoding 标头提供压缩响应。如果客户端根本没有指定此标头，或者指定了它但没有提及 gzip，那么您可以相当肯定用户将无法解码 gzip 后的响应。在这些情况下，您需要发送未压缩的版本。

内容协商的细节超出了这个答案的范围。您需要对如何解析 Accept-Encoding 标头并协商响应的编码进行一些研究。通常，内容编码是通过使用第三方模块（如 Apache 的 mod_deflate）来完成的。虽然我不熟悉 S3 在这方面的选项，但我怀疑您需要自己实施协商。

总而言之：在不先与客户端清除的情况下发送编码内容不是一个好主意。

【讨论】：

感谢您的详细帖子。有什么方法可以为不被接受的内容编码重定向location: ...？
这不是内容协商的工作方式——您不是重定向到另一个版本，而是确定为该特定请求提供哪个版本的内容。不需要重定向。您需要解析 Accept-Encoding 标头的值以确定客户端是否支持 gzip 响应。如果没有请求 Accept-Encoding 标头，则 HTTP 规范要求您以其本机格式（身份）提供资源，无需任何额外编码。
对。但是对于 S3，没有内容协商功能。每个 URL 都映射到一个且只有一个版本的资源。所以我唯一的选择是重定向资源，但看起来不太可能。
就像我说的，我不熟悉 S3 在这方面的能力，但从this answer over at AWS 看来，您需要确定服务器上的编码并重写链接以返回实际内容或执行对 gzip 压缩内容的重定向。无论您如何操作，在发送之前验证客户端是否可以接受编码响应非常重要。

【解决方案2】：

【讨论】：