Code change:
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.

Related discussion:
text: This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message content. <del> Also, private response directives with field names are often handled by caches as if an unqualified private directive was received; i.e., the special handling for the qualified form is not widely implemented. </del> <ins> Also, the qualified form of the directive is often handled by caches as if an unqualified private directive was received; i.e., the special handling for the qualified form is not widely implemented. </ins> 5.2.2.8. <del> The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches. </del> <ins> The "proxy-revalidate" response directive indicates that once the response has become stale, a shared cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by validation.model.  This is analogous to must-revalidate (cache-response-directive.must- revalidate), except that proxy-revalidate does not apply to private caches. Note that "proxy-revalidate" on its own does not imply that a response is cacheable.  For example, it might be combined with the public directive (cache-response-directive.public), allowing the response to be cached while requiring only a shared cache to revalidate when stale. </ins> 5.2.2.9.