I have read several articles about strong cache and negotiated cache on the Internet, and found that they are not very easy to understand. Here I will explain to you in a more understandable language what is strong cache, what is negotiated cache and its working process. Please point out any mistakes

Strong cache

First of all, strong caching literally means forced caching. In order to reduce access to the server, browsers cache certain resources locally, so strong caching is also called local caching. Its main working principles are:

The first thing you need to do is get the resource from the server, right, and the server will set an expiration date for the resource, which is to tell you when the resource expires, and once it expires, you have to ask the server again for the resource, and if it hasn’t expired, then you have to continue to use the locally cached resource. This is the general workflow of strong caching. When you request a resource, check whether the local resource has expired, and then bother the server.

And then how does the server set the expiration time for the resource

In HTTP1.0, the server will add an Expires attribute to the response header. This attribute represents the absolute time when the resource will expire. The value looks something like this:

Mar, 06 Apr 2020 10:47:02 GMT

In HTTP1.1, we added a cache-control property that tells the browser how to Cache the resource. There are also some expiration Settings. The main one is max-age. This value represents the lifetime of the resource (that is, how long the resource lasts). Then there are a few other commonly used values:

  • No-cache: no local cache (i.e. no strong cache)
  • No-store: directly disallows the browser to cache data (i.e. requests to the server each time the resource is requested)
  • Public: indicates that the resource can be cached by all users
  • Private: the device can be cached only by the browser of the terminal user and cannot be cached by a trunk cache server such as the CDN.

Here is an example of how this property is used, max-age=0 for immediate expiration

cache-control: no-cache, no-store, must-revalidate, private, max-age=0

When cache-control and Expires are present together, browsers will prefer cache-control

Ok, so that’s the main thing about strong caching. Let’s look at negotiated caching

Negotiate the cache

Negotiated caching is literally a discussion between the browser and the server about whether or not to use the cached resource. When the strong cache is skipped by the browser (i.e. the cache expires), the browser and the server negotiate how to obtain the resource. Specific working process:

When a browser requests the server resources for the first time, the server will return a side cache identification of resources to the browser, when the browser for the second time to request the server resources, will put the logo to the server, the server will first check the resource cache id compared with server resource cache logo above, if different, means resources are updated, If the resource is the same, a 304 status code is returned to tell the browser that the resource has not been updated and that the local cache can be read.

When the resource on the server is updated, the identity is also updated, so it will tell the difference. This is the general workflow for negotiating caches

Let’s take a look at what this cache id is.

In HTTP1.0, the first time a request is made to the server, the server returns a last-Modified cache identifier, which literally stores the Last time the resource was Modified. The server then gives this to the browser, and when the browser requests the server again, The server then compares the browser’s Last-Modified with the server’s last-Modified resource, and returns 304 If the time is the same. Inconsistent returns a new resource and a new Last-Modified

The downside of this approach is that when a file on the server deletes a character and adds the same character back, last-Modified is also updated, but the content of the resource itself has not changed, so the next request will return the same resource instead of reading the resource from the cache

In HTTP 1.1, the server uses Etag to set the response header cache identifier. The Etag value is generated by the server. On the first request, the server returns both the resource and the Etag to the browser, which caches both to the local cache database. On the second request, the browser will put the Etag information in the if-none-match header to access the server. Upon receiving the request, the server will compare the file id in the server with the id sent by the browser. If the file id is different, the server will return the updated resource and the new Etag. The server returns the 304 status code, which the browser reads from the cache.

Explanation of Etag:

The emergence of Etag solved several last-Modified problems

  • For example, if the time of the file is changed but the content is not changed, we do not want the client to think that the content of the file has changed and request new resources
  • Another point is that some files are Modified very frequently, such as n times per second, but last-Modified detection is second, so if the file is Modified but not detected by Last-Modified, last-Modified will remain unchanged, which is not desirable

Finally, the general flow chart, I hope you can better understand the content of the diagram after reading my article