Parsing browser-side AJAX caching mechanism _javascript tips

Ajax cache is maintained by the browser, for a url,ajax sent to the server only on the first request with the server interaction information, after the request, Ajax no longer submit requests to the server, but directly from the cache to extract data.
In some cases, we need to get updated data from the server each time. The idea is to make each request a different URL, without affecting the normal application: After the URL to add random content.
e.g.

url=url+ "&" +math.random ();

Key points:
1. Each request URL is different (Ajax cache will not work)
2. Does not affect the normal application (most basic)

Here we are by two conclusions:

The 1:ajax cache is the same as the HTTP cache.
the HTTP and caching mechanisms of modern browsers are much worse than Ajax XMLHttpRequest objects, so it does not recognize or care about AJAX requests. It simply follows the normal HTTP caching rules and caches the response headers returned by the server.
If you already know about HTTP caching, you can use the knowledge of HTTP caching as an understanding of Ajax caching. They are only a bit different, that is, the way to set the response header is not the same as normal files.
The following response headers allow you to cache Ajax:
Expires: This should be set to a suitable point in time in the future, and the setting of the point of time depends on how frequently the content changes. For a chestnut, if the request is an inventory quantity, then the Expires value can be 10 seconds later. If the request is a photo, Then the value of expires can be a little longer because it doesn't change very often. Expires headers allow browsers to reuse locally cached data for a period of time, thereby avoiding any unnecessary interaction with server data.
Last-modified: Setting this item is a good choice, through which the browser uses the if-modified-since in the request header to check the contents of the local cache when sending a conditional GET request. If the data does not need to be updated, the server returns a 304 response state.
Cache-control: In appropriate cases, this value should be set to public so that all intermediary proxies and caches can be saved and shared with other users. In Firefox, it also supports the caching of HTTPS requests
Of course, if you use post to send Ajax is not cached, because the POST request will never be cached. If your Ajax request would have other effects (such as transfers between bank accounts), please use POST requests.
We have set up a demo (this demo can't see's Finger licking (≧-≦) ノ) to illustrate how the header information works. In HttpWatch, you can see that we set the above three response headers in the response header.

If you click the ' Ajax Update ' button regularly, the change in time will tend to occur every minute. Because the expires response header is set to the next minute. In the screenshot below, you can see that when you click the Update button repeatedly, The AJAX request reads the browser's local cache without generating network activity (the Send and transfer bar values are 0)

The last 1:06.531-hour click sent by the AJAX request generated network data transfer because the cached data has been exceeded for a minute. The server returns a 200 response status indicating that a new data was obtained.
Guess this demo should be a button that gets the current time for every click and then back to the page now.

The 2:ie browser does not refresh content acquired via Ajax until the expires time expires.
Sometimes, Ajax is used to populate parts of the page (such as a price list) when the page is loaded. It is not triggered by a user's event, such as clicking a button. Instead, it is sent through JavaScript when the page loads. It's like Ajax requests are the same as those embedded resources (such as JS and CSS).
If you develop such a page, when you refresh it, you probably want to update the embedded AJAX request content. For embedded resources (CSS files, pictures, and so on), the browser will automatically send the following different types of requests, either F5 (refresh) or ctrl+f5 (Force refresh) in the form of user refreshes:
1.f5 (Refresh): If the request content has a last-modified response header, then the browser sends a conditional update request. It uses the If-modified-since request header for comparison so that the server can return 304 states to avoid the transmission of unnecessary data.
2.ctrl+f5 (forced refresh): tells the browser to send an unconditional update request, and the request header's Cache-control is set to ' No-cache '. This tells all intermediary proxies and caches that browsers need to get the latest version, regardless of whether it has been cached.
Firefox has propagated this refresh to the Ajax requests that were sent when the page was loaded, dealing with these AJAX requests as embedded resources. Below is a screenshot of HttpWatch in Firefox, showing the Ajax Caching demo ( This demo has been unable to see the's Finger licking (≧-≦) ノ) Refresh (F5) page when the effect of the AJAX request:

Firefox ensures that Ajax-initiated requests are conditional. In this example, if the cached data is less than 10 seconds, the server returns 304, more than 10 seconds, and the server returns 200 to transfer the data again.
In IE, the Ajax requests that are launched when the page is loaded are seen as having nothing to do with the other parts of the page, nor are they being refreshed by the user. If the cached AJAX data does not expire, no get requests are sent to the server. It reads data directly from the cache, From the HttpWatch is the (cache) results. The following figure is to refresh by pressing F5 if the cache does not expire under IE:

Even if you force a refresh through CTRL+F5, the data obtained via Ajax is read from the cache:

This means that any content that is obtained via AJAX will not be updated under IE if it is not expired-even if you use CTRL+F5 to force the flush. The only way to make sure you get the latest data is to manually clear the cache. You can use the HttpWatch toolbar:

Note that the cache results are different from the 304 results. Cache is actually (cache), 304 is 304. Cache actually does not send the request to the server, can see from the chrome, it is time-consuming 0,response is also empty. and 304 different,
304 request is the browser initiated a conditional request, this request carries the If-modified-since request header, if this file is not modified after the time that the browser sends, the server side returns a 304 state, Tells the browser to use its local cached content. It does not cache fast because the request is sent to the server side, but the server side does not send data.
Can look at the Taobao home page, which has both (cache) also has 304. You can view their differences.

Summarize:

We all know that Ajax can improve the speed of the page load is the main reason is to reduce the load of duplicate data through Ajax, really do on demand, in this case, we can write Ajax programs to send the Buddha to the west, in the client to do a cache, and further improve data loading speed. Which is to cache data in the browser's memory while loading the data. Once the data is loaded, as long as the page is not refreshed, the data is always cached in memory, when the user view the data again, you do not need to fetch data from the server, greatly reducing the load on the server and improve the user experience.