Detailed Explanation of the HTTP Caching Mechanism

In network application development, improving the access speed and efficiency of websites is of great significance. Designing various types of caches can effectively avoid unnecessary data transmission and requests, significantly accelerating the response speed of websites. The HTTP protocol itself has a built-in HTTP caching mechanism. This article will delve into the HTTP caching mechanism and its applications.

Types of Caches in HTTP

The principle of caching is to store a copy of the requested resource locally so that when the request is made again, the copy can be directly returned instead of downloading it from the server again, thus reducing resource transmission and improving efficiency. In addition to directly accessing and returning resources, HTTP caches are mainly divided into two categories:

Shared Cache: Different clients can obtain resources from the shared cache, which is suitable for scenarios where multiple clients access the same resources. It is commonly applied in Web proxy servers. Many users can share the resource copies on the server, avoiding repeated saving by each user and reducing invalid copying of resources.
Private Cache: Only specific users or clients can access it, and others have no access rights. Browser caches usually belong to private caches, which only serve the current browser and will not be shared with other browsers.

Status of Cached Responses in HTTP

HTTP caching generally applies to GET requests because GET requests usually have no other parameters except the URI and are mainly used to obtain resources from the server. Different GET requests will return different status codes:

200 OK: The resource is successfully returned.
301: Redirection.
404: The requested resource does not exist, and an exception occurs.
206: An incomplete result is returned.

Cache Control in HTTP

HTTP cache control is implemented through HTTP headers. In HTTP 1.1, Cache-Control was introduced, and with its help, the caching behavior of requests and responses can be finely controlled:

No Caching: Using Cache-Control: no-store ensures that the resource will not be cached.
Cache Validation: Cache-Control: no-cache requires the validation of the client cache.
Mandatory Validation: Cache-Control: must-revalidate, and expired resources will not be allowed to be used.
Cache Scope Control: The server can control whether the cache is private or public through Cache-Control: private or Cache-Control: public.
Expiration Time Setting: Cache-Control: max-age=31536000 sets the valid time of the resource, overriding the Expires header. Within this time, the resource is considered up-to-date and does not need to be re-obtained from the server.

In HTTP 1.0, the Pragma field can achieve similar functions. For example, Pragma: no-cache has a similar effect to Cache-Control: no-cache, forcing the client to submit the cache to the server for verification. However, the server response usually does not contain Pragma, so Pragma cannot completely replace Cache-Control.

Cache Refresh

After the client caches the resource, for security reasons, an expiration time needs to be set. Only within the expiration time is the cache valid; if it exceeds the expiration time, the resource needs to be re-obtained from the server. This mechanism ensures that the resources obtained by the client are always up-to-date, and the updates on the server side can be synchronized to the client in a timely manner.

Cache Status: If the client resource is within the expiration time, the status is fresh; otherwise, it is stale.
Expiration Handling: When the resource is in a stale state, it will not be immediately cleared from the client. Instead, in the next request, an If-None-Match request will be sent to the server to determine whether the resource on the server side is still fresh. If the resource has not changed, the server returns 304 (Not Modified), indicating that the resource is still valid.
Freshness Calculation: The fresh duration of the resource is determined by Cache-Control: max-age=N. If this header field is not present in the response, check whether the Expires header exists. If it exists, the fresh time is Expires - Date. If neither exists, look for the Last-Modified header, and the fresh time is （Date - Last-modified ）/ 10.

Revving

To improve the efficiency of HTTP requests, it is generally desirable to have a longer cache time. However, an overly long cache time will make it difficult to update server resources. For files that are not frequently updated, the file name and version number can be added to the request URL. The same version number indicates that the resource content has not changed and can be cached for a long time. When the content of the server resource changes, only the version number in the request URL needs to be updated. With the help of modern front-end packaging tools, it is not difficult to implement this operation.

Cache Verification

When the cached resource expires, there are two ways to handle it: request the resource from the server again or re-verify the cached resource. Re-verification requires server support and setting the Cache-Control: must-revalidate request header.

Verification Method: When the client verifies the validity of the resource, it cannot directly send the resource to the server, otherwise, it will cause a waste of resources. HTTP provides the ETags header as a unique identifier for the resource. The client sends an If-None-Match request to let the server determine whether the resource matches, which is a strong verification. If the response contains Last-Modified, the client can send an If-Modified-Since request to ask the server whether the file has changed, which is a weak verification.
Server Response: The server can choose whether to perform file verification. If it does not verify, it directly returns the 200 OK status code and the resource; if it verifies, it returns 304 Not Modified, informing the client that it can continue to use the cached resource. At the same time, it can return other header fields, such as updating the expiration time of the cache.

Vary Response

The server can carry the Vary header in the response, and its value is a certain key in the response header, such as Content-Encoding, indicating that the resource is cached for a specific encoding. For example:

First Request: The client sends GET /resource HTTP/1.1, Accept-Encoding: *, and the server returns HTTP/1.1 200 OK, Content-Encoding: gzip, Vary: Content-Encoding. At this time, the resource and the Content-Encoding with gzip encoding will be cached together.
Subsequent Request: The client sends GET /resource HTTP/1.1, Accept-Encoding: br. Since the encoding of the current cached resource is gzip, which is different from the br expected by the client, the resource needs to be re-obtained from the server. The server returns HTTP/1.1 200 OK, Content-Encoding: br, Vary: Content-Encoding, and the client caches the resource in the br format again. The next time the client requests a resource of the br type, it can hit the cache.

Vary implements caching by additionally classifying resources (such as encoding types), but it will lead to repeated storage of resources. To solve this problem, the resource request needs to be standardized, that is, the encoding method is verified before the request, and one encoding is selected for the request to avoid multiple caches.

Conclusion

This article comprehensively introduces the HTTP caching mechanism, covering cache types, response statuses, cache control, cache refresh, Revving, cache verification, and Vary responses. In practical applications, a deep understanding and reasonable application of the HTTP caching mechanism can help improve website performance and user experience.