Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to set up the resource cache in nginx. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

First, I created a new index.html file and an index.js file in the root directory of nginx. At this point, the configuration file for nginx looks like this:

Server {listen 8080; server_name localhost; location / {root / Volumes/myFile/nginx_root; index index.html index.htm;}}

Then we visit localhost:8080 in our browser. Open the console and find two requests in it:

You can see that on the first visit, the status code for both requests is 200. Let's click on one of the requests to see the response header message:

As you can see, we have Etag and Last-Modified information in the response header. This is the field used by the negotiation cache. It seems that nginx has given us the default use of caching. Then we do not modify the html file and js file on the basis to refresh the page to verify, hit the negotiation cache, the status code should return us 304 Not Modified. I refreshed several times to observe the status code of the http request. The html file returns 304each time. But the js file becomes 200 OK (from memory cache) after the original 304s. This means that each time the html file hits the negotiation cache, while the js file hits the strong cache (the strong cache takes precedence over the negotiation cache). Why did this happen? let me take a look at Baidu:

Why is it that some caches are 200OK (from cache) and others are 304Not Modified? It's simple to see if Entity Tag is removed. If you remove it, it will always be 200 OK (from cache). If not removed, the two will appear alternately.

So what's the difference between the timing of the trigger? 200OK (from cache) is accessed directly by clicking on the link, and entering the URL can also be triggered by pressing enter, while 304Not Modified is triggered when the page is refreshed or when a strong cache is set but the Entity Tags is not removed.

Compared with my example, I understand that the index.html file refresh page hit the negotiation cache returned 304, while the js file was introduced in the index.html file link, so hit the strong cache 200OK (from cache). To verify my idea, I used the address bar to access the index.js file directly. Type: localhost:8080/index.js in the address bar. At this time, it did return 304 to me. Let's take a look at the request header at this time:

You can see that at this time, Cache-Control gives the max-age=0; and then carries the relevant parameters of the negotiation cache. It seems that when the browser is a refresh operation, it will carry Cache-Control:max-age=0 to avoid hitting the strong cache.

Nginx disables strong caching

Try what happens after nginx disables strong caching. Modify the nginx configuration file:

Server {listen 8080; server_name localhost; location / {root / Volumes/myFile/nginx_root; index index.html index.htm; add_header Cache-Control no-cache; # is public that can be cached by any object, and private can only be cached by individual users, not by proxy server add_header Cache-Control private;}}

After modifying the nginx configuration file, let's restart the nginx server. Accessing localhost:8080 at this time

As you can see, both the html file and the js file are hit by the negotiation cache.

Cache-Control: no-store

Disable all caching (this is what the response means not to be cached). Caching usually forwards a no-store response to the client, like a non-cached proxy server, and then deletes the object.

Cache-Control:no-cache

Forces the client to send a request directly to the server, that is, each request must be sent to the server. The server receives the request and determines whether the resource has changed. If so, the new content is returned, otherwise 304 is returned and no change is made. This is easily misleading and makes people think that the response is not cached. In fact, Cache-Control: no-cache is cached, but each time the response data is provided to the client (browser), the cache evaluates the validity of the cached response to the server.

In fact, setting Cache-Control to no-store really means not being cached, so modify the nginx file and set Cache-Control to no-store to see what happens. Refresh the browser again at this time.

You can see that after modifying the configuration file of nginx, except that the first time is 304( the browser has just received the information of no-store, and the request still carries cache-related information on the header), the rest of the refreshes of the page have returned 200. Neither the strong cache nor the negotiation cache is hit. Take a look at the http header information of the index.js file.

On how to set up the resource cache in nginx to share here, I hope the above content can be of some help to you, you can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.