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

RFC2616 13.4 Response Cacheability #115

Open
bino98 opened this issue Oct 2, 2019 · 0 comments
Open

RFC2616 13.4 Response Cacheability #115

bino98 opened this issue Oct 2, 2019 · 0 comments

Comments

@bino98
Copy link
Contributor

bino98 commented Oct 2, 2019

ref. https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4

Hello.
I was reading RFC2616 chap 13.4,
I noticed that there might be a gap from the implementation.

That part is...

A response received with any other status code (e.g. status codes 302 and 307) MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a "max-age", "s-maxage", "must- revalidate", "proxy-revalidate", "public" or "private" cache-control directive (section 14.9).

I think only this can be supported with the current implementation.
In my RFC interpretation, you can have cache in addition to this.

Am i wrong?

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

No branches or pull requests

1 participant