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

Comments

Projects
None yet
4 participants
@mnot
Copy link
Member

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 mnot added the caching label Aug 2, 2018

@mnot

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

annevk commented Oct 9, 2018

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

@royfielding

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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 referenced this issue Nov 12, 2018

Closed

Pragma #140

@mnot mnot added the has-proposal label Nov 13, 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