RFC 9111 / START HERE
Caching, before the details
HTTP caching
An HTTP cache stores responses so they can sometimes be reused. This RFC explains when a stored response is fresh, when it needs checking, and when reuse is forbidden.
The idea in one picture
A response is stored
The cache checks reuse rules
A saved or refreshed response is used
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Downloading the same content repeatedly costs time and bandwidth. Reuse is useful only when the response is suitable for the new request.
A familiar example
Your browser reuses a recently downloaded logo, or asks the server whether an older copy is still current.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Store and select a responseA cache first decides whether storage is permitted, then whether a stored response matches a later request.→
- Freshness and ageA response is fresh when its freshness lifetime exceeds its current age, after accounting for transit and time in caches.→
- Revalidate with 304A conditional request asks the origin whether a stored representation can still be used.→
- Cache-Control directivesDirectives separately control storage, validation, freshness, transformation, and shared-cache behavior.→
- Private and shared cachesA browser cache serves one user. A shared cache can answer requests from many users and needs stricter safeguards.→
- Stale responses and invalidationExpiry does not always mean deletion. A state-changing success can require invalidation of a saved answer.→
This introduction explains RFC 9111 (2022). Read the original RFC ↗