Apply cache controls to the response
03A 451 response is cacheable by default, subject to method rules and explicit cache controls; this does not force a cache to store it.
In this separate case, a conforming empty cache does not store or reuse the response. No universal lifetime follows from 451.
Source for this drawing: RFC 7725 · Read RFC section 3 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Cacheable
- Eligible for storage under applicable cache rules, not guaranteed to be stored.
- Freshness
- The conditions and time during which a stored response may be reused without validation.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Cacheable by default does not mean always stored or reusable forever.
- RFC 7725 defines 451 as cacheable by default unless the method definition or explicit cache controls indicate otherwise. This describes the response, not permission to retrieve the denied content.
- Normal HTTP cache requirements still apply. Storage and later reuse are separate decisions; 451 alone does not set an unlimited freshness lifetime or require a cache to store the response.
- For a concrete comparison, a 451 response carrying Cache-Control: no-store is not stored or reused by a conforming cache in this example. This follows the supporting cache specification, not a new rule invented for 451. No-store is not by itself a sufficient privacy guarantee.
The drawing compares two independent response cases, starting from an empty cache, with no must-understand directive or overriding extension. Default eligibility is conditional; the no-store case prevents storage. Supporting current guidance: RFC 9111 §3 and §5.2.2.5 (https://www.rfc-editor.org/rfc/rfc9111.html#section-5.2.2.5). RFC 7725 originally references RFC 7234. No stored blocked content, expiry value or later successful fetch is asserted.
Read the RFC section ↗