原文地址：http://www.webkaka.com/blog/archives/how-to-set-Vary-Accept-Encoding-header.html
在webkaka的网站速度诊断性能优化里有一项叫指定“Vary:Accept-Encoding”标头，可能很多人不太明白这是什么意思，不知道它对网站的影响有多大，不知道如何进行优化，为此，本文将给大家阐述下“Vary:Accept-Encoding”标头的意义以及设置方法。
指定“Vary:Accept-Encoding”标头
指定“Vary: Accept-Encoding”标头的意义
指定“Vary: Accept-Encoding”标头，用一句话来说明它的意义，就是“告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题。”不过我想很多人都不理解这句话是什么意思，所以需要更详细的解释。
先来看看下面这幅图：
网页从请求到响应的过程
这个图显示了一个网页从请求到响应的过程。正常情况下，“Response”的结果是可读文本，但并不是所有的服务器端都返回这样的正常的结果到用户端，有的返回一堆乱码，这显然是不正常的。
当浏览器发出一个请求时，会包含一些HTTP头信息，服务器会根据这些头信息决定返回什么样的东西（这是一个移动客户端吗？它能否处理压缩内容？它是否需要特定的语言支持？）。
直接访问是好的，但现在网络使用了中间高速缓存（cache）和内容分发网络（CDN）。这就产生了一个问题，缓存如何使用头信息决定返回什么？它能否复制服务器端的决策逻辑？
“Vary”解决了这个问题，“Vary”头描述什么信息“唯一地”标识一个请求——传入的请求只有完全匹配缓存的“Vary”信息，缓存才被使用。
假如没有“Vary”头，那么如果由于某种原因，客户端有一个未压缩的版本在其缓存中的文件，它会不知道随后再次要求它的压缩版本，而不是只从缓存中使用未压缩的文件。——这就很好的解释了“Vary”头信息的重要意义。
设想有两个客户，一个使用的旧浏览器不支持压缩，一个使用新的浏览器支持压缩，如果他们都请求同一个网页，那么取决于谁先请求，压缩或非压缩版本便存储在CDN上。这样问题就出现了，旧浏览器请求常规网页但获得缓存的压缩版本，而新浏览器会获得缓存的非压缩版本但尝试去“解压”它。无论哪种方式都是坏消息。解决方法是，源服务器回送“Vary: Accept-Encoding”。
现在的中间CDN会存储独立的缓存条目，一个是Accept-encoding: gzip ，而如果你没有发送header，则存储另一个。
标头“Vary:Accept-Encoding”指定方法
现在的新浏览器都支持压缩了，因此如果网站启用了GZip，可以无需再指定“Vary: Accept-Encoding”标头，不过指定“Vary: Accept-Encoding”标头会有更高的保险，而它并不需要你额外的开销，为什么不指定呢？下面是设置方法：
Apache/.htaccess
<IfModule mod_headers.c>
<FilesMatch ".(js|css|xml|gz|html)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>
Nginx
gzip_vary on
IIS
在web.config里加上如下配置，web.config位置在：%windir%\Microsoft.NET\Framework\.net版本号\CONFIG\Web.config 。
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="Vary"></remove>
<add name="Vary" value="Accept-Encoding"></add>
</customHeaders>
</httpProtocol>
</system.webServer>
指定“Vary:Accept-Encoding”标头，网站需要启用GZip，才变得有意义。网站如何启用GZip？可以看看如下的教程：
IIS启用GZip压缩的详细教程【图解】
Nginx 如何配置GZip压缩
如何启用Apache的GZip压缩功能
lighttpd 如何配置GZip压缩
相关文章
IIS启用GZIP压缩css、js无效的原因及解决方法
IIS启用GZip失败之原因：临时目录权限没设好
图片GZip压缩后体积会变大
GZip压缩启动后js css不能运行的解决方法
