直接服务gzip压缩的内容 - 糟糕的事是什么？(Serving gzipped content d

我有我的网站配置为使用gzip压缩，像这样提供静态内容：

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

我没有看到任何网站做类似的事情。所以，问题是，这有什么错呢？难道我期待缺点？

准确地说，据我所知，大多数网站都配置服务的正常静态文件（的.css，.js文件等）和gzip压缩的内容（.css.gz，.js.gz等），只有当请求带有一个Accept-Encoding: gzip头。为什么他们要这么做时，所有浏览器都支持gzip一样的？

PS：我不是在所有的，因为所有的静态内容之前上传到其中，然后简单地服务于gzip压缩文件的CDN gzip压缩看到任何性能问题。因此，有我的服务器上没有应力/应变。

万一这是有帮助的，这里的HTTP响应头信息的gzip压缩的CSS文件：

而本作gzip压缩的favicon.ico文件：

支持Content-Encoding: gzip没有任何当前的HTTP说明书的要求，这就是为什么没有在请求头的形式的触发器。

在实践中？如果你的听众是使用Web浏览器，你只担心合法用户则有非常非常渺茫没有机会，任何人实际上将只具有预处理gzip压缩的版本会受到影响。这是一个过去的时代的残余。浏览器，这些天应该处理，即使他们不要求它，只要你还为他们提供所给予他们的内容正确的头被强行灌食gzip压缩的内容。要认识到HTTP请求/响应是一个对话及与大多数的请求头都仅仅是这一点很重要; 请求。在大多数情况下，在另一端的服务器是没有义务履行任何特定的头，只要他们回来是有道理的另一端，客户端应该尽自己所能做出的返回是什么意义上的有效响应。这包括启用gzip如果服务器响应它使用了它。

如果你的目标是机器消耗然而，则是有点担心。人们仍然认为这是一个聪明的想法写自己的HTTP / SMTP /等解析器有时即使该问题被做死在多个库的几乎每一种语言在那里。所有的库应该支持gzip就好了，但手挽解析器通常不会。