在之前一篇关于apache中进行mod_deflate配置的文章中，我们知道Apache2通过启用mod_deflate压缩模块来对网页组件进行压缩，可以显著的提高网页的下载速度，并为您节省大量的带宽。
当浏览器直接与服务器通信时，“mod_deflate配置”一文中的所介绍的配置都能很好的工作。浏览器直接与服务器通信时，Web服务器基于浏览器的Accept-Encoding来检查是否对响应进行压缩。也就是说，如果浏览器可以识别gzip格式的压缩文件，那么Web服务器就会发送经过压缩的网页内容给浏览器。反之，如果浏览器的Accept-Encoding中明确不能接受gzip格式的压缩文件，那么Web服务器就会发送不经过任何压缩的网页内容。
但是，当浏览器通过代理来发送请求时，情况就变得复杂了。
假设针对某个URL发送到代理的第一个请求来自一个不支持gzip的浏览器。这是到达代理的第一个请求，因此其缓存为空。代理会将请求转发到Web服务器。此时服务器的响应时未经过压缩的。这个没有压缩的响应被代理缓存起来并发送给浏览器。
现在，假设到达代理的第二个请求访问的是同一个URL，来自一个支持gzip的浏览器。代理会使用其缓存（未经压缩）的内容进行响应，这就失去了进行压缩的机会。如果顺序相反——第一个请求来自一个支持gzip的浏览器，而第二个请求来自一个不支持gzip的浏览器——情况就很严重。在这种情况下，代理的缓存中拥有一个压缩的内容，并将这个内容提供给后续的浏览器——不管它们是否支持gzip。
上边说了这么多，其实也就是说：仅仅按照“mod_deflate配置”一文中方法对网站内容进行压缩，在用户通过代理进行浏览网站时，有部分浏览器不支持压缩的浏览器就有可能看到一大堆乱码。
解决方案很简单：在Web服务器的响应中添加Vary头。Web服务器可以告诉代理根据一个或多个请求头来改变缓存的响应。
方法一：
通过apache的mod_headers模块设置Vary头
<IfModule mod_headers.c>
<FilesMatch “\.(gif|jpg|js|css|png|ico|swf)$”>
Header set Vary “Accept-Encoding”
</FilesMatch>
</IfModule>
方法二：
通过编程实现，例如PHP
<?php
Header(“Vary: Accetp-Encoding”);
?>
通过Vary的设置，可以使得代理缓存响应的多个版本，为Accept-Encoding请求头的每个值缓存一份。默认情况下，mod_gzip会向所有响应添加Vary: Accept-Encoding头，mod_deflate我不确定，所以我决定还是在apache的配置中增加上这一项。关于Vary有关的更多信息请参阅：http://www.w3.org/Protocols/rfc2616-sec14.html#sec14.44
以上资料主要出自《高性能网站建设指南》，结合自己的实践写的，希望对你有用。
作者： 分类：服务器管理 标签： 时间：2009年10月30日 1,108次浏览
下一篇：爷爷奶奶回海南的日子
更多服务器管理文章>>
家庭会客厅