Code and principle of 304 Not Modified on the asp.net page, 304 modified

Code and principle of 304 Not Modified on the asp.net page, 304 modified

Through the previous example, we have seen the benefits of Caching: it can be reduced to server access, because the page can be displayed without accessing the server, which for the server, this reduces access pressure.However, if you force refresh the browser, the browser ignores the cache page and directly initiates a request to the server.

That is to say, the cache page will be invalid when the user forces to refresh the browser.
However, we use the cache page because we want to tell the browser that the data will not change for a certain period of time, so we do not need to request the server again. However, we cannot block user behavior. Due to browser re-access, the original idea of cache will fail. The final result is that the page is re-executed on the server, and the generated HTML code will be re-sent to the client. The result of this refresh may also be meaningless, because the data may not change at all, so the page obtained cannot be changed.

Let's take a simple example: the client needs to browse an image. When a browser accesses an image for the first time, the browser certainly does not have any cache records. At this time, it accesses the server and the server returns the image content. However, because an image may be referenced by multiple pages, the possibility of modification is very small. Therefore, there is no need to read the image and return the image content for multiple requests from the same browser. This will not only affect performance but also waste bandwidth. Therefore, when server software such as IIS accesses such static files, some tags will be output in the response header to inform the browser that the file can be cached.

Back to the above-mentioned [user forced refresh] Question, what will IIS do at this time? See:

Note: At this time, no data is returned except for the HTTP status code to 304.

To impress you with the 304 response, I captured an image response result with a status code of 200:

After comparing the two images, we can see that 304 and 200 are not only numerical differences. The most important difference is whether or not results are returned.

If no result is returned, how does the Browser display it?
Do you have such doubts?
In fact, do not worry, the browser will use its cached version to display. That is to say: no matter how powerful the user is, the server does not return results, but it can still be displayed normally.

Obviously, this effect is what we want.
If you use this method, the cache page mentioned above has been badly refreshed by users.
However, I would like to remind you that the webdev.webserver.exe self-contained in Visual Studio does not support 304 responses, so you should not try it out without any results.

Back to Top how to program 304 responses

We have seen the effect of 304 responses. However, in ASP. NET, the program we developed is a dynamic page, not an image. We hope that a page can be cached for a period of time in this way. I think this requirement may be more meaningful.

Next, I will demonstrate how to implement it through programming.
In the following example, the page displays the time generated by the page on the server. The time has changed, indicating that the page has been re-executed.

I think it doesn't make much sense to intercept a series of images. I just took a picture and showed it many times.

It reflects the process of multiple requests to An ASPX page. It can be seen from the image that only the first response is 200, followed by 304, which is the expected result.

Let's take a look at its implementation code:

Although the Code is not complex, I plan to explain it as follows:
When the browser requests the page for the first time, it will execute the SetLastModified call. It will output a "Last-Modified" response header when the browser responds. Then, when the browser accesses the page again, theContentThe Request Header "If-Modified-Since" is sent to the server. In this case, the server can determine whether to use the 304 response based on the specific logic.

In the previous request image example, the server sends the Last modification time of the image file to the browser as "Last-Modified". When the browser requests the image subsequently, the server is also notified in the form of "If-Modified-Since". At this time, the server only needs to check this image again to see If the image has been Modified Since the last access, of course, we will tell the browser in the form of 304: continue to use the Cache version.

In fact, the server also uses another pair of [Request/Response] headers:

The use of these two headers is: the server Outputs An ETag header. After receiving the header, the browser sends it to the server in the form of If-None-Match in subsequent requests, for the server to determine whether to use the 304 response.

"Last-Modified" and "ETag" are both. In fact, you only need to use one of them. The key is to check how the server processes them. The browser only sends them again after receiving them.

However, the preceding sample code does not use a cache header. In fact, you can also use it to minimize access to the server. After all, the user will not always be able to use a browser. Although there are big differences between the two methods, they can definitely complement each other.

In order to visually depict the request process of cache pages (or other documents), I drew a picture for your reference:

How to avoid HTTP caching back to the top

The previous section describes two methods to use browser cache. However, sometimes the browser may wish to discard the cached results. Currently, browsers have cache functions, especially for some static files, such as images, JS, CSS, and HTML files. But sometimes we need to update CSS and JS files. If the browser still uses its cached version, it will obviously be a problem. In addition, some websites use URL rewriting to convert the original dynamic page extension to static HTML files. Therefore, we still hope that the browser will not cache these pseudo static pages in some cases.

At this point, we want the browser to discard the results obtained from the HTTP request. Generally, when a browser processes (as it thinks) static files, it will save the cached results according to the URL as the kEY. Therefore, the common solution is to modify the URL, for example: the original request is abc. js, to be changed to abc. js? T = 23434, followed by a parameter, so that the previous cache does not work. The value of parameter t can be manually specified based on the last modification time of the file. In short, you only need to change it.

However, for pseudo-static pages, we can no longer use this method, so there is no need to explain the reason.
Therefore, you can output a response header on the server to notify the browser of the Response Header. Do not cache this file. For example, you can call this method:

Response.Cache.SetNoStore();

It will generate such response header content:

Cache-Control: private, no-store

Many browsers can recognize it. Another way is to set an expiration time.

The method of adding additional parameters in the URL mentioned above is also common in JS. For example, JQuery supports making an Ajax request not cached. The method is to set {cache: false }, in the end, it will add a temporary parameter to the generated URL to ensure that the address of the subsequent request is not repeated, so as to avoid caching. JQuery is too simple to use, so I will not provide the sample code.