Resent-Date: Thu, 11 Jun 2026 18:48:27 +0000
Resent-Message-Id: <E1wXkS3-00Duo2-01@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gbiv.com designates 23.83.209.82 as permitted sender) client-ip=23.83.209.82; envelope-from=fielding@gbiv.com; helo=heron.birch.relay.mailchannels.net;
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <178120118333.18.17085303167778859848@rfc-editor.org>
Date: Thu, 11 Jun 2026 11:47:59 -0700
Cc: Martin Thomson <mt@lowentropy.net>,
 mbishop@evequefou.be,
 Mark Nottingham <mnot@mnot.net>,
 Julian Reschke <julian.reschke@gmx.de>,
 Francesca Palombini <francesca.palombini@ericsson.com>,
 gorry@erg.abdn.ac.uk,
 ietf-http-wg@w3.org,
 zhangph12138@163.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FA910EA-7C46-4293-B8BD-F89B1240E1CD@gbiv.com>
References: <178120118333.18.17085303167778859848@rfc-editor.org>
To: rfc-editor@rfc-editor.org
Subject: Re: [Technical Errata Reported] RFC9111 (9004)
Archived-At: <https://www.w3.org/mid/8FA910EA-7C46-4293-B8BD-F89B1240E1CD@gbiv.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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=E2=80=AFAM, rfc-editor@rfc-editor.org wrote:
>=20
> The following errata report has been submitted for RFC9111,
> "HTTP Caching"
>=20
> --------------------------------------
> You may review the report below and at:
> https://errata.rfc-editor.org/eid9004/
>=20
> --------------------------------------
> Type: Technical
> Reported by: zhangph <zhangph12138@163.com>
>=20
> Section 3.5 says:
>=20
> 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).
>=20
> 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.
>=20
> 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" =E2=80=94 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.
>=20
> 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 =20
> will log in to change the status and edit the report, if necessary.
>=20
> --------------------------------------
> 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
>=20