Summary of the server-browser cache negotiation control mechanism

Http://www.ginano.net/browser-server-cache-control-ruletable was released by ginano on January 1, March 13, 2013

Introduction:There were a large number of user complaints on the Chinese site yesterday. The complaint was that the freight was changed and the freight amount was incorrect. However, we have no problem in local testing. However, considering the problem, the only possible cause is that yesterday's project on the optimization of the freight template. Because I released a style application version at noon yesterday at around nine o'clock, and the shipping template optimization project was released at around. However, the freight template optimization project found a problem in the formal release phase, so it responded to the formal release failure operation at about 3 o'clock the next day, the style application is rolled back together (that is, the current version of the server is overwritten by the version around noon ). Therefore, after analysis, it is likely that the front-end JS file of the user end is not normally rolled back to the version released at noon (later useMerge-ump-old.jsTo replace this version), that is, the user visited the order now page from to (during the official release of the cost template optimization project, therefore, the browser caches the versions generated by the freight template optimization project (which will be used later ).Merge-ump-new.jsTo replace this version), and when the browser visits the order now page again the next day, it requests the server's style file, the server directly tells the browser that the cached file is newer than the file on my server (because the server has rolled backMerge-ump-old.js,What the user caches isMerge-ump-new.js), So directly returning status code: 304, the browser still uses the files cached last night, so it is a tragedy and a lot of tragedies.

So why are there no problems in our own tests? In the end, how does the cache between the browser and the server be negotiated and controlled? By searching for several documents on the network, the following Cache Control flowchart is obtained:

Server browser cache negotiation control flowchart (click to view the big picture)

Briefly describe the entire process and give a brief overview of the key control nodes. For details, refer to the details of the expanded reading link. Since the browser will never cache POST requests, it only describes the process of the GET request file. If there is any inaccuracy, I hope to correct it.

A process. When the page is accessed for the first time or forcibly refreshed (similar to the first visit), the server will directly return the status code: 200 with the relevant information of the file response headers, all information is added or decreased Based on the server configuration. After receiving the Response Headers returned by the server, the browser determines whether the file is to be cached and how long the cache is valid for further access.

From the above several key points, the main information for controlling the cache through browser and server negotiation is:

1. The Pragma value determines whether browser cache is required (http1.0 specification, http1.1 compatibility, not all browsers support it)

2 Cache-control determines whether the browser caches or sets the cache time (in seconds ).

3 expires expiration time value, but the server and client may not synchronize the time zone or the like, resulting in inaccurate

4 etag is similar to the unique hash value of the file on the server, which is generated by the server according to the rules.

5 last-modified: The last modification time of the file. It can only be processed by etag in seconds.

There is a general order or priority:

Browser behavior: Pragma value verification, cache-control value verification, and expires value verification

Server behavior: etag verification last-modified verification (most servers will return 304 after both are passed, so there is no such strict order relationship, of course, the specific check or check is related to your server configuration)

Normally, press F5 to stop the local cache verification of the browser, so that the cache-control and expires values are invalid, but the last-modified and etag values are still valid (if any ), the browser directly sends the cached file information to the server and submits it to the server to determine whether the 304 or 200 status code is returned. This determines whether the browser directly uses the cached file on the browser.

When the page is forcibly refreshed, that is, we often call Ctrl + F5, the browser directly makes all values related to cache settings invalid when the file is accessed for the first time, the values of last-modified and etag are invalid. Therefore, directly following the [a] process will not generate the negotiation control process between the browser and the server. In many cases, it is useless for us to make a strong click. This is a problem with some specific browsers. For details, a student has made a detailed evaluation analysis. For more information, see [3 ].

Next we reference the mere-ump.js file on the following single page as an example to simulate a complaint about the user's access process.

Stage 1:The user accessed the order now page for the first time between PM and PM on the 11 th (during the official release and rollback of the freight template optimization project ).

1. Go to the page, the browser analyzes the file that references the merge-ump.js, and there is a corresponding localMerge-ump-old.js File Cache (assuming the user has accessed it before).

2. the browser determines whether the cached file has expired. The style application on the Chinese site does not specifically set The Pragma value (this value is specified in the HTTP 1.1 specification, but is not implemented by many browsers, so the significance is not very big ), the cache-control value is not specifically set to control the cache, even expires is not set (this time is the server time, but the browser and the server time zone are inconsistent, and other reasons will cause the time to be fundamentally different, so it is not very reliable), only through the etag and last-modified time of the file to control the return to the browser. Therefore, each time a browser requests a server, the Cache control is always determined by the server. :

Request Header and returned header information of the style file on the Chinese site (click to view the large image)

In addition, the time returned by the server indicates that the time zone of the server is incorrect, which is 8 hours different from that of ours!

3. As you can see, the request header information carried by the browser should beMerge-ump-old.jsThe etag value and the modified time are sent as keys of IF-None-match and if-modified-since. Therefore, when the browser sends a request to the server, the server compares the passed value with the etag value of the merge-ump-new.js on the server (if verified), andMerge-ump-old.jsWhether the last modification time is earlier than the last modification time of the merge-ump-new.js, if verified ). Browser comparisonThe merge-ump-new.js is newer, so status code: 200 is returned and the latestMerge-ump-new.js file to the browser, the browser will cache the file again according to response headers.

