RFC 8246 / START HERE
Immutable responses, before the details
HTTP Immutable Responses. HTTP means Hypertext Transfer Protocol; immutable means not changing within the response’s freshness lifetime.
This HTTP extension lets a server promise that one response will stay unchanged while it is fresh. A client can then skip an otherwise unnecessary check with the server, even on an ordinary reload.
The idea in one picture
Publish a stable version
Keep it while fresh
Use a new URL for changes
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
A page can reference versioned stylesheets or images whose contents stay fixed at each address. Without this signal, reloading the page can cause many needless checks for those unchanged resources.
A familiar example
A site publishes a changed stylesheet at a new URL and updates the page’s link. The old cached stylesheet stays at its own URL; expiry, explicit force reloads and corruption safeguards still matter.
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.
- Publish changes under a new URLA versioned resource keeps its old URL stable; a changed resource receives a new URL and updated references.→
- Keep the promise within freshnessA fresh immutable response can skip ordinary reload revalidation. Expiry or an explicit user override changes that decision.→
- Read the response directiveImmutable is a Cache-Control response extension with no meaningful arguments; putting it in a request has no effect.→
- Let a proxy answer from its fresh cacheAn intermediary can use immutable too, while client validation signals still matter.→
- Keep recovery and corruption safeguardsSkipping validation can amplify cache corruption. Three recommendations keep immutable from becoming an unconditional pin.→
This introduction explains RFC 8246 (2017). Read the original RFC ↗