Browser cache related HTTP control header (Last-modified/etag/expires/cache-control) detailed

Browser cache, also known as HTTP cache, refers to when we browse the site, the browser will store a copy locally, so that the next time you visit the same URL can no longer connect to the server, directly from the browser local cache to obtain resources. The server-side program can control the cache behavior through HTTP cache headers, reduce the burden on the server, shorten the response time, and significantly improve the performance of the website. HTTP Cache related head has Last-modified/etag/expires/cache-control, respectively, described as follows: (1) Expires in the head of the HTTP response message Expires to control, The form is as follows (GMT time, Beijing East Eight district, to add 8 hours, is the Times OH):

Expires:thu, 23:21:37 GMT

After the browser receives a response message containing the Expires field, the next time the resource is requested again, the client will assume that the browser cache is valid until the expires date, so the browser does not connect to the server and reads directly from the local cache. However, expires has shortcomings, for example, the time settings of the server and the client may be different, which will make the cache failure may not be accurate as expected. (2) The form of Cache-control Cache-control in the HTTP response header is as follows:

cache-control:max-age=3600

This declares a relative number of seconds, which means that from now on, the cache is valid for 3,600 seconds, thus avoiding inconsistencies between the server and client time. But Cache-control is HTTP1.1, not for HTTP1.0, and expires both for HTTP1.0 and HTTP1.1, so it would be a better choice to send these two headers at the same time in most cases, and when the client can parse both headers, it takes precedence over the CA Che-control. In addition, caching the resource is not allowed when Cache-control is configured as Private,no-cache,no-store or Set-cookie in the response header. (3) Last-modified/if-modified-since when the browser first requests a URL, the server-side return status is 200, the content is the resource you requested, There is also a last-modified attribute that marks the time at which this file was last modified at the end of the service period, similar in format:

Last-modified:mon, 23:21:37 GMT

When the browser requests this URL for the second time, according to the HTTP protocol, the browser transmits the If-modified-since header to the server asking if the file has been modified after that time:

If-modified-since:mon, 23:21:37 GMT

If the server-side resources do not change, the HTTP 304 (not Changed) status code is returned automatically, and the content is empty, thus saving the amount of data transferred. When the server-side code changes or restarts the server, the resource is re-emitted, similar to when the first request is returned. This ensures that the resources are not duplicated to the client, and that the client is able to get the latest resources when the server changes. (4) The Etag/if-none-match HTTP protocol specification defines the ETAG as the entity value of the requested variable. The server is solely responsible for judging what the token is and what it means, and transmitting it to the client in the HTTP response header, which is the format returned by the server side:

ETag: "d41d8cd98f00b204e9800998ecf8427e"

The client's query update format is this:

if-none-match:w/"d41d8cd98f00b204e9800998ecf8427e"

If the etag does not change, the status 304 is returned, and the content is empty, which is the same as last-modified.

Learning materials from: http://blog.wpjam.com/m/last-modified-etag-expires-cache-control/