gzip - 直接提供压缩后的内容-不好做吗？

Question

我将我的网站配置为使用gzip压缩提供静态内容，如下所示:

<link rel='stylesheet' href='http://cdn-domain.com/css/style.css.gzip?ver=0.9' type='text/css' media='all' />

我看不到任何网站在做类似的事情。所以，问题是，这怎么了？我会期待缺点吗？

确切地说，据我所知，大多数网站都配置为仅在请求带有 Accept-Encoding: gzip header 的情况下提供正常的静态文件(.css，.js等)和压缩内容(.css.gz，.js.gz等) 。当所有浏览器都完全支持 gzip时，为什么要这样做？

PS:我根本看不到任何性能问题，因为在将所有静态内容上载到CDN之前，所有静态内容都被压缩了，然后再直接提供压缩后的文件。因此，我的服务器没有压力/紧张。

以防万一，这是gzip压缩CSS文件的HTTP响应 header 信息:



这是gzip压缩的favicon.ico文件:

Answer 1

当前所有HTTP规范都不需要支持Content-Encoding: gzip，这就是为什么存在请求 header 形式的触发器的原因。

在实践中？如果您的观众使用的是网络浏览器，而您只担心合法用户，那么只有经过预处理的压缩版本才有可能使所有人受到非常非常微小的影响。这是过去时代的残余。这些天的浏览器应该处理强制馈送的压缩内容，即使他们不要求它，只要您还为它们提供正确的标题即可。重要的是要意识到HTTP请求/响应是一个对话，而请求中的大多数 header 就是这样。一个请求。在大多数情况下，另一端的服务器没有义务遵守任何特定的 header ，并且只要它们返回有效的响应即可，该响应是有意义的，另一端的客户端应尽最大努力弄清返回的内容。如果服务器响应已使用gzip，则包括启用gzip。

但是，如果您的目标是机器消耗，请多加注意。人们仍然认为有时编写自己的HTTP / SMTP / etc解析器是一个聪明的主意，即使该主题已经在多个库中用几乎每种语言都写死了。所有的库都应该支持gzip，但通常不会提供手动解析器。