支持gzip的预冲洗头标签
http://developer.yahoo.com/performance/rules.html
在那里，它是给定的，它是很好的预刷洗头标签。
但我有一个问题，它在使用gzip时会有帮助吗？(我正在使用apache2)。我认为完整的文档将被一次性压缩，然后发送给客户端。
或者也可以使用gzip以及预刷写head标签
回答 1
Stack Overflow用户
发布于 2011-09-09 19:19:24
编辑的
这个问题的原始版本表明我们处理的是HTTP头，而不是超文本标记语言文档的<head>部分。我将在下面留下我的原始答案，但它实际上与这个特定的问题无关。
要回答关于文档的<head>部分的预刷新的问题-虽然可以与gzip结合使用，但如果没有比Apache提供的更细粒度的gzip进程控制，这可能是不可能的。可以将一个gzip流分解成可以自己解压的块(see this)，但是如果有一种方法可以控制Apache的gzip实现到这样的程度，那么我不知道它是什么。
这样做可能会降低gzip的效率，使压缩大小变得更大，并且只有当文档的<head>特别大时才值得这样做，例如，大于10KB (这是我通过阅读有关gzip如何在引擎盖下工作而得出的一个有点随意的值，绝对不应该被视为福音)。
原始答案，与HTTP标头相关：
纯粹从HTTP协议的角度来看，而不是确切地说在基于Apache的服务器上如何实现它，我看不出有什么理由不能预刷出头文件并使用gzip压缩正文。请记住，标头永远不会被gzipped压缩(如果是，客户端如何知道它们已经被压缩了？)，内容的传输编码不应该对您何时发送标头产生任何影响。
然而，有几件事需要牢记：
- 一旦发送了标头，您就不能改变传输编码的想法。因此，如果你发送的头部声明正文将被gzip压缩，然后意识到你的正文只有4个字节，你仍然需要用gzip压缩它，这实际上会增加正文的大小。这可能不是问题，除非您省略了
Content-Length:头，这虽然可能，但这是不好的做法，因为它意味着您不能使用持久连接。这就引出了下一点…… - 在这段代码中，你不能发送
Content-Length:头。这是因为你不知道正文的大小，直到你压缩了它，这个时候它已经准备好发送了，所以你并没有真正(从服务器的角度来看)预刷新头，即使你在开始发送正文之前将它们分开发送。 - 如果你花了很长的时间来压缩消息的正文(慢/重负载的服务器，非常大的正文等)，并且直到你发送了头之后才开始压缩，客户端可能会超时等待响应的其余部分。这完全取决于客户端，但是有如此多的HTTP客户端实现，这种可能性是不能完全打折扣的。
简而言之，是的，这是可能的，但没有一个通用的答案，“是，做”或“不，不要做”-你是否会做它取决于每个请求和它的响应的性质。
https://stackoverflow.com/questions/7359790
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号