An OutputCache Bug with ASP. NET from 1.0 to 4.0

Let's take a look at this Bug!

Add OutputCache settings to an. aspx file. The Code is as follows:

<% @ OutputCache Duration = "300" VaryByParam = "*" %>

The preceding settings indicate that the cache is cached for 5 minutes and updated based on different query strings. Location uses the default value Any, that is, Cache can be performed in three places: browser, proxy server, and Web server. In Response Headers, Cache-Control: public, max-age = 300. (If you want to use CDN acceleration, public is required for Cache-Control ).

Then, visit this page in the Firefox browser and open Firebug. For details, see:

For the first access, the returned status code is "200 OK", which is normal. Here, Vary: Accept-Encoding in Response Headers is generated because IIS enables "dynamic content compression". If it is not enabled, it will not appear.

The cache should be created. Press F5 to refresh the browser and check the result. See:

For the second access, the returned status code is "304 Not Modified", and the browser cache takes effect. This is what we expect.

However, pay attention to the Vary: *, which will invalidate the browser cache. Let's press F5 to verify it.

Sure enough, the browser cache is invalid, and the return status code is changed back to 200 OK. If the cache time is five minutes, it will become invalid for the third time. This result is obviously not expected.

The above test is performed when dynamic content compression (dynamic content compression) is enabled in IIS on the Web server. If dynamic content compression is disabled, the 200 OK message is returned for each request, vary is an asterisk. That is to say, browser browsing cache does not work at all.

After the Bug is appreciated, we will perform the second test.

Set the VaryByParam attribute value of OutputCache to none:

<% @ OutputCache Duration = "600" VaryByParam = "none" %>

The test results show that, after the first request by the browser, the server will respond "304 Not Modified" within the cache time, which is what we want.

However, in practice, VaryByParam = "none" is rarely used, and VaryByParam is used to specify the corresponding value.

This Bug has a great impact, increasing the server load and wasting bandwidth.

Bug Information

This bug was mentioned in Microsoft's official document ASP. NET 4 Breaking Changes -- "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 cocould 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 demo-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.

From the above document, we can know the history of this Bug:

In ASP. NET 1.0, if Location = "ServerAndClient" is set in OutputCache, the browser sends the Vary: * HTTP header when ASP. NET responds.

In ASP. NET 1.1, Microsoft provides a dedicated method System for this Bug. web. httpCachePolicy. setOmitVaryStar (bool omit), use SetOmitVaryStar (true) to modify the HTTP header and remove Vary :*.

At ASP. NET 4, Microsoft solemnly announced that it had fundamentally solved this problem.

The bug mentioned in this document only appears when Location = "ServerAndClient.

However, my actual test using ASP. NET 4 shows that not only is the Bug fixed when Location = "ServerAndClient", but also the same Bug occurs when Location = "Any.

Solution

The solution is simple. You only need to add the following code to Page_Load to solve the problem by using System. Web. HttpCachePolicy. SetOmitVaryStar (bool omit) provided in the ASP. NET 1.1 era:

 

Protected void Page_Load (object sender, EventArgs e)

{

Response. Cache. SetOmitVaryStar (true );

}

 

 

Related Documents

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

Summary

Small bug, the solution is also very simple. However, if you do not know this bug, you will be stuck in a Microsoft scam (a previously mentioned WCF Client scam), which will waste your server resources and bandwidth without knowing it.

Microsoft is so rich and has so many talented programmers, but it is difficult to avoid bugs. It can be seen how challenging it is to develop excellent software!

 

Supplement

This issue does not exist in ASP. net mvc.

 

Author: dudu