Code change:
Argument syntax: <del> The "s-maxage" response directive indicates that, in shared caches, </del> <ins> The "s-maxage" response directive indicates that, for a shared cache, </ins> the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the <del> header field.  The s-maxage directive also implies the semantics of the proxy-revalidate response directive. </del> <ins> header field. </ins> <del> The s-maxage 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 s-maxage directive incorporates the proxy-revalidate (cache- response-directive.proxy-revalidate) response directive's semantics for a shared cache.  A shared cache MUST NOT reuse a stale response with s-maxage to satisfy another request until it has been successfully validated by the origin, as defined by validation.model. This directive also permits a shared cache to reuse a response to a request containing an Authorization header field, subject to the above requirements on maximum age and revalidation (caching.authenticated.responses). </ins> This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'.  A sender MUST NOT generate the

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.