Overview ASP. NET built-in HttpCachePolicy

Page Cache

In ASP. NET, if you need to add HTTP attributes, you can use the HttpResponse. AppendHeader method. For example, you can directly execute Response. AppendHeader in the Page code. The HttpResponse. AddHeader method is equivalent to this method, but it is only used for compatibility with ASP code. Therefore, it is recommended that you do not use it. By using the AppendHeader method, you can write the Last-Modified attribute and ETag attribute to the response.

Next we will consider how to read the above attributes from the request and then determine how to return them. We can use HttpRequest. serverVariables reads the attribute in the request and compares it with the current value. If the comparison result shows that the content does not change, we can set HttpResponse. statusCode is 304, and then null content is returned. If the comparison result shows that the content has changed, the whole response is still completed in the normal way.

This is troublesome, right? So ASP. NET built-in HttpCachePolicy class, so that we can directly control the relevant attributes, we can use HttpResponse. the Cache accesses this type of instance, and if we are on the Page, we can directly access this type of instance through Reponse. cache to access it. The usage of this class is described in detail in MSDN, so I will not explain it any more. Because its implementation also relies on the above HTTP attribute, when using the AppendHeader to control the above attribute, it will destroy the settings in HttpCachePolicy, if you have set them ). Therefore, we recommend that you use only one of the two methods, AppendHeader and HttpCachePolicy for indirect control at the same time. If you need flexibility, use the former. If you need simple settings, use the latter.

Resource Cache

ASP. NET has built-in HttpCachePolicy and Cache, which makes the Page Cache convenient enough. So let's take a look at how to Cache non-pages. In fact, the maximum number of requests for resource files such as js and css is much larger than that of Page, because a Page is usually linked to several resource files.

Compile embedded Resources

Let's take a look at how the compilation control caches resources. Many of the controls that come with the system have resources, because they need these images, scripts, or styles to ensure their normal operation. These resources are embedded into the dll during compilation, these resources will be included wherever the control is released. These resources embedded in the dll are referenced in a specific form. when the control is rendered as HTML code, it becomes a link starting with WebResource. axd. For example:

 
 

  
  
<script 
  
  
src="/WebResource.axd?d=7wVzVzBOs3_HEjhM5umRSQ2&amp;t=632962899860156250" 
  
  
type="text/javascript"> 
  
  
</script> 
 
 

The WebResource. axd is registered for processing by AssemblyResourceLoader. This IHttpHandler is responsible for extracting the resource files from the dll and returning them to the client.

Pay attention to WebResource. the two parameters after axd. d indicates the resource, which indicates the resource in the current request. t indicates the timestamp of the last compilation of the dll, if the dll is re-compiled, t will change. This will let the browser know that this is a new URL and should not use the original cache.

It should be emphasized that this is not a compatibility practice. It can only ensure that the cache expires when the resource is updated, but cannot ensure that the resources that are not updated are successfully cached. According to RFC2616, browser operations are classified into two categories: security and insecurity. GET and HEAD should be safe, because they do not affect the outside world except for obtaining information; POST, PUT, and DELETE are insecure because they affect the outside world. Therefore, when you refresh the POST page, the browser will prompt you to confirm whether to submit data again. As mentioned in RFC2616, the client has the right to directly obtain the cache to display security operations unless the server explicitly declares that they have expired, this is because whether the client is obtained from the service period or from the cache, it should not affect the outside world, except in one case-that is, when QueryString exists in the URL.

When QueryString exists in the URL, this request is considered to have an impact on the outside world. Therefore, when the client initiates this request, the request must be completed on the server, that is, the cache is not allowed. RFC2616 says so, but not every browser does. IE and Firefox violate RFC2616 to cache the URL with QueryString, while Opera and Safari follow this rule to get the content again each time. That is to say, ASP.. NET resource addresses will never be cached in Opera and Safari, such as your ASP. NET application in MasterPage using ASP.. net ajax ScriptManager. The script files related to each page must be downloaded again.

Non-compiled embedded Resources

If we are currently writing an ASP. NET website, some resources exist directly in the form of files, instead of compiling and embedding them in the dll, so we cannot enjoy the convenience provided by the above system, however, we can implement a similar mechanism by ourselves and avoid the issue that some Browsers Do not cache resources. The above introduces ASP. NET built-in HttpCachePolicy

1. Microsoft released multiple function updates for ASP. net mvc 2 preview Edition
2. ASP. NET Server custom control security guidelines
3. Analysis of ASP. NET programming standards and Their encoding specifications
4. Introduction to ASP. NET sessions
5. ASP. NET programming tool ASP. NET Web Matrix