What kind of HTTP response will be cached

Let's discuss what kind of responses will be cached, and what are the conditions for using cached ones.

Caching is divided into two steps. First, the response is cached. In the second step, when a request is about to be initiated, it is checked whether the current cache can use the cached response.

(1) The request method can be understood by the cache (not only the GET method, the Get method can definitely be cached, and the non-get method can also be cached)

(2) The response code can be understood by the cache (404, 206 can also be cached)

(3) The response and request headers do not specify no-store

(4) The response should contain at least one or more of the following headers:

Expires、max-age、s-maxage、public
When there is no header that clearly indicates the expiration time in the response, if the response code is very clear, it can also be cached

(5) If the cache is on the proxy server

Does not contain private (here is to explain that the shared cache cannot be used, but the shared cache can be used on the proxy server)
Does not contain Authorization

other response headers

• Pragma = 1#pragma-directive

• pragma-directive = "no-cache" / extension-pragma

• extension-pragma = token [ "=" ( token / quoted-string ) ]

• Pragma: no-cache has the same meaning as Cache-Control: no-cache

Use the cache as a condition for the current request response

URIs are matching

URI is used as the main cache key. When a URI corresponds to multiple caches at the same time, the cache with the latest date is selected
For example, the default cache key in Nginx: proxy_cache_key $scheme$proxy_host$request_uri ;

Responses in the cache allow the currently requested method to use the cache

Although there is a cache, there are still some conditions to use the cache. The first url needs to be matched, and the uri needs to be used as the cache keyword. The uri will correspond to multiple caches. At this time, choose the cache with the latest date.

Use the cache as a condition for the current request response

Responses in the cache must match headers specified in the Vary header with those in the request:

Vary = “*” / 1#field-name

Vary: * means that the match must fail (not a specific header)

• Neither the current request nor the cached response contains the no-cache header (Pragma: no-cache or Cache-Control: no-cache)

• The response in the cache must be one of the following:

• Fresh (not expired in time)

• The response header in the cache clearly informs that expired responses can be used (eg Cache-Control: max-stale=60)

• Use conditional requests to verify whether the request has expired on the server side, and get a 304 response

Vary cache

When the client goes to visit, the server uses gzip encoding. At this time, the proxy server caches gzip-encoded content. If client 2 comes to access, it clearly indicates that it can only accept the content compressed by the br algorithm. At this time, although there is the same url, the same url cannot be returned. The response returned for the first time has a vary header. The vary header must be based on content-encoding. At this time, a response must be obtained from the source server. At this time, another br response was saved.

When client3 needs br's response, it can directly use br's cache to return to client3.