?原文出自http://mark.koli.ch/2010/09/understanding-the-http-vary-header-and-caching-proxies-squid-etc.html
作者是Mark S. Kolich

就是簡單的對vary進行一下介紹，方便大家理解，下面是一個簡單的翻譯

我從來沒有過多關注http的vary header。事實上，我非常幸運在過去的很長時間避開了它給我帶來的問題，所以就沒引起我的關注，但是，如果你最終要配置一個高性能的反向代理服務器，那么理解vary header并且它對于你的緩存策略意味著什么事非常有必要的。 下面是一個關于我最近處理關于squid，apache的一個有趣的問題，并且這個問題很難找出竟然是和vary response header有關。

1 關于vary的一些基本信息

?

流行的緩存代理服務器，像squid，通常會根據請求的URI和vary response header的內容產生一個hash值。當緩存服務器接收到一個請求的時候，它會根據輸入產生一個hash，之后檢查緩存看是否已經有這個資源在硬盤上或者在內存中匹配這個hash值。緩存服務器以此來判斷命中與否。 而vary response header告訴緩存服務器使用什么判斷一個請求的資源是fresh還是stale的，一個簡單的vary header包括： Vary: Accept-Encoding Vary: Accept-Encoding,User-Agent Vary: X-Some-Custom-Header,Host Vary: *

　　

根據http標準，vary 的值表明需要哪些request header去充分決定一個response是否是fresh的，緩存服務器是否可以不用重新確認就使用一個reponse。

2 緩存遇到的問題

?

我配置squid作為一個輪詢的負載均衡服務器和一個反向代理緩存服務器，在apache服務器的前面，每個apache服務器都運行著我的web應用，我嚴格配置squid緩存.json文件24個小時。 我打開了一個web瀏覽器，我訪問了一個我認為已經被緩存的URL。 GET /path/big.json HTTP/1.1 Host: app.kolich.local User-Agent: Firefox HTTP/1.0 200 OK Date: Fri, 24 Sep 2010 23:09:32 GMT Content-Type: application/json;charset=UTF-8 Content-Language: en-US Vary: Accept-Encoding,User-Agent Age: 1235 X-Cache: HIT from cache.kolich.local X-Cache-Lookup: HIT from cache.kolich.local:80 Content-Length: 25090 Connection: close 很好，它已經被緩存了，然后我在另一臺機器上打開了第二個web瀏覽器（注：是一個不同類型的瀏覽器），這一次，注意一下X-Cache:MISS GET /path/big.json HTTP/1.1 Host: app.kolich.local User-Agent: Chrome HTTP/1.0 200 OK Date: Fri, 24 Sep 2010 23:11:45 GMT Content-Type: application/json;charset=UTF-8 Content-Language: en-US Vary: Accept-Encoding,User-Agent Age: 4 X-Cache: MISS from cache.kolich.local X-Cache-Lookup: MISS from cache.kolich.local:80 Content-Length: 25090 Connection: close

?

wow,看看它，我請求了一個完全一樣的資源，只是從一個不同的瀏覽器上，現在我看到了一個MISS。這肯定不是我想看到的結果，我當然需要需要同樣的緩存對象而無論到底是誰請求了這個資源。如果就這樣放著的話，這個緩存服務器只會是一個每一個瀏覽器都會有一份拷貝的緩存，而不是一個全局的緩存。

3 解決方案，檢查你的vary header

?

觀察上面兩個請求，注意User-Agent header和Vary header，雖然兩個請求都是請求同一個資源，但是squid把這個兩個請求看做是不同的了，這是怎么發生的呢，我們看一下Vary header: Vary: Accept-Encoding,User-Agent 它告訴squid請求的URI，Accept-Encoding header和User-Agent header應該包括在hash值內去決定在緩存上的對象是可用的。很明顯的，任何一個（URI,?Accept-Encoding,"Firefox"）組合的hash值和(URI, Accept-Encoding, "Chrome")組合產生的hash值都是不匹配的，所以squid才認為這兩個請求是請求不同的內容的。 為了解決這個問題，我找到了煩人的附加在我的Vary response header上的User-Agent是從哪來的，原來是在apache自帶的mod_deflate模塊，推薦的mod_deflate的配置包括如果一個response沒有被mod_deflate壓縮話就默認附加User-Agent在Vary header后面。這是推薦的apache配置中關于mod_deflate的相關行： SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary Header append Vary User-Agent env=!dont-vary

?

我刪除掉了上面的這兩行，重啟了apache然后squid會忽略掉請求的瀏覽器客戶端的類型。本質上說，我通過移除Vary header中的User-Agent告訴squid不要再去關心用戶的瀏覽器類型，然后問題就解決了。 轉載自http://shunter.blog.51cto.com/2183398/1076521

轉載于:https://www.cnblogs.com/engeng/articles/5981582.html

總結

以上是生活随笔為你收集整理的http请求报文头部vary信息的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。