Visual RFC.
ALL RFCs / RFC 8246
Read the RFC ↗
RFC 8246 / IMMUTABLE HTTP RESPONSES

Keep recovery and corruption safeguards

05

Skipping validation can amplify cache corruption. Three recommendations keep immutable from becoming an unconditional pin.

DIAGRAMRead RFC section 3 ↗
RFC 8246 · § 3EXAMPLE
3 / 3
Keep recovery and corruption safeguardsThree separate security cases show an unauthenticated HTTP context, a force reload for recovery, and a close-delimited response without a strong stored-size indication. In each case clients SHOULD ignore the immutable extension. Only the directive inference stops at the gate; no rejection of the entire response or mandated recovery algorithm is claimed. HTTPS is not a proof that cached content is correct.Do not let corruption become softly pinnedNo strong stored-size indicationExample: connection-close-delimited bodyResponse includes immutablerely on the immutable promiseSHOULD ignore immutableContinue with ordinary caching and security rulesIgnore extension ≠ reject the entire response
03
Check whether the stored size is trustworthy.

Separate close-delimited response example: the stored body lacks a strong size indication. Clients SHOULD ignore immutable; the directive does not certify completeness.

Source for this drawing: RFC 8246 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9111 Caching RFC 9110 HTTP

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Cache poisoning
An attacker or failure causes incorrect bytes to be stored in a cache.
Authenticated context
A context such as HTTPS that protects the peer/transport exchange.
Close-delimited
A response whose end is indicated by closing the connection.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

A cache promise is not proof that cached bytes are sound.

  • Clients SHOULD ignore immutable for resources outside an authenticated context such as HTTPS. This mitigates cache-poisoning risk; it is not a general ban on HTTP caching.
  • Force reloads used to repair interrupted or corrupted loads, typically signaled with no-cache, SHOULD ignore immutable as well.
  • Clients SHOULD ignore immutable when there is no strong indication that stored response size is correct, such as a response delimited by connection close.
DETAILS

These are SHOULD recommendations, not invented MUST rejection rules. The gate ignores the immutable extension, not the entire response: ordinary caching and security rules still apply. HTTPS helps authenticate the transport context but does not prove that content is correct, malware-free or properly authorized. No particular body-length proof or corruption-repair algorithm is mandated.

Read the RFC section ↗

All chapters in RFC 8246

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