Detailed explanation of browser negotiation cache process based on nginx

This article mainly introduces the detailed process of setting browser negotiation cache based on nginx. The example code in this article is very detailed and has a certain reference value for everyone's study or work. Friends in need can refer to it.

The difference between strong caching and negotiated caching

Strong caching: The browser does not negotiate with the server and directly accesses the browser cache

Negotiated caching: The browser will first confirm the validity of the resource with the server before deciding whether to fetch the resource from the cache or retrieve it again.

How Negotiation Cache Works

Now there is a business scenario like this: the static resources on the backend will be updated from time to time, and because the browser uses strong cache by default, outdated resources will be retrieved from the browser cache by default.

Now we want the browser to confirm with the backend whether the resource is updated every time it obtains the resource, so we need to set the browser to use negotiated cache.

So how does the backend determine whether the resource has been updated? At this time, the two response headers Etag and Last-Modified are used.

Every time a request for a static resource is received, the backend puts the resource's last modification time (Last-Modified) and the Etag calculated based on the resource content in the response header to the frontend.

After receiving the response, the front end caches these two items, and then puts the contents of these two items into the If-Modified-Since and If-None-Match request headers the next time the same resource is requested.

After receiving these two items, the server will compare them with the Etag and Last-Modified currently generated by the resource. If the two are consistent, it means that the resource has not been updated, and the server will return a 304 empty response; otherwise, it means that the resource has been updated, and the server will return the complete resource content.

accomplish

So how to implement such a complex process? In fact, it is very simple. Just use nginx as the server for static resources and add Cache-Control: no-cache to the response header.

Let's implement it step by step

1. Use nginx as a static resource server

In the nginx configuration, map requests for static resources to the disk path of the resource

http {
  server {
  listen 80;
  ...
  location /picture/ {
    alias D:/luozixi/tcp_test/picture/;
    # alias is a redefined path# For example, if you access 127.0.0.1/picture/1_new.gif, it will be mapped to access D:/luozixi/tcp_test/picture/1_new.gif
    # The web application will not receive any requests at all, and all requests for picture are processed by nginx # alias is replacement, root is concatenation autoindex on;
    # Visit 127.0.0.1/picture/, you will get the directory index interface}
  }
}

2. Reload nginx configuration

nginx -s reload

3. At this time, when requesting static resources, nginx will automatically add Etag and Last-Modified to the response header

4. But then I found that if Cache-Contrl: no-cache is not configured, the browser will not send the request to the backend the next time it requests this resource, but will directly obtain the resource from the cache

5. Configuration in nginx

location /picture/ { 
  add_header Cache-Control no-cache;
  alias D:/luozixi/tcp_test/picture/; 
}

6. After clearing the browser cache, the first request will get a normal 200 Response, and the response header already has Cache-Control: no-cache, indicating that the negotiated cache is used.

7. After initiating the request again, you will find that the request header has two items: If-Modified-Since and If-None-Match

8. After receiving these two items, the server (nginx) will compare them with the Etag and Last-Modified currently generated by the resource. If the two are consistent, it means that the resource has not been updated, and the server will return a 304 empty response; otherwise, it means that the resource has been updated, and the server will return the complete resource content

In addition, the way the server verifies If-Modified-Since is just a simple string comparison. Even if the Last-Modified of the resource is earlier than If-Modified-Since, the server still considers the resource to be updated.

9. After receiving the 304 response, the browser will retrieve the resource from the browser cache. So the speed is very fast

The difference between no-cache and no-store

no-cache means that expired resources will not be cached. The cache will process the resource after valid processing confirmation from the server.

And no-store means no caching.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.