[Technical Errata Reported] RFC9111 (9004)

The following errata report has been submitted for RFC9111,
"HTTP Caching"

--------------------------------------
You may review the report below and at:
https://errata.rfc-editor.org/eid9004/

--------------------------------------
Type: Technical
Reported by: zhangph <zhangph12138@163.com>

Section 3.5 says:

Original Text
-------------
A shared cache MUST NOT use a cached response to a request with an
Authorization header field (Section 11.6.2 of [HTTP]) to satisfy any
subsequent request unless the response contains a Cache-Control field
with a response directive (Section 5.2.2) that allows it to be stored
by a shared cache, and the cache conforms to the requirements of that
directive for that response.  In this specification, the following
response directives have such an effect: must-revalidate
(Section 5.2.2.2), public (Section 5.2.2.9), and s-maxage
(Section 5.2.2.10).

Corrected Text
--------------
A shared cache MUST NOT use a cached response to a request with an
Authorization header field (Section 11.6.2 of [HTTP]) to satisfy any
subsequent request unless the response contains a Cache-Control field
with a response directive (Section 5.2.2) that allows it to be stored
by a shared cache, and the cache conforms to the requirements of that
directive for that response.  In this specification, the following
response directives have such an effect: must-revalidate
(Section 5.2.2.2), public (Section 5.2.2.9), and s-maxage
(Section 5.2.2.10).  Note that proxy-revalidate (Section 5.2.2.8) is
not included here: although Section 5.2.2.8 states it is analogous to
must-revalidate, it governs revalidation behavior after a response
becomes stale and does not itself authorize a shared cache to store a
response to an authenticated request.

Notes
-----
Section 5.2.2.8 states that proxy-revalidate "is analogous to must-revalidate (Section 5.2.2.2), except that proxy-revalidate does not apply to private caches" — i.e., proxy-revalidate is the shared-cache-specific counterpart of must-revalidate. However, the list in Section 3.5 of response directives that allow a shared cache to store a response to an authenticated request includes must-revalidate but omits proxy-revalidate. This creates an apparent inconsistency between Sections 3.5 and 5.2.2.8. This is submitted as Editorial. The proposed corrected text adds a clarifying note explaining why proxy-revalidate is excluded (it governs revalidation after staleness, not storage authorization), so the relationship between the two sections is made explicit and reader confusion is removed. No change to caching behavior is requested.

Instructions:
-------------
This erratum is currently posted as "Reported". Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC9111 (draft-ietf-httpbis-cache)
--------------------------------------
Title               : HTTP Caching
Publication Date    : June 2022
Author(s)           : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
Category            : Internet Standard
Source              : httpbis (wit)
Stream              : IETF
Verifying Party     : IESG

Received on Thursday, 11 June 2026 18:08:11 UTC