HTTP caching, a refresher

HTTP caching, a refresher This is a reading of RFC 9111 (2022), the latest iteration of the HTTP Caching standard. It defines the Cache-Control HTTP header as a way to prescribe how caches should store and reuse HTTP responses, with regards to not just the browser cache, but to any other intermediary caches, such as proxies and content delivery networks, that may exist between the client and the origin server. The Cache-Control header accepts a set of comma-separated directives, some of which are meant to be added to HTTP requests, and others to HTTP responses. A typical response header: HTTP/2 200 Cache-Control: max-age=0, must-revalidate Some of these directives specifically target shared caches , that is intermediary caches that serve the same cached responses to many users, while others also apply to private caches such as the browser cache. What’s fresh? Whenever the cache receives a request, it must figure out if the cached response is still fresh and can therefore be reused without incurring the performance tax of an HTTP request, or whether it has gone stale and should be validated with the server. To decide on freshness, the cache compares the age of the response to the response’s so-called freshness timeline. The age of a cached response is the time elapsed since it was last generated or revalidated by the origin server. To the time spent in its own cache, the browser must add any Age: <seconds> header received from intermediary caches. The freshness timeline is a duration beyond which the cached response is to be considered stale. It’s usually signaled by the server via the appropriate response headers, but may also be guesstimated by the cache in the absence of explicit cues. In order of precedence: the server establishes a freshness timeline, in seconds, with the directive on the response; otherwise, Cache-Control: max-age=<number> the cache falls back to computing the interval between the Expires: <date> and Date: <date> response headers, if available; otherwise, if there’s no Expires header, the response lacks an explicit expiration, and a heuristic freshness based on the Last-Modified response header might be applicable. For shared caches, the special s-maxage=<number> directive takes precedence over all others. Going past expiration Just because a response has gone stale, it doesn’t mean it needs to be thrown out. When it receives a request for a stale cached response, the cache should validate it with its upstream server. Although validation always generates an HTTP request, it avoids a data transfer when there’s no newer version of the cached response on the server, so it can still be faster than a regular request. Validation uses a mechanism known as a conditional HTTP request, which includes one or more special headers called preconditions: if the precondition with the highest precedence is met, the server responds with HTTP 200 OK and an updated response body; otherwise, it responds with HTTP 304 Not Modified and an empty body, confirming the existing response can be reused. To generate the preconditions needed for these conditional...

Preview: ~500 words