HTTP caching principles and related knowledge (1)

Getting resources over the internet is both slow and expensive. For this reason, the HTTP protocol contains a portion of the control cache so that HTTP clients can cache and reuse previously acquired resources to optimize performance and enhance the experience. Although the part about cache control in HTTP, there are some changes as the protocol evolves. But I think as a back-end programmer, when developing Web services, it is enough to focus on the request header If-none-match, the response header ETag, and the response header Cache-control. Because these three HTTP headers can meet your needs, and most of today's browsers support these three HTTP headers. All we have to do is make sure that each server response provides the correct HTTP header instructions to guide when the browser can cache the response and how long it can be cached.

Where is the cache?

There are three roles in the browser, Web proxy, and server, and HTTP caching exists in both the browser and Web proxy. Of course there are various caches inside the server, but this is not the HTTP cache that this article will discuss. The so-called HTTP cache control, is a convention, by setting different response header Cache-control to control the browser and Web Proxy usage policy of the cache, by setting the request header If-none-match and the response header ETag to verify the validity of the cache.

Response header ETag

The ETag is the full entity Tag, used to identify a resource. In a specific implementation, the ETag can be a hash value for a resource, or it can be an internally maintained version number. However, the etag should be able to reflect changes in resource content, which is the basis for HTTP caching to work properly.

As shown in the previous example, when the server returns a response, it usually contains some metadata information about the response in the HTTP header, where the ETag is one, in this case the ETag with the value X1323DDX is returned. When the content of the resource/file changes, the server should return a different etag.

Request Header If-none-match

For the same resource, such as/file in the previous example, after making a request, the browser already has a version of the content of/file, and this version of the ETag, when the next time the user needs this resource, the browser again to the server request, You can use the request header If-none-match to tell the server that it already has an etag of X1323DDX/file, so that if the/file on the server does not change, that is, the/file etag on the server is X1323DDX, Instead of returning the contents of the/file, the server returns a 304 response telling the browser that the resource has not changed and that the cache is valid.

As shown in the example above, after using If-none-match, the server needs only a small response to achieve the same result, which optimizes performance.

Response Header Cache-control

Each resource can define its own cache policy through HTTP header Cache-control, Cache-control control who can cache the response under what conditions and how long it can be cached. The fastest request is a request that does not have to communicate with the server: with a local copy of the response, we can avoid all network delays and data costs for the transmission. To do this, the HTTP specification allows the server to return a series of different cache-control instructions, controlling how long the browser or other relay cache caches a response and how much time it caches.

The Cache-control header is defined in the http/1.1 specification, replacing the header previously used to define the response cache policy (for example, Expires). All current browsers support Cache-control, so it's enough to use it.

Let me introduce the common directives that can be set in Cache-control again.

　　Max-age

This directive specifies the maximum amount of time (in seconds) that a given response is allowed to be reused, starting at the current request. For example, cache-control:max-age=60 indicates that the response can be cached and reused for 60 seconds. It is important to note that the browser does not send any requests to the server within the time specified by Max-age, including verifying that the cache is valid, that is, if the resources on the server have changed during that time, the browser will not be notified and the old version of the resource is used. So when setting the length of the cache time, you need to be cautious.

　　Public and private

If public is set to indicate that the response can be cached in the Web proxy of the browser or any relay, public is the default value, that is, cache-control:max-age=60 equals Cache-control:public, max-age=60.

In the case where the server is set to private such as Cache-control:private, max-age=60, it means that only the user's browser can cache the private response and not allow any relay Web proxy to cache it-for example, The user browser can cache HTML pages that contain user private information, but the CDN cannot be cached.

　　No-cache

If the server is setting No-cache-Cache-control:no-cache in the response, the browser must confirm with the server whether the returned response is changed before using the cached resource, and avoid downloading if the resource has not been changed. Whether the response before this verification is modified is implemented by the request header If-none-match and the response header ETag described above.

It is important to note that the name No-cache is a bit misleading. After setting the No-cache, it is not said that the browser will not cache the data, but the browser when using cached data, you need to confirm that the data is also consistent with the server. If No-cache is set, and the ETag implementation does not reflect a change in resources, it can result in the browser's cached data being kept from being updated.

　　No-store

If the server sets No-store-Cache-control:no-store in the response, the browser and any relay Web proxy will not store this data. The next time the resource is requested, the browser can only re-request the server and re-read the resource from the server.

How to determine the Cache-control strategy of a resource?

Here is a flowchart that can help you.

< from Web developers >

HTTP caching principles and related knowledge (1)