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 will add any Age:
... continue reading