304 Not modified code and principle for ASP.

From the previous example, we have seen the benefits of caching: it is possible to reduce access to the server, because the server can display the page, which for the server, can alleviate some of the access pressure. However, if the user forces the browser to refresh, the browser will ignore the cached page and re-initiate the request directly to the server.

That is, the cached page is not valid when the user forces the browser to refresh.
However, we use cached pages because we want to tell the browser that the data does not change for a certain amount of time, so there is no need to request the server again. However, we cannot prevent users from behaving. Because of the browser re-visit, we originally conceived the idea of caching will be frustrated, the final result is: The page is re-executed in the server, the resulting HTML code will be sent back to the client. The result of this re-refresh may also be meaningless, because the data may not have changed at all, so the resulting page is not likely to change.

Let me give you a simple example: The client wants to browse for a picture. When the browser first to access the picture, the browser must not have any of its cache record, at this time it to access the server, the server also returned the contents of the picture. However, since a picture may be referenced by multiple pages, the likelihood of its being modified is very small. Therefore, it is not necessary to read the picture and return the contents of the picture for multiple requests from the same browser, which both affect performance and waste bandwidth. As a result, server software such as IIS, for such static file access, will output some tags on the response header, to tell the browser of this file you can cache it up.

Or go back to the "user forced refresh" issue that was mentioned earlier, what happens to IIS now? Please see:

Note that no data is returned except that the HTTP status code becomes 304.

To give you a deep impression of the 304 response, I intercepted a picture with a status code of 200 responding to the result:

Through the comparison of these two pictures, now see clearly:304 and 200 is not only the difference between the numbers, the most important difference is whether there is no return results.

No results returned, how should the browser be displayed?
Do you have any doubts about that?
Don't worry, the browser will use its cached version to display it. In other words: no matter how the user forced the brush, the server will not return the results, but still can display normally.

Obviously, this effect is what we want.
The above mentioned cache page is the user's strong brush problem, if this method, it is more perfect.
However, one thing I would like to remind you is that the WebDev.WebServer.exe that comes with Visual Studio does not support 304 responses, so you should not experiment with it, and there will be no results.

Back to top how to programmatically implement 304 responses

We saw the effect of 304 response in the front. However, in ASP. NET, we develop a program that is a dynamic page, not a picture, we prefer a page to be cached in this way for a period of time, I think this need may be more meaningful.

Below, I'll show you how to implement it programmatically.
In the next example, the page is displayed in the same sample, showing the time the page was generated on the server, and the time changed, indicating that the page was re-executed.

To re-intercept a series of pictures, I think the meaning is not big, I cut a picture to show the process of several strong brushes

Reflecting the process of requesting an ASPX page several times, as you can see from the picture, only the first response is 200, followed by a total of 304, which is the result you expect.

Let's take a look at its implementation code:

Although the code is not complicated, I would like to explain:
When the browser requests the page for the first time, it executes the setlastmodified call, which outputs a "last-modified" response header in response, and then, when the browser accesses the page again, the "last-modified" header obtained from the last request content , in the form of "if-modified-since" This request header to the service side, the server can be based on the specific logic to determine whether to use the 304 answer.

In the previous sample request picture, the server as the last modification time of the picture file as "last-modified" to the browser, the browser in the subsequent request that picture, and "if-modified-since" in the form of the service side, At this time, the service side just check this picture again to know whether the image after the last visit has changed, if not modified, of course, in the form of 304 of the browser: continue to use the cached version.

Or an example of a previous request picture, in fact the server also uses another pair of "request/Response" headers:

The use of these two headers is: The server output an ETag header, the browser after receiving, in the form of If-none-match in subsequent requests sent to the server, for the service side to determine whether to use 304 response.

"Last-modified" and "ETag" both, in fact, only need to use one is enough, the key is to see how the server handles them, the browser just after receiving, the next time to send out.

However, the preceding example code does not use the cache header, in fact, it can also be taken, so as to minimize access to the server, after all, the user does not always strong browser. Although there are big differences in these two ways, they are absolutely complementary.

In order to be able to portray the request process of caching pages (or other documents), I drew a picture for your reference:

Back to top how to avoid HTTP caching

In the previous section, there are two ways to use the browser's cache. But sometimes you might want the browser to discard its cached results. Now the browser has a cache function, especially for some static files, such as: Pictures, js,css, HTML files, can be cached. But sometimes we need to update the CSS, JS file, if the browser also use its cached version, obviously there is a problem. Some sites use URL rewriting to make the original dynamic page extension a static HTML file, so you still want the browser to not cache these pseudo-static pages at some point.

At this point, we want the browser to discard the results obtained from the HTTP request. In general, the browser in the processing (it considers) static files, will follow the URL as key to save those cached results, so the usual solution is to modify the URL, such as: The original request abc.js, to change to abc.js?t=23434, followed by a parameter, Let the previous cache not work. The value of the parameter T can be specified according to the last modification time of the file or manually, as long as you change it.

However, for pseudo-static pages, we can no longer use this method, why not explain it.
Then, you can use the server to output a response header, the response header to the browser, do not cache this file. For example, this method can be called:

Response. Cache. Setnostore ();

It generates such a response header content:

Cache-control:private, No-store

Many browsers can recognize it. There is another way to set an expired expiration time.

The previous practice of adding extra parameters to URLs is more commonly used in JS, such as jquery, which allows an AJAX request not to be cached, by setting {Cache:false} and eventually adding a temporary parameter to the generated URL. To ensure that the address of the subsequent request is not duplicated, the goal of avoiding caching is eventually achieved. The use of jquery is so simple that I'm not going to show you an example code anymore.

304 Not modified code and principle for an ASP. NET page