HTTP caching mechanism

have been reading the HTTP authoritative guide or related books, but no deep practice and thinking, this part of the knowledge theory is difficult to understand,

Because all are theories, practice is more difficult in the absence of guidance, because the Web developers few people really understand this part

Content and thorough use, and HTTP caching mechanism is generally used by default, it is not necessary to adjust, because the cache is to better

The experience, so there is no need to set the ban and the like, are targeted to let a file update, such as add version number, hash change name

And so on, let the file request be recognized as a new file and solve the caching problem.

HTTP cache information is in the header, while the HTTP request cache processing has two kinds, one is strong cache, one is to assist the cache, and the strong cache is

Browser-side cache, that is, the resources are directly in the browser to not go to the server, and assist the cache is to go to the server before the clear

Whether cache information is cached after fetching, whereas the general strong cache takes precedence, and after to assist the cache, such as the size of the network field from cache to strong cache,

While the status code is 304 for assistance caching.

You can use No-cache, No-store, and the specific block.

Specific information:

Thorough understanding of HTTP caching

There's a difference between the browser's history cache and the HTTP cache, so the reason I couldn't clear the cache was because I used a browser

Back forward button practice to view the source where the cache condition is not valid, but to resolve it by refreshing or replacing the current path of the history to let the resource be re-

Request.

User agents typically have historical mechanisms, such as a Back button and a history list, which can be used to re-display the entities that were retrieved earlier in the session.

The historical mechanism and the cache are different. In particular, the historical mechanism should not attempt to display a semantically transparent view of the current state of the resource. Rather, the purpose of the historical mechanism is to accurately display what the user sees when retrieving resources.

By default, the expiration time does not apply to the historical mechanism. If the entity is still stored, even if the entity has expired, the history mechanism should display it unless the user has specifically configured the agent to refresh the outdated history document.

This should not be interpreted as prohibiting the historical mechanism from telling the user that the view may be stale.

Translation information: Caching in HTTP

Profile 2

HTTP caching mechanism