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

Request Cache-Control directives #129

Closed
mnot opened this issue Aug 2, 2018 · 5 comments
Closed

Request Cache-Control directives #129

mnot opened this issue Aug 2, 2018 · 5 comments

Comments

@mnot
Copy link
Member

@mnot mnot commented Aug 2, 2018

currently fall under the MUST in 7234 5.2. However, they aren't honoured by most browsers, most CDNs, most reverse proxies, and unevenly honoured by forward proxies.

@mnot
Copy link
Member Author

@mnot mnot commented Oct 9, 2018

There's also a requirement in Constructing Responses from Caches, although only regarding no-cache and no-store, not the rest.

There are a few things to unpack here:

I think we can craft requirements that only apply to forward proxies but not reverse ones. Question is what do browsers want to do here? /cc @annevk

@mnot mnot added the discuss label Oct 9, 2018
@mnot
Copy link
Member Author

@mnot mnot commented Oct 9, 2018

... and if we do this, we should probably change the language in the request CC directives section from "willing" to "prefers."

@annevk
Copy link
Contributor

@annevk annevk commented Oct 9, 2018

What browsers want with Cache-Control is probably better answered by @mayhemer @ddragana @MattMenke2 @youennf et al.

@royfielding
Copy link
Member

@royfielding royfielding commented Nov 5, 2018

I am pretty sure the original intent of these requirements were for caches not controlled by the origin (e.g., CDNs and reverse proxies were not considered caches when those requirements were made). I am sure the intent was to ensure semantic transparency, which is also subject to origin control.

My opinion has always been that they should be an optional preference, not hard requirements, since a single user's desire for semantic transparency does not automatically override a site's need for availability under load. I was out-hummed on that a long time ago (1996-ish).

Apache httpd implements them as specified. I would prefer it be a config option that might be dynamically adjusted based on whether it is operating as a shared cache, a reverse proxy, or under load.

@mcmanus
Copy link

@mcmanus mcmanus commented Nov 6, 2018

in bkk: make this advisory - don't make it universally by default

@mnot mnot removed the discuss label Nov 12, 2018
@mnot mnot self-assigned this Nov 12, 2018
@mnot mnot mentioned this issue Nov 12, 2018
@mnot mnot closed this in f4ce9c9 Dec 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants