From the point of view of normative references — RFC 9110: HTTP Semantics and RFC 9111: HTTP Caching — what is the rationale of having the must-revalidate cache directive have the effect of allowing shared caches to store and reuse responses for requests that bear an Authorization header field?
RFC 9111 § 3.5. Storing Responses to Authenticated Requests states (emphasis mine):
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).
While I can understand public and s-maxage as more or less direct indications that the response should be available on shared caches, what exactly about the behavior of must-revalidate leads one to intuit this must have a side-effect on authenticated requests? And why has that not carried over proxy-revalidate as well?
---
As a secondary curiosity, RFC 9110 § 12.5.5. Vary states (emphasis mine):
There is no need to send the Authorization field name in Vary because reuse of that response for a different user is prohibited by the field definition (Section 11.6.2). Likewise, if the response content has been selected or influenced by network region, but the origin server wants the cached response to be reused even if recipients move from one region to another, then there is no need for the origin server to indicate such variance in Vary.
What about the (very short) Authorization field definition in RFC 9110 § 11.6.2. Authorization prohibits the reuse of authenticated responses between users?
The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. [...]
If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
A proxy forwarding a request MUST NOT modify any Authorization header fields in that request. See Section 3.5 of [CACHING] for details of and requirements pertaining to handling of the Authorization header field by HTTP caches.
Is it the note about caching requirements, which can easily/accidentally be overwritten with several cache control directives? Or is there any other section that suggest that the Authorization header is somehow auto-Varyed when the cache evaluates potential responses?
If it’s not, isn’t stating there’s no need to Vary the Authentication header misleading? A need would be to prevent responses to be shared between users.