Visual RFC.
ALL RFCs / RFC 9211
Read the RFC ↗
RFC 9211 / HTTP CACHE-STATUS

Expose useful diagnostics carefully

05

Keys and implementation details help debugging but can expose sensitive cache behavior.

DIAGRAMRead RFC section 2.7 ↗
RFC 9211 · § 2.7EXAMPLE
4 / 4
Expose useful diagnostics carefullyA quoted cache name with comma is one String and key is a String; detail MEMORY is a Token. Separate CacheA/B FAST details have different explicitly fictional local meanings. Chosen policy stops key before disclosure and outgoing report omits key. Separate local malformed-request400not based on stored response follows SHOULD NOT append; stored-response-based304/206remain an exception. No production privacy or authorization setting changes.Useful diagnostics can expose sensitive behaviorProxy generates local responseHTTP/1.1 400 Bad Requestappend local Cache-StatusSHOULD NOT append · not based on stored dataStored-response-based 304 / 206 is a different case
04
Usually leave a local malformed-request400 unreported.

A proxy’s local400 is not based on a stored response, so the pictured choice follows SHOULD NOT append. A304or206based on a stored response is a different permitted situation, not a blanket prohibition on local status codes.

Source for this drawing: RFC 9211 · Read RFC section 2.7 ↗

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

A request starts a conversation.

A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.

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.

Related RFCs and changes

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

KEY POINT

Diagnostic information is neither a portable policy nor an access grant.

  • key is a String representation of the implementation-specific cache key. detail is a String or Token with semantics specific to the sending cache. The same detail value from two caches can mean different things.
  • Cache-Status can help attackers probe stored data, activity and key construction, including cache-poisoning opportunities. Merely obfuscating the cache key does not remove that risk.
  • The RFC describes options: omit the field, send it only to authorized clients, or restrict sensitive parameters such as key. It does not mandate public diagnostics or define an authorization scheme.
  • An intermediary SHOULD NOT append its report to locally generated responses unless based on a stored response. A local malformed-request400 is different from a stored-response-based304or206.
  • New interoperable parameters can be registered through expert review in the HTTP Cache-Status registry. A specification is appreciated, not required. Do not treat an arbitrary detail string as a standardized extension.
DETAILS

No real cache keys, users or debug permissions are tested. The guide teaches RFC9211reporting; it does not authenticate cache reports, change cache policy or claim a complete Structured Fields implementation.

Read the RFC section ↗

All chapters in RFC 9211

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 ↗