-
Notifications
You must be signed in to change notification settings - Fork 16
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
Should allowed have special values besides null #67
Comments
This is equivalent to omitting the header entirely, right? |
So https://wicg.github.io/origin-policy/#update-the-origin-policy-from-a-response returns "success" in step 4. The caller seems to do nothing with the return value. How does that ensure the latest policy? |
The current cached policy is applied whenever setting up something that would benefit from policies. So e.g. https://wicg.github.io/origin-policy/#monkeypatch-fp and https://wicg.github.io/origin-policy/#monkeypatch-csp so far. Maybe we should add a note to the "return success" step, something like
|
So I navigate to A for the first time and A does not specify a header, what makes it download A's origin policy and apply it? |
Ah, I see, yes, that use case is not met. OK, adding! |
Hmm, so what are the specific semantics we want? I can think of a few:
|
Is there an equivalent of max-age for cached items? Bypassing the cache altogether seems bad, but the cache does need to support some invalidation probably? |
I'm a bit confused. You can just use max-age or etags or similar; it's the HTTP cache. |
In that case I would expect a normal request with the request defaults? |
So "latest from the cache" in my above list. (Although I recognize now that that was a somewhat misleading name; perhaps "latest, possibly from cache" would make more sense.) |
#67 points out that it can be useful to have values that require less maintenance from the site author. This adds the latest token for the allowed=() list, and the latest-from-network token for the preferred= entry, to allow such use cases. In the process, this expands the README's illustration of the Origin-Policy header to contain more concrete examples, and removes the spec-sketch from version-negotiation.md in favor of a more broad outline. This also clarifies that you do not need to duplicate the preferred value inside allowed. Closes #67. Closes #61.
#67 points out that it can be useful to have values that require less maintenance from the site author. This adds the latest token for the allowed=() list, and the latest-from-network token for the preferred= entry, to allow such use cases. In the process, this expands the README's illustration of the Origin-Policy header to contain more concrete examples, and removes the spec-sketch from version-negotiation.md in favor of a more broad outline. This also clarifies that you do not need to duplicate the preferred value inside allowed. Closes #67. Closes #61.
#67 points out that it can be useful to have values that require less maintenance from the site author. This adds the latest token for the allowed=() list, and the latest-from-network token for the preferred= entry, to allow such use cases. In the process, this expands the README's illustration of the Origin-Policy header to contain more concrete examples, and removes the spec-sketch from version-negotiation.md in favor of a more broad outline. This also clarifies that you do not need to duplicate the preferred value inside allowed. Closes #67. Closes #61.
#67 points out that it can be useful to have values that require less maintenance from the site author. This adds the latest token for the allowed=() list, and the latest-from-network token for the preferred= entry, to allow such use cases. In the process, this expands the README's illustration of the Origin-Policy header to contain more concrete examples, and removes the spec-sketch from version-negotiation.md in favor of a more broad outline. This also clarifies that you do not need to duplicate the preferred value inside allowed. Closes #67. Closes #61.
Regarding #66 I think it would be useful if allowed had special values besides null, in particular for resources you don't plan on updating and would not want to invalidate (if ever), but would like to use the latest policy for.
The text was updated successfully, but these errors were encountered: