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

Clarify "private" and "public" #268

Closed
mnot opened this issue Dec 3, 2019 · 1 comment · Fixed by #290
Closed

Clarify "private" and "public" #268

mnot opened this issue Dec 3, 2019 · 1 comment · Fixed by #290

Comments

@mnot
Copy link
Member

@mnot mnot commented Dec 3, 2019

From https://www.w3.org/mid/9F36A6F8-0276-4F8C-B063-C4619901EBB1@webfactory.de:

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 (https://tools.ietf.org/html/draft-ietf-httpbis-cache-06#section-3) 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"?

@mnot mnot added the caching label Dec 3, 2019
@mpdude
Copy link

@mpdude mpdude commented Dec 3, 2019

OP here 👋🏻

@mnot mnot self-assigned this Feb 2, 2020
mnot added a commit that referenced this issue Feb 3, 2020
reschke added a commit that referenced this issue Feb 3, 2020
@mnot mnot closed this in #290 Feb 3, 2020
reschke added a commit that referenced this issue Feb 4, 2020
royfielding added a commit that referenced this issue Mar 6, 2020
Restore some 2616 wording on public, must-revalidate, and proxy-revalidate

This ended up being an editorial change between drafts because the only normative changes were already noted for #264 and #268, and this is just rewording what we had for #161.
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.

2 participants