A companion ASP.net from 1.0 to 4.0 OutputCache Bug Introduction _ Practical Tips

Let's get a glimpse of this bug!

Add the OutputCache setting in an. aspx file with the following code:

Copy Code code as follows:

<%@ OutputCache duration= "*" varybyparam= "*"%>

The above setting means that the cache is cached for 5 minutes, and the cache is updated according to different query strings. Location uses the default value of any, that is, can be in the browser, proxy server, Web server three places to cache, in Response headers embodiment is cache-control:public, max-age=300. (If you want to use CDN to accelerate, Cache-control will use public).

We then visit this page in the Firefox browser and open Firebug, as shown in the following figure:

First visit, return status code for "OK", normal. Here, the vary:accept-encoding in response headers is because IIS enables dynamic content compression, and if it is not enabled, it does not occur.

Then the cache should be built up, we press F5 to refresh the browser, look at the results, see the following figure:

Second access, the return status code is "304 not Modified", and the browser cache is in effect, which is what we expect.

However, please note the vary:* in the figure above, it will disable the browser cache, we click F5 to verify.

Sure enough, the browser cache failed, the return status code changed back to OK. The cache time is 5 minutes, the third time is invalid, such a result is obviously not what we expect.

The above test is done with IIS enabled for dynamic content compression on the Web server, and if dynamic content compression is turned off, each request return is an asterisk ok,vary. This means that the browser browsing cache does not work at all.

After the bug is finished, we'll do a second Test.

Set the OutputCache VaryByParam property value to None:

Copy Code code as follows:

<%@ OutputCache duration= "varybyparam=" "None"%>

The test results show that after the first request of the browser, the server's response in the cache time is "304 not Modified", which is the effect we want.

However, in practical applications, we use varybyparam= "none" very little, with more to specify the corresponding value for VaryByParam.

So this bug has a big impact, increases the server burden, and wastes bandwidth.

Bug Related Information

This bug--"Output Caching Changes to Vary * HTTP Header" is specifically mentioned in Microsoft's official document ASP.net 4 breaking Changes:

In ASP.net 1.0, a bug caused cached pages so specified location= "ServerAndClient" as a output–cache setting to emit a V ary:* HTTP header in the response. This is had the effect of telling client browsers to never cache the page locally.

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

In ASP.net 4, the decision is 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 are no longer needed in order to suppress the vary:* header.

In applications so specify location= "ServerAndClient" in the @ OutputCache directive on a page, you'll now the BEH Avior implied by the name of the Location "s value–that is, the pages would be cacheable in the browser without Iring that's call to the Setomitvarystar method.

From the above document we can know the history of this bug:

When ASP.net 1.0, if location= "ServerAndClient" is set in OutputCache, the ASP.net HTTP header is sent by the browser in response.

At ASP.net 1.1, Microsoft provided a dedicated method for this bug System.Web.HttpCachePolicy.SetOmitVaryStar (bool omit), via Setomitvarystar (true) Modify the HTTP header to remove the vary:*.

At asp.net 4 o'clock, Microsoft solemnly announced that it had fundamentally solved the problem.

Also, the bug mentioned in the document will only appear when location= "ServerAndClient".

However, I use the ASP.net 4 real test situation is: not only location= "ServerAndClient" when the bug is not resolved, and location= "any" will also appear the same bug.

Solving method

The solution is simple, as long as the System.Web.HttpCachePolicy.SetOmitVaryStar (bool omit) provided by the ASP.net 1.1 era solves the problem, simply add the following code to the Page_Load:

Copy Code code as follows:

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 bugs, and the solution is simple. However, if you do not know the bug, you will be caught in a Microsoft scam (previously mentioned a WCF client scam), unknowingly wasted server resources and bandwidth.

Microsoft is so rich, there are so many gifted programmers, but bugs are also difficult to avoid, it can be seen that the development of good software is how challenging work!

Add

This problem does not exist in ASP.net MVC.