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

Storing responses with Authentication #161

mnot opened this issue Oct 16, 2018 · 2 comments

Storing responses with Authentication #161

mnot opened this issue Oct 16, 2018 · 2 comments


Copy link

mnot commented Oct 16, 2018

3.2. Storing Responses to Authenticated Requests lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.

@mnot mnot closed this as completed in d4695a3 Nov 12, 2018
reschke added a commit that referenced this issue Nov 13, 2018
mpdude added a commit to mpdude/http-core that referenced this issue Dec 3, 2019
… be stored

In httpwg#161, the suggestion was made to explicitly note when a directive
allows the response to be cached, even with Authorization being used.

According to section `caching.authenticated.responses`, `public` also
has this effect, so I added a note there.

Additionally, in `cache-response-directive.s-maxage`, I tried to
make it clearer that `s-maxage` overrides Authorization as well,
due to the implication of proxy-revalidate and thus must-revalidate.
Copy link

mpdude commented Dec 3, 2019

I think this should also be added for public; see #269.

Copy link

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.

@royfielding royfielding reopened this Feb 6, 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

No branches or pull requests

3 participants