我将我的网站配置为使用 gzip 压缩来提供静态内容，如下所示：
<link rel='stylesheet' href='http://cdn-domain.com/css/style.css.gzip?ver=0.9' type='text/css' media='all' />
我没有看到任何网站做类似的事情。所以，问题是，这有什么问题？我可以期待缺点吗？
准确地说，据我了解，大多数网站都配置为仅在请求带有Accept-Encoding: gzip标头时才提供普通静态文件（.css、.js 等）和压缩内容（.css.gz、.js.gz 等）。当所有浏览器都支持相同时，他们为什么要这样做gzip？
PS：我根本没有看到任何性能问题，因为所有静态内容在上传到 CDN 之前都经过 gzip 压缩，然后 CDN 只是提供 gzip 压缩的文件。因此，我的服务器上没有压力/紧张。
以防万一，这是 gzip 压缩的 CSS 文件的 HTTP 响应标头信息：
这适用于 gzip 压缩的 favicon.ico 文件：
支持Content-Encoding: gzip不是任何当前 HTTP 规范的要求，这就是为什么以请求标头的形式存在触发器的原因。
在实践中？如果您的受众正在使用 Web 浏览器，而您只担心合法用户，那么只有经过预处理的 gzip 压缩版本可用，任何人实际上都会受到影响的可能性非常非常小。这是一个过去时代的残余。这些天的浏览器应该处理强制输入的 gzip 内容，即使他们不请求它，只要您还为他们提供正确的标题来提供给他们的内容。重要的是要意识到 HTTP 请求/响应是一个对话，并且请求中的大多数标头就是这样；一个请求. 在大多数情况下，另一端的服务器没有义务尊重任何特定的标头，只要它们返回有意义的有效响应，另一端的客户端就应该尽最大努力理解返回的内容. 这包括在服务器响应它已使用 gzip 时启用 gzip。
但是，如果您的目标是机器消耗，请小心。人们仍然认为有时编写自己的 HTTP/SMTP/etc 解析器是一个聪明的主意，尽管该主题已经在多个库中为几乎所有语言完成了死亡。所有的库都应该很好地支持 gzip，但手动解析器通常不会。