HTTP devices can keep copies of popular documents. Maintaining a cache of the previous resources allows the client to use a local copy of the resource, thereby eliminating unnecessary HTTP requests.
Important HTTP headers related to the web cache
Normally, making an HTTP cache is about three HTTP headers: Cache-control, Last-modified, and Etag. They all available in both the request header and response header.
- Cache-control header specifies the cache lifetime(max-age) of the resource.
- Last-modified and ETag header provides a validation mechanism. Generally speaking, last-modified validate the resource with time and Etag does it with content(hash).
Two things need to be born in mind:
Specifying a lifetime for each resource with Cache-control header.
Specifying a validation mechanism to allow the client to check the availability of the resource(if it expired or updated).
You should always specify both the cache lifetime and validation methods to avoid either redundant resource transfers(missing validation methods) or redundant checks(missing lifetime).
Cache types
Caches can be divided into two categories: private caches and shared caches.
Private cache stores resources for a single user. Web browsers have private caches build in with client-side storage.
Shared cache can be reused by more than one user. For example, a web proxy or CDN can cache resources for many users.
How web cache works
In general, freshness and validation decide how web cache work. Fresh resources are served directly from the cache without checking the origin server. If it is stale, the origin server will be asked to validate it.
Fresh and stale cache
As HTTP is a client-server protocol, serves cannot contact caches and clients when resource changes, they have to communicate an expiration time for the cache. Before expiration, the cache is fresh, after it is stale. When the stale cache receives a request, it forwards this request with an If-None-Match to check if it is still fresh. If so, the server returns a 304(Not modified) header without the body of the requested resource.
You can use Cache-Control: max-age = 3600 or Expires: Fri, 30 Oct 1998 14:19:41 GMT headers to set a freshness lifetime. When both Cache-Control and Expires are presented, Cache-Control takes precedence.
The freshness lifetime is calculated by several headers. If Cache-Control: max-age = n is specified, then the freshness lifetime is equal to n. If not, it checks the Expires header.
Cache validation
Time-based:
Response header: Last-Modified
Request header: If-Modified-Since
Content-based:
Response header: Etag
Request header: If-None-Match
The first time, the client requests a resource, and the server sends the resource back with cache headers. The second time the client requesting the same resource, if it is fresh, then the client gets the resource from the cache directly. If it is stale, the client sends a request with the header If-None-Match to the server to validate if the resource is still available. If it does, the client gets the resource from the cache and refreshes its freshness lifetime. The rules apply to Time-based validation.
If both of Last-Modified and Etag are exits, the server will check both of the headers and either return 304 or new content.
Best practice
There are some rules for controlling how HTTP cache works. Generally, there are most common rules to be followed:
If the cache is fresh, the HTTP request sends from the browser gets a response directly from the cache without checking with the server.
If the cache is stale, the original server will be asked to validate whether the copy is still good. If it is, the server will respond with status code 304, which means “not modified”, and refresh the cache.
Under certain circumstances, for example, when it’s disconnected from the network, the stale content can be served without checking with the original server.
Common settings of Cache-Control
Expires and pragma headers are outdated, as a result, cache-control is mainly used in modern days.
Below are some common settings for the cache-control header:
max-age=[seconds] — specify the maximum amount of time that a cache can be considered as fresh.
private — the content can only be cached in the client and only used for the user.
public — the content can also be cached in the proxies for multiple users.
no-store — the content cannot be cached anywhere.
no-cache — the content can be cached but requires validation every time a request is reached.