It also indicates that a private cache &MAY; store the response, subject
to any other cache directives present, even if the response would not
otherwise be heuristically cacheable by a private cache.
If a qualified private response directive is present, with an argument that
lists one or more field names, then only the listed fields are limited to a
single user: a shared cache [...] &MAY; store the remainder of the
response message without those fields.
I think there are two problems here:
"subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability).
The second paragraph omits any such condition.
I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add private to the list in section 3 (probably below public.
The "public" response directive indicates that a cache &MAY; store the
response even if it would otherwise be prohibited, subject to the
constraints of any other response directives present. In other words,
public explicitly marks the response as cacheable.
Similar to above, I think it should be "subject to the constraints defined in [ref to section 3].
A note like this would also help:
Note that it is not necessary to add public to a response if the response is explicitly fresh (e.g., due to the presence of the max-age response directive or the Expires header), or if the response is heuristically cacheable (e.g., the 200 and several other response status codes; see [ref to heuristic]).
The language for
privateindicates that they override the rest of the caching model unconditionally; as discussed in #319, that is too broad.
publicis often used even though the message is still cacheable, because developers misunderstand its semantics.
The text was updated successfully, but these errors were encountered: