HTTP标头“Vary:Accept-Encoding”指定方法及其重要性分析

指定“Vary: Accept-Encoding”标头，用一句话来说明它的意义，就是“告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题。”这句话其实很好理解，但是，我还是想更详细的解释。

先来看看下面这幅图：

这个图显示了一个网页从请求到响应的过程。正常情况下，“Response”的结果是可读文本，但并不是所有的服务器端都返回这样的正常的结果到用户端，有的返回一堆乱码，这显然是不正常的。

当浏览器发出一个请求时，会包含一些HTTP头信息，服务器会根据这些头信息决定返回什么样的东西（这是一个移动客户端吗？它能否处理压缩内容？它是否需要特定的语言支持？）。

直接访问是好的，但现在网络使用了中间高速缓存（cache）和内容分发网络（CDN）。这就产生了一个问题，缓存如何使用头信息决定返回什么？它能否复制服务器端的决策逻辑？

“Vary”解决了这个问题，“Vary”头描述什么信息“唯一地”标识一个请求——传入的请求只有完全匹配缓存的“Vary”信息，缓存才被使用。

假如没有“Vary”头，那么如果由于某种原因，客户端有一个未压缩的版本在其缓存中的文件，它会不知道随后再次要求它的压缩版本，而不是只从缓存中使用未压缩的文件。——这就很好的解释了“Vary”头信息的重要意义。

1. 设想有两个客户，一个使用的旧浏览器不支持压缩，一个使用新的浏览器支持压缩，如果他们都请求同一个网页，那么取决于谁先请求，压缩或非压缩版本便存储在CDN上。这样问题就出现了，旧浏览器请求常规网页但获得缓存的压缩版本，而新浏览器会获得缓存的非压缩版本但尝试去“解压”它。无论哪种方式都是坏消息。解决方法是，源服务器回送“Vary: Accept-Encoding”。
3. 现在的中间CDN会存储独立的缓存条目，一个是Accept-encoding: gzip ，而如果你没有发送header，则存储另一个。

* 标头“Vary:Accept-Encoding”指定方法* 现在的新浏览器都支持压缩了，因此如果网站启用了GZip，可以无需再指定“Vary: Accept-Encoding”标头，不过指定“Vary: Accept-Encoding”标头会有更高的保险，而它并不需要你额外的开销，为什么不指定呢？下面是设置方法：

Apache/.htaccess

1. <IfModule mod_headers.c>
2. <FilesMatch ".(js|css|xml|gz|html)$">
3. Header append Vary: Accept-Encoding
4. </FilesMatch>
5. </IfModule>

Nginx

1. gzip_vary on