Strong caching and negotiation caching

Strong caching and negotiation caching

1. When the browser makes a resource request, it will judge whether the response headers hit the strong cache. If it hits, it will read the cache directly from the local and will not send the request to the server.

2. When the strong cache is not hit, it will send a request to the server to determine whether the negotiated cache is hit. If it hits, the server will return the request without returning the resource, telling the browser to read the cache from the local. How to miss, the server directly returns the resource.
Differences: If a strong cache hits, the server will not be requested, and the cache will be directly requested; if the negotiated cache hits, the server will be requested, the content will not be returned, and then the cache will be read;

Strong cache

Force the resources to be cached
Header information

At the same time, cache-control has some other values: 1) public/private: public means that both the client and proxy server (such as CDN) can be cached, and private (the default value) means that only the client can cache

2) on-cache/no-store: no-cache client caches the content, but whether to use the cache needs to be negotiated to verify the decision; no-store content will not be cached, that is, no strong cache is used, nor is it used Negotiation cache

Negotiation cache

After the strong cache fails, the browser carries the cache mark to initiate a request to the server, and the server branch cache mark determines whether to use the cache.
Header information

Last-Modified/If-Modified-Since and ETag/If-None-Match

1. Last-Modified/If-Modified-Since

  1. The browser sends a request for the first time, and the server returns the last update time (Last-Modified value) of the requested resource in the response header, and the browser saves this time;

2) When the browser requests next time, the If-Modified-Since (the saved Last-Modified value) is included in the request header. Compare the modification time sent by the browser with the wh modification time of the server. If they are the same, the code resource has not changed, and the server returns a response with an empty body, allowing the browser to read the resource in the cache, thereby reducing request consumption.


1) From the above figure, we can see that Last-Modified saves absolute time and is accurate to the second, so if the resource is modified multiple times within 1 second, it will not be recognized;

2) For the file, only the modification time is changed, and the content remains unchanged. At this time, the cache will be invalidated. In fact, at this time, we don't want the client to request again;

3) Some servers cannot accurately get the last modification time of the file;

2. ETag/If-None-Match

  1. The browser sends a request for the first time to get the value of ETag, and then puts If-none-match (that is, the value of the saved ETag) in the request header of the next request;

2) Compare the sent ETag value with the ETag value regenerated by the server. If the same means that the resource has not changed, the server returns a response with an empty body, allowing the browser to read the resource from the cache, thereby reducing request consumption .

The working mechanism of ETag is basically the same as Last-Modified. However, ETag uses an anti-collision hash function for resource content (I don't know what it is), and uses the hash value of the most recently modified timestamp. ETag solves the above-mentioned problem of Last-Modified.

Disadvantages: Although ETag can solve the problem, it is not perfect. ETag needs to be read and written every time the server is generated (because a hash is generated), while Last-Modified only needs to be read, and ETag consumes more.


It can be seen that the negotiation cache is actually affected by the strong cache. When the strong cache expires and the Cache-Control is not no-store, whether to cache is determined by the negotiation cache.