Article starts on my personal blog: blog. Fstars. Wang / 2019/12/04 /…
A brief description of cache-related header fields in THE HTTP protocol. This article is more like a book note and has been condensed.
If-Modified-Since
Corresponding to the last-modified. The server returns a resource with last-Modified, indicating the time when the resource was Last modified. If the client caches data, it needs to save this time and carry it with if-modified-since on the next request to let the server determine whether the resource was last Modified at the same time. If so, 304 is returned, allowing the client to use the local cache directly. Otherwise, the resource has been modified and the new resource and the new Last-Modified are returned.
Last-modified
The time when the resource was last Modified, used with if-modified-since. Belongs to the response header field.
ETag
A specific version identifier of a resource, which can be analogous to a software version number, must be used with if-none-match. The E stands for Entity.
If-None-Match
The effect is similar to if-modified-since, where the client retrieves the ETag field in the response header the first time it requests a resource and stores it. The next request is made as the value of the if-none-match header field. ETag usually uses a weak comparison algorithm, that is, if two resources have the same semantics, it is considered as a successful match. If the match is successful, 304 is returned, otherwise a new resource and a new ETag are returned. In addition, ETag usually starts with a W/ to indicate that a weak matching algorithm is used. ETag can be used to track users and, to some extent, as an alternative to cookies. This header field has a higher priority than if-modified-since.
Cache-Control
Generic header fields, which have different semantics in the request header and response header, are used for cache control. In the response header, there are many values to choose from:
max-age=<seconds>Indicates the validity period of the resources provided by the server, in seconds. Note that the validity period is calculated from the time when the response packet is generated. This is different from cookie counting from the moment the client receives the responseno-storeIndicates that the client is not allowed to cache. This is usually used for dynamic pages, such as the front page of a Micro blog.no-cacheIndicates that each time a client uses the local cache, it must verify with the server.must-revalidateIndicates that the cache can be used, but if you want to continue to use the cache after its expiration, you must first go to the server for verification.privateIndicates that the client can cache, but the proxy server cannot cache. For example, on the personal homepage, the interface returns a set-cookie field during loginpublicIndicates that both client and proxy servers can be cached. A proxy server can serve as a content cache.proxy-revalidateWorks in a similar waymust-revalidate, but on a proxy server. After the cache of the proxy server expires, the proxy server needs to request the source server for authentication, and the client is not involved.s-maxage=<seconds>The validity period of the cache on the proxy. The s here refers to share.no-transformIndicates that the agent is not allowed to modify the resource. This is because agents sometimes optimize resources, such as converting images in common formats to webP format with less storage space and returning them to browsers that support the format to reduce bandwidth. Setting this value disables these operations.
On the client side, the values are
max-age=0Indicates that the client is no longer using the old local cache (the expiration date has been set to 0) and expects the server to return an updated resource.no-cacheThe effect withmax-age=0.max-stale=<seconds>This parameter is applicable only to agents. Resources are still valid within a specified period of time after they expire.min-fresh=<seconds>Indicates that the client expects the resource to remain up to date for a certain period of timeonly-if-cachedIndicates that the client only accepts data cached by the proxy. If the proxy does not cache data, the client cannot return to the source to obtain new resources and return them to the client.
Expire
The resource is invalid. The priority is lower than cache-control. Example: Expires: Thu, 05 Dec 2019 16:27:43 GMT
vary
It is mainly used for the proxy server to implement the cache service and belongs to the response header field. Different clients support different content formats (for example, some support data compression, others do not), so the server will return different data even if the request URL and request method are the same (called content negotiation). The Vary field records which request fields the proxy server refers to to return specific data. For a more detailed introduction, see my other article on the role of the Vary header field in response messages
Via
A generic field that records information about the passing proxy node. It is used on the proxy server and the source server. If the request sent by the client passes through proxy server A and proxy server B and finally reaches the source server, the source server receives the fields Via: A, B. The purpose of this header field is to track the forwarding of messages and prevent the formation of a loop between proxy servers resulting in an infinite loop of messages.
X-Forwarded-For
Via does not record the actual sender client IP, so this is a de facto standard that is not part of the HTTP standard. This field records the IP address of the request party of the current node. That is, the value of this field is X-Forwarded-For: Client, A, and B. In addition, in order to solve The cost caused by The need to parse The modified data of HTTP packets to add information during PROXY forwarding, The PROXY Protocol appears. The principle is to put some information before HTTP packets. The specific principle is not introduced in detail in this paper.
X-Real-IP
Only the IP address of the client is recorded.