4. rollback is required because the project release fails. Although the rollback operation is not very clear, it is certain that: directly copy all the files in the previous version of the server and overwrite the existing files, therefore, the last-modified time of the file is changed to the modification time when the previous version was released. The rules and verification rules generated by etag are determined by the server. The generation and verification of etag is a huge cost for the static service resources of large websites, because all static files are rarely changed n times in 1 second, the last-modified time is enough. So a lot like Yahoo !, This function is disabled for large websites such as Google and Facebook, which only depends on the modification time of files to improve server performance. Therefore, the Chinese site is not certain. You need to check with the O & M personnel whether etag verification is enabled. At present, it seems that the generated function is enabled, and I don't know whether the verification is enabled (I came to check with Mi Zhiwen that the etag value was not verified, but the default last-modified is used for verification ).

Stage 2The user visits the order now page again at nine o'clock A.M. on the 12th (the first visit after rollback ).

The browser repeats steps 1 and 2 in the first phase, but the local cache file is the merge-ump-new.js file downloaded last night, so the information carried by request headers is also the information of the file. After the server receives the request, compare the modification time of the last-modified-since in the request header information with the merge-ump-old.js file in the server because it rolled back to this version, it was found that the modified time of the cached file was still newer than that of the server, so the system passed the modification and directly returned the status code "status code304" to the response headers, the browser directly uses the local cache file merge-ump-new.js after receiving the 304 status code, and the order now page itself is a dynamic page and does not cache (set Pragma: No-Cache and cache-control: max-age = 0 ). Therefore, the page is rolled back, but the user's local JS file is still the version generated by the cost template optimization project, resulting in inconsistency between the front and back ends of the computing logic, resulting in user complaints.

At that time, I contacted a local user in Hangzhou and remotely assisted the user's computer in Operations. He downloaded the merge-ump.js file referenced on the order page through his ie9 browser, we found that this file version is a merge-ump-new.js file, and the server has been troubleshooting merge-ump-old.js content, thus indicating that the server directly returned 304, we download only the browser local cache. Because the corresponding etag value could not be recorded at the time, it cannot be verified.

Finally, to solve the problem as soon as possible, we immediately used an unaltered style application to change the last-modified time of the online Server File. The results show that the order can be successfully placed one minute after the release. Therefore, the above inference can indicate the following two possibilities to reasonably explain the cause of the fault.

1) The style server does not verify the etag value;(The server is not verified after confirmation)

2) the corresponding etag value is not modified during the rollback operation;

Summary:

Based on the above analysis and the problem generation and Solution Process, the cache negotiation control between the browser and the server is generally divided into two aspects:

1) The server uses response headers to tell the browser whether to cache the file and how long it takes, or whether to directly use the local cache file.

2) the browser determines whether to cache the file, how long the file will be cached, and whether to initiate an HTTP request to request the file server again at the next visit based on the response header information received during the last request to cache the file, and ask the server to tell the browser whether the file can be cached locally.

Suggestions:

Therefore, the specific problem should be analyzed based on the actual situation.

1. Dynamic Content pages with high real-time requirements. Use Pragma and cache-control/expires to disable browser caching.

2. For static files that never change, such as images, you should set a large cache-control value (this value is recommended) or the expires value tells the browser to directly use the local cache without sending a request to the server. This reduces HTTP requests, reduces server overhead, improves performance, and increases user access speed (because the browser's concurrent request Uris are restricted at the same time ).

3. For static files such as CSS and JS files in the style application, although there are not many changes, they are occasionally released and need to take effect in a timely manner. In order to achieve a balance between timely file content update and server load reduction, the browser needs to cache the file, but it cannot be too long. The file must be updated in a timely manner after the new release. The best way is to set a smaller cache-control value or expires value to reduce HTTP requests. When the browser sends the request header information of the request file, make full use of etag and last-modified time to verify and determine whether to return new content. This ensures that the server always responds to the latest file content from the server,The etag value and last-modified time should be updated in a timely manner no matter the rollback or release phase.. At the same time, the release of the style application should choose the late-night period of low user activity, so as to reduce the problem of availability reduction caused by browser cache time. Of course, if the style server has good performance or does not have to worry about the pressure, you do not need to set the browser cache expiration time. Each time you directly access the server, you can decide whether to use the cached content to the server for processing. At present, the Chinese site also has a smooth release solution, but we should also note that the values of etag and modified time should be updated in rollback and release to prevent the same tragedy.

The above is a detailed analysis of this fault. If you have any different opinions or have different opinions on the content described in this article, please criticize and correct it.

Reference List:

[1] Hypertext Transfer Protocol-HTTP/1.1

[2] browser cache mechanism

[3] [summary] browser cache mechanism

This entry is published in the front-end development directory for server technology classification and is pasted with 200,304, cache-control, etag, expires, HTTP, if-modified-since, last-modified, Pragma, request Header, Response Header, status code, Web Front-end development, server cache, and browser cache tags. Add a fixed link to favorites.

Summary of the server-browser cache negotiation control mechanism