Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public and Private vs. the world #320

Closed
mnot opened this issue Feb 19, 2020 · 2 comments · Fixed by #338
Closed

Public and Private vs. the world #320

mnot opened this issue Feb 19, 2020 · 2 comments · Fixed by #338

Comments

@mnot
Copy link
Member

mnot commented Feb 19, 2020

The language for Cache-Control: public and private indicates that they override the rest of the caching model unconditionally; as discussed in #319, that is too broad.

Also, public is often used even though the message is still cacheable, because developers misunderstand its semantics.

@mnot mnot added the caching label Feb 19, 2020
@mnot mnot self-assigned this Feb 19, 2020
@mnot
Copy link
Member Author

mnot commented Mar 18, 2020

The text in question for private:

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:

  1. "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).

  2. 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.

@mnot
Copy link
Member Author

mnot commented Mar 18, 2020

For public, we have:

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]).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

1 participant