问题描述
我已将我的网站配置为使用gzip压缩来提供静态内容，例如:
I have my website configured to serve static content using gzip compression, like so:
<link rel='stylesheet' href='http://cdn-domain.com/css/style.css.gzip?ver=0.9' type='text/css' media='all' />
我没有看到任何网站在做类似的事情.所以，问题是，这怎么了?我会期待缺点吗?
I don't see any website doing anything similar. So, the question is, what's wrong with this? Am I to expect shortcomings?
准确地说，据我所知，大多数网站都配置为仅在请求包含时提供正常的静态文件(.css，.js等)和压缩后的内容(.css.gz，.js.gz等) Accept-Encoding: gzip标头.当所有浏览器都完全支持gzip时，为什么要这样做?
Precisely, as I understand it, most websites are configured to serve normal static files (.css, .js, etc) and gzipped content (.css.gz, .js.gz, etc) only if the request comes with a Accept-Encoding: gzip header. Why should they be doing this when all browsers support gzip just the same?
PS:我根本看不到任何性能问题，因为在将所有静态内容上传到CDN之前，所有静态内容都已压缩，然后再直接提供压缩后的文件.因此，我的服务器没有压力/紧张.
PS: I am not seeing any performance issues at all because all the static content is gzipped prior to uploading it to the CDN which then simply serves the gzipped files. Therefore, there's no stress/strain on my server.
只要有帮助，以下是gzip压缩CSS文件的HTTP响应标头信息:
Just in case it's helpful, here's the HTTP Response Header information for the gzipped CSS file:
对于gzip压缩的favicon.ico文件，这是这样的:
And this for gzipped favicon.ico file:
推荐答案
支持Content-Encoding: gzip并不是当前任何HTTP规范的要求，这就是为什么存在以请求标头.
Supporting Content-Encoding: gzip isn't a requirement of any current HTTP specification, that's why there is a trigger in the form of the request header.
在实践中?如果您的听众使用的是网络浏览器，而您只担心合法用户，那么只有经过预处理的压缩版本才有可能使所有人受到非常非常微小的影响.这是过去时代的残余.这些天的浏览器应该处理强制馈送的压缩内容，即使他们不要求它，只要您还为它们提供正确的标题即可.重要的是要意识到HTTP请求/响应是一个对话，并且请求中的大多数标头就是这样. 请求.在大多数情况下，另一端的服务器没有义务遵循任何特定的标头，只要它们返回的有效响应对另一端的客户端来说应该尽最大的努力使返回的内容有意义.这包括在服务器响应已使用gzip的情况下启用它.
In practice? If your audience is using a web browser and you are only worried about legitimate users then there is very, very slim to no chance that anyone will actually be affected by only having preprocessed gzipped versions available. It's a remnant of a bygone age. Browsers these days should handle being force-fed gzipped content even if they don't request it as long as you also provide them correct headers for the content being given to them. It's important to realise that HTTP request/response is a conversation and that most of the headers in a request are just that; a request. For the most part, the server on the other end is under no obligation to honor any particular headers, and as long as they return a valid response that makes sense the client on the other end should do their best to make sense of what was returned. This includes enabling gzip if the server responds that it has used it.
但是，如果您的目标是机器消耗，请多加注意.人们仍然认为有时编写自己的HTTP/SMTP/etc解析器是一个聪明的主意，即使该主题已经在多个库中用几乎每种语言都写死了.所有的库都应该很好地支持gzip，但是通常不会使用手动解析器.
If your target is machine consumption however, then be a little wary. People still think that it's a smart idea to write their own HTTP/SMTP/etc parsers sometimes even though the topic has been done to death in multiple libraries for pretty much every language out there. All the libraries should support gzip just fine, but hand-rolled parsers usually won't.
这篇关于直接提供压缩的内容-不好做吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！