直接提供gzip压缩内容 - 不好的事情要做?

its*_*_me 20 gzip static-content

我的网站配置为使用gzip压缩服务静态内容,如下所示:

<link rel='stylesheet' href='http://cdn-domain.com/css/style.css.gzip?ver=0.9' type='text/css' media='all' />
Run Code Online (Sandbox Code Playgroud)

我没有看到任何网站做类似的事情.所以,问题是,这有什么问题?我期待缺点吗?

准确地说,据我所知,大多数网站都配置为仅在请求带有Accept-Encoding: gzip标头时才提供普通静态文件(.css,.js等)和gzip压缩内容(.css.gz,.js.gz等).当所有浏览器都支持gzip相同时,他们为什么要这样做呢?

PS:我没有看到任何性能问题,因为所有静态内容在上传到CDN之前都被gzip压缩,然后CDN只提供gzip压缩文件.因此,我的服务器没有压力/压力.


为了防止它有用,这里是gzip压缩的CSS文件的HTTP Response Header信息:

截图1

这对于gzip的favicon.ico文件:

截图2

Mat*_*ley 26

支持Content-Encoding: gzip不是任何当前HTTP规范的要求,这就是请求头形式的触发器的原因.

在实践中?如果您的观众使用的是网络浏览器而您只是担心合法用户,那么只有预处理的gzip压缩版本可用,才会真正受到影响.这是过去时代的残余.浏览器这些天应该处理强制馈送gzip压缩内容,即使它们没有请求它,只要你还为它们提供的内容提供正确的标题.重要的是要意识到HTTP请求/响应是一个对话,并且请求中的大多数头都是这样; 一个请求.在大多数情况下,另一端的服务器没有义务遵守任何特定的标头,只要它们返回一个有意义的有效响应,另一端的客户端应该尽力理解返回的内容. .这包括如果服务器响应它已使用它,则启用gzip.

如果您的目标是机器消耗,那么请稍微警惕.有时候人们仍然认为编写自己的HTTP/SMTP/etc解析器是一个明智的想法,即使这个主题在多个库中已经完成了几乎所有语言的死亡.所有的库都应该支持gzip,但是手动解析器通常不会.

  • @AahanKrish:机器消耗:任何未直接向用户显示的内容.屏幕抓取工具等或类似功能的REST API.解析是用于描述采用一些复杂元素(在这种情况下,例如CSS或HTML文件或HTTP会话)并将其转换为计算机可以直接理解的数据结构或结构的术语."手卷"是指开发人员自己创建的代码,即.不是图书馆. (2认同)