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.

Sign up for GitHub

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

Jump to bottom

Storing responses with Authentication #161

Closed
mnot opened this issue Oct 16, 2018 · 2 comments
Closed

Storing responses with Authentication #161

mnot opened this issue Oct 16, 2018 · 2 comments
Labels
caching editorial

Comments

@mnot
Copy link
Member

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
@reschke
Change log (#161)
b189ed3
reschke added a commit that referenced this issue Dec 2, 2018
@reschke
fix changelog breakage caused by myself (#161)
5635a49
@royfielding royfielding mentioned this issue Nov 12, 2019
Closed
mpdude added a commit to mpdude/http-core that referenced this issue Dec 3, 2019
@mpdude
Explcitly state that "public" allows responses with Authentication to…
e3c7ec2 
… 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.
@mpdude mpdude mentioned this issue Dec 3, 2019
Closed
@mpdude
Copy link

mpdude commented Dec 3, 2019

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

@royfielding
Copy link
Member

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 royfielding mentioned this issue Feb 10, 2020
Merged
royfielding added a commit that referenced this issue Mar 6, 2020
@royfielding
Merge pull request #319 from httpwg/fielding-i161
0b4c0e4 
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
Assignees
No one assigned
Labels
caching editorial
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mnot @mpdude @royfielding