HTTP Caching, a Refresher

Summary

HTTP caching, a refresher Published Dec 22, 2025 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 Cache-Control: max-age=<number> directive on the response; otherwise, the cache falls back to computing the interval between the Expires: <date> and Date: <date> response ...