An introduction to the HTTP caching principles for back-end programmers--how to determine the Cache-control strategy of a resource

Getting resources over the internet is both slow and expensive. To do this, the HTTP protocol contains a portion of the control cache so that HTTP clients can cache and reuse previously

To optimize performance and improve experience. Although the part about cache control in HTTP, there are some changes as the protocol evolves. But I think that as the back end of the journey

Sequencer, when developing Web services, it is sufficient to focus on the request header If-none-match, the response header ETag, and the response header Cache-control. Because of these three HTTP

Head to meet your needs, and most of today's browsers support these three HTTP headers. All we have to do is make sure that every server response is

The correct HTTP header instruction to instruct the browser when the response can be cached 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. Within the server, of course, there are

Various caches, but this is not the HTTP cache that this article is going to discuss. The so-called HTTP cache control, is a convention, by setting different response headers cache-

Control controls the usage policy of the browser and Web proxy for the cache, by setting the request header If-none-match and the response header ETag to verify the validity of the cache

Certificate

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. But

In any case, the etag should reflect changes in resource content, which is the basis for the HTTP cache 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 of the

An etag with a value of X1323DDX is returned in the example. 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 a request has been made, 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 requests again to the server, you can use the request header If-none-match to tell the server itself has

There is an etag for 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 can

How long to cache. 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 transfers

of data costs. To do this, the HTTP specification allows the server to return a series of different cache-control directives that control how the browser or other relay cache caches a

Response and how long the cache is cached.

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 are

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

Then cache and reuse 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 has

If the resource on the server changes during this time, the browser will not be notified and the old version of the resource

。 So when setting the length of the cache time, you need to be cautious.

Public and private

If public is set, the response can be cached in the Web proxy of the browser or any relay, and public is the default value, which is cache-control:max-

Age=60 is equivalent to 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.

No relay Web Proxy is allowed 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 set to No-cache or Cache-control:no-cache in the response, the browser must confirm the return with the server before using the cached resources.

The response is changed, and if the resource has not been changed, you can avoid the download. Whether the response before this verification has been modified is through the request header described above if-

None-match and the response header ETag to achieve this.

It is important to note that the name No-cache is a bit misleading. After setting the No-cache, it is not that the browser is no longer caching data, but the browser is using the slow

When you save the data, you need to make sure that the data is still consistent with the server. If No-cache is set, and the ETag implementation does not reflect a change in resources, it

Causes the browser's cached data to be kept from being updated.

No-store

If the server is set to No-store or Cache-control:no-store in the response, then the browser and any relay Web proxy will not store the corresponding

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.

Back to Sohu, see more

http://www.sohu.com/a/128401743_419394

An introduction to the HTTP caching principles for back-end programmers--how to determine the Cache-control strategy of a resource