Dated report · 19 Oct 2026 · RFC 9111 interpretation
Does proxy-revalidate permit shared reuse of an Authorization response?
Not by itself. RFC 9111 lists three response directives that permit a shared cache to reuse a response to a request containing Authorization; proxy-revalidate is not one of them.
Finding
RFC 9111 §3.5 says a shared cache must not reuse a response to an Authorization request unless the response explicitly permits shared reuse with must-revalidate, public, or s-maxage. The list does not include proxy-revalidate. A response carrying only proxy-revalidate therefore does not gain that permission from this directive. RFC 9111 §3.5.
This permission is separate from whether a representation is safe to share. A cache must still apply the response's ordinary storage, key-matching, freshness, and validation rules; the directive list is not a privacy assessment.
Do not confuse authorization permission with stale validation
| Directive or section | Role in this question |
|---|---|
§3.5: must-revalidate, public, s-maxage | The three listed response directives that can permit shared-cache reuse for a request carrying Authorization. |
§5.2.2.8: proxy-revalidate | For a shared cache, this governs reuse after a response becomes stale: validation is required before stale reuse. It is not an additional permission in §3.5. |
§5.2.2.9: public and §5.2.2.10: s-maxage | These separate directive definitions describe their shared-cache effects; both also appear in §3.5's authorization permission list. |
Practical reading: check the §3.5 authorization gate first. Do not count proxy-revalidate alone as permission to share an authenticated response; when an explicit permission applies, the relevant freshness and revalidation requirements still matter.
Erratum 9004 is not a confirmed standards change
An erratum submission proposed adding a clarifying sentence that proxy-revalidate is not among §3.5's permissions, and described the proposal as requesting no behavior change. The accessible IETF archive record was marked Reported when checked for this review; a co-author reply said “REJECT.” The final formal disposition was not confirmed from the accessible record, so this report treats the submission as an unconfirmed clarification—not an accepted correction or a changed rule.
IETF HTTP working-group archive: Erratum 9004 submission · Co-author reply
Method and limits
This is a standards-text and erratum-record review, not an interoperability test. It establishes the RFC's normative distinction; it does not show how any particular cache implements it, what a provider configured, or whether a user-specific representation was exposed. The erratum's final disposition remains unconfirmed in the accessible archive record.
Checkable sources
- RFC 9111 §3.5 — Cache Handling of Authentication Information: shared-cache permission list for requests containing
Authorization. - RFC 9111 §5.2.2.8 — proxy-revalidate, §5.2.2.9 — public, and §5.2.2.10 — s-maxage: directive definitions and stale-validation behavior.
- IETF HTTP working-group archive — Erratum 9004 submission and co-author reply: process context only, not normative text.