直接提供gzip压缩内容——是一件不好的事情吗？

Question

直接提供gzip压缩内容——是一件不好的事情吗？

23

我已经配置了我的网站以使用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 之前进行了压缩，然后 CDN 只需提供已压缩的文件即可。因此，我的服务器没有任何压力。

如果有帮助的话，这是压缩后的 CSS 文件的 HTTP 响应标头信息：

还有这个压缩后的 favicon.ico 文件的标头信息：

- its_me

PS：可能是重复问题，我知道——但那个问题已经很多年了，基于浏览器支持性的答案不再相关，个人认为。 - its_me

为什么它们不再相关？我仍然坚持我的答案：所有现代浏览器都支持接收gzipped内容进行传输。服务器端如何预处理内容是无关紧要的。你正在做一些聪明的事情，但这并不是一个新问题。只要您的服务器在经过处理后仍然发送正确的标题，您就会完全没问题。即使您没有发送所有正确的标题，浏览器现在甚至也可以为您保存。 - Matthew Scharley

1

作为参考，许多网站确实会这样做，但大多数不会保留“.gzip”后缀（技术上应该只有“.gz”）。 - Matthew Scharley

@MatthewScharley，问题在于我认为这个问题不仅仅是浏览器的问题，我相信这并没有被广泛采用（我不知道确切的原因是什么）。是的，所有现代浏览器都非常好地支持gzip。所以，浏览器端或移动设备上没有问题。PS 我更新了我的问题并添加了一些信息。 - its_me

1

亚马逊返回的一切都很好，所以你应该没问题。我想不出任何设备不支持“Content-Encoding: gzip”的原因，这是一个非常常用的机制。正如我已经提到的，对于gzip压缩的预处理文件并不是一个新的想法（特别是考虑svgz），但大多数主机将被设置为在没有依赖于文件名后缀的情况下透明地处理它。你真的有问题吗？如果是这样，你能强调一下吗？目前我完全没有理解你问题中的问题。 - Matthew Scharley

@MatthewScharley 请检查一下我的更新后的问题是否更加清晰明了。 :) - its_me

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matthew Scharley · Accepted Answer

支持Content-Encoding: gzip不是任何当前HTTP规范的必要条件，这就是为什么有一个请求头形式的触发器。

实际上呢？如果你的受众使用的是Web浏览器，并且你只担心合法用户，那么只提供预处理过的gzipped版本几乎不会对任何人产生影响。这是早期的剩余物。现在的浏览器应该能够处理被强制喂食的gzipped内容，即使他们没有请求，只要你还为它们提供正确的内容头。需要注意的是，HTTP请求/响应是一次对话，请求中的大部分头信息只是请求而已。在很大程度上，另一端的服务器没有义务遵守任何特定的头信息，只要返回一个有效的、有意义的响应，另一端的客户端应该尽力理解所返回的内容。这包括当服务器响应使用了gzip时启用gzip。

但是，如果你的目标是机器消费，那就要小心了。有些人仍然认为编写自己的HTTP/SMTP等解析器是个好主意，即使这个话题已经被多个库用各种语言实现了。所有这些库都应该支持gzip，但自己编写的解析器通常不会。