Code change:
5.2.2.1. <del> The "must-revalidate" response directive indicates that once it has become stale, the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. </del> <ins> The "must-revalidate" response directive indicates that once the response has become stale, a cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by validation.model. </ins> The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a <del> cache is disconnected, it MUST generate a </del> <ins> cache is unable to validate a stale response containing must- revalidate, for any reason, the cache MUST generate a </ins> <del> response. </del> <ins> response rather than reuse the stale response. </ins> The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could result in incorrect operation, such as a silently unexecuted financial transaction. <del> The must-revalidate directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </del> <ins> The must-revalidate directive also permits a shared cache to reuse a response to a request containing an Authorization header field, subject to the above requirement on revalidation (caching.authenticated.responses). </ins> 5.2.2.2.

Related discussion:
text: This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.