Shulou(Shulou.com)06/02 Report--

ASP.NET how to carry out built-in HttpCachePolicy, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Page caching

In ASP.NET, if you need to add a HTTP attribute, you can use the HttpResponse.AppendHeader method, for example, to execute Response.AppendHeader directly in the code of Page. The HttpResponse.AddHeader method is equivalent, but only for compatibility with ASP code, so I advise you not to use it. With the AppendHeader method, you can write the above Last-Modified property and ETag property to the return.

Then we consider how to read the above properties from the request and then determine how to return. We can use HttpRequest.ServerVariables to read the properties in the request and compare it with the current value. If the comparison shows that the content has not changed, we can set the HttpResponse.StatusCode to 304 and return the empty content; if the comparison indicates that the content has changed, then complete the whole return in the normal way.

It's troublesome, isn't it? So ASP.NET has a built-in HttpCachePolicy class, which allows us to directly control the relevant properties, we can access instances of this class through HttpResponse.Cache, and if we are in Page, we can access it directly through Reponse.Cache. The use of this class is described in detail in MSDN, so I won't explain it any more. Because its implementation also relies on the above HTTP property, using AppendHeader to control the above property will break the setting in HttpCachePolicy (if you set it). So use only one of the two methods of using AppendHeader directly or indirectly through HttpCachePolicy at the same time, use the former if you need flexibility, and use the latter if you need simple settings.

Resource caching

ASP.NET has built-in HttpCachePolicy and Cache, which makes Page caching convenient enough, so let's take a look at how non-Page caches can be done. In fact, resource files (such as js and css) may have much more requests than Page, because a Page usually links several resource files.

Compile and embed resources

Let's first look at how compiled controls cache resources. Many of the controls that come with the system come with resources because they need these small pictures, scripts, or styles to ensure that they work properly. These resources are compiled to be embedded in dll, and then come with them wherever the control is published. These resources embedded in dll are referenced in a specific form and become WebResource.axd opening links when the control is rendered as HTML code, for example:

WebResource.axd is registered for AssemblyResourceLoader processing, and this IHttpHandler is responsible for extracting the resource file from dll and returning it to the client.

Notice the two parameters after WebResource.axd. D is the resource indicator, which indicates which resource is currently requested; t is the timestamp compiled by the dll***, and t will change if the dll is recompiled, which lets the browser know that this is a new URL and should no longer use the original cache.

It is important to emphasize that this is not a compatible approach, it can only ensure that the cache expires when resources are updated, but not that resources that are not updated are cached successfully. According to RFC2616, browser operations are divided into secure and unsecure, GET and HEAD should be secure, because they do not have any impact on the outside world except to obtain information; POST, PUT and DELETE are unsafe because of their impact on the outside world, so when you refresh the page after POST, the browser will prompt you whether to confirm the submission of data again. As mentioned in RFC2616, the client has the right to directly fetch the cache to display security operations unless the server explicitly declares it to expire, because no matter whether the client is fetched from the server or cached, it should not have any impact on the outside world, except when QueryString exists in the URL.

When there is a QueryString in the URL, the request is considered to have an impact on the outside world, so when the client makes the request, it must be done through the server, that is, caching is not allowed. RFC2616 says so, but not every browser does. IE and Firefox cache URL with QueryString in violation of RFC2616, while Opera and Safari follow this rule to retrieve content every time. In other words, the resource address of ASP.NET will never be cached in Opera and Safari. For example, if your ASP.NET application uses ASP.NET AJAX's ScriptManager in MasterPage, the relevant script files will have to be downloaded again when you open each page.

Uncompiled embedded resources

If we are currently writing an ASP.NET website, some resources are directly in the form of files, not compiled and embedded in dll, then we will not be able to enjoy the convenience provided by the above system, but we can implement a similar mechanism ourselves and avoid the problem that some browsers do not cache resources. The above introduction of ASP.NET built-in HttpCachePolicy

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.