上面的設(shè)置表示：緩存5分鐘，根據(jù)不同的查詢字符串更新緩存。Location使用的是默認值A(chǔ)ny，也就是可以在瀏覽器、代理服務(wù)器、Web服務(wù)器三個地方進行緩存，在Response Headers中的體現(xiàn)就是Cache-Control:public, max-age=300。（如果你要用CDN加速，Cache-Control就要用public）。

然后，我們在Firefox瀏覽器中訪問這個頁面，并打開Firebug，見下圖：

第一次訪問，返回狀態(tài)碼為"200 OK"，正常。這里Response Headers中的Vary:Accept-Encoding是因為IIS啟用“動態(tài)內(nèi)容壓縮”產(chǎn)生的，如果不啟用，就不會出現(xiàn)。

這時緩存應(yīng)該被建立起來了，我們按F5刷新一下瀏覽器，看一下結(jié)果，見下圖：

第二次訪問，返回狀態(tài)碼為"304 Not Modified"，瀏覽器緩存生效，這也是我們期望的。

但是，請注意一下上圖中的Vary:*，它會讓瀏覽器的緩存失效，我們再按一下F5驗證一下。

果然，瀏覽器緩存失效，返回狀態(tài)碼變回了200 OK。緩存時間有5分鐘呢，第三次就失效了，這樣的結(jié)果顯然不是我們期望的。

上面的測試是在Web服務(wù)器上IIS啟用動態(tài)內(nèi)容壓縮（dynamic content compression）的情況下進行的，如果關(guān)閉動態(tài)內(nèi)容壓縮，每次請求返回都是200 OK，Vary都是星號。也就是說瀏覽器游覽緩存根本沒起作用。

Bug欣賞完畢，我們進行第二個測試。

將OutputCache的VaryByParam屬性值設(shè)置為none：

測試結(jié)果顯示，瀏覽器第一次請求之后，接下來在緩存時間內(nèi)，服務(wù)器的響應(yīng)都是"304 Not Modified"，這才是我們想要的效果。

但是，在實際應(yīng)用中，我們使用VaryByParam="none"很少，用的更多的是為VaryByParam指定對應(yīng)的值。

所以這個Bug影響很大，增加了服務(wù)器負擔(dān)，浪費了帶寬。

Bug相關(guān)信息

在微軟的官方文檔ASP.NET 4 Breaking Changes中專門提到了這個bug —— "Output Caching Changes to Vary * HTTP Header":

In ASP.NET 1.0, a bug caused cached pages that specified Location="ServerAndClient" as an output–cache setting to emit a Vary:* HTTP header in the response. This had the effect of telling client browsers to never cache the page locally.

In ASP.NET 1.1, the System.Web.HttpCachePolicy.SetOmitVaryStar method was added, which you could call to suppress the Vary:* header. This method was chosen because changing the emitted HTTP header was considered a potentially breaking change at the time. However, developers have been confused by the behavior in ASP.NET, and bug reports suggest that developers are unaware of the existing SetOmitVaryStar behavior.

In ASP.NET 4, the decision was made to fix the root problem. The Vary:* HTTP header is no longer emitted from responses that specify the following directive:

<%@OutputCache Location="ServerAndClient" %>

As a result, SetOmitVaryStar is no longer needed in order to suppress the Vary:* header.

In applications that specify Location="ServerAndClient" in the @ OutputCache directive on a page, you will now see the behavior implied by the name of the Location attribute's value – that is, pages will be cacheable in the browser without requiring that you call the SetOmitVaryStar method.

從上面的文檔中我們可以知道這個Bug的歷史：

在ASP.NET 1.0時，如果在OutputCache中設(shè)置Location="ServerAndClient"，在ASP.NET在響應(yīng)時會瀏覽器發(fā)送Vary:* HTTP header。

在ASP.NET 1.1時，微軟針對這個Bug，提供一個專門的方法System.Web.HttpCachePolicy.SetOmitVaryStar(bool omit)，通過SetOmitVaryStar(true)修改HTTP header，去掉Vary:*。

在ASP.NET 4時，微軟鄭重地宣布從根本上解決了這個問題。

而且，文檔中提到這個bug只會出現(xiàn)在Location="ServerAndClient"時。

可是，我用ASP.NET 4的實測試情況是：不僅Location="ServerAndClient"時的Bug沒有解決，而且Location="Any"時也會出現(xiàn)同樣的Bug。

解決方法

解決方法很簡單，只要用ASP.NET 1.1時代提供的System.Web.HttpCachePolicy.SetOmitVaryStar(bool omit)就能解決問題，只需在Page_Load中添加如下代碼：

相關(guān)文檔

ASP.NET caching tests find a bug with VaryByParam

How to cache asp.net web site for better performance

Microsoft Connect: The ServerAndClient parameter with the OutputCache page directive does not cache on the client, without code

小結(jié)
小bug，解決方法也很簡單。但是，如果你不知道這個bug，又會陷入微軟的一個騙局（之前提到一個WCF Client的騙局），不知不覺中浪費了服務(wù)器資源與帶寬。

微軟那么有錢，有那么多天才程序員，可是Bug也很難避免，可見開發(fā)優(yōu)秀的軟件是多么具有挑戰(zhàn)性的工作！

補充

ASP.NET MVC 中不存在這個問題。

最新評論