Re: [Technical Errata Reported] RFC9111 (9004)

REJECT

Adding irrelevant text that does not apply to a given context, thereby disrupting a reader's chain of thought just to remind them of an irrelevant detail they couldn't possibly use anyway, does not improve the spec and certainly isn't an errata.

....Roy

> On Jun 11, 2026, at 11:06 AM, rfc-editor@rfc-editor.org wrote:
> 
> 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:48:24 UTC