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

Should allowed have special values besides null #67

Closed
annevk opened this issue Jan 10, 2020 · 10 comments · Fixed by #72
Closed

Should allowed have special values besides null #67

annevk opened this issue Jan 10, 2020 · 10 comments · Fixed by #72
Assignees

Comments

@annevk
Copy link

annevk commented Jan 10, 2020

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.

@domenic
Copy link
Collaborator

domenic commented Jan 10, 2020

This is equivalent to omitting the header entirely, right?

@annevk
Copy link
Author

annevk commented Jan 11, 2020

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?

@domenic
Copy link
Collaborator

domenic commented Jan 13, 2020

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

In this case any web platform feature that is governed by origin policy will consult the response's URL's origin's origin policy.

@annevk
Copy link
Author

annevk commented Jan 13, 2020

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?

@domenic
Copy link
Collaborator

domenic commented Jan 13, 2020

Ah, I see, yes, that use case is not met. OK, adding!

@domenic
Copy link
Collaborator

domenic commented Jan 13, 2020

Hmm, so what are the specific semantics we want? I can think of a few:

  • "Latest from the cache": performs a cache-enabled fetch to the origin policy URL. If you've never visited the origin before this will indeed fetch the policy. If you have and got a 404, this will return the 404, giving the null policy.

  • "Always refetch from network": performs a cache-disabled fetch to the origin policy URL.

  • "Cache then network": perform a cache-enabled fetch. If this 404s from the cache, then go to the network.

@annevk
Copy link
Author

annevk commented Jan 14, 2020

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?

@domenic
Copy link
Collaborator

domenic commented Jan 14, 2020

I'm a bit confused. You can just use max-age or etags or similar; it's the HTTP cache.

@annevk
Copy link
Author

annevk commented Jan 14, 2020

In that case I would expect a normal request with the request defaults?

@domenic
Copy link
Collaborator

domenic commented Jan 14, 2020

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.)

@domenic domenic self-assigned this Jan 31, 2020
domenic added a commit that referenced this issue Feb 12, 2020
#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.
domenic added a commit that referenced this issue Feb 12, 2020
#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.
domenic added a commit that referenced this issue Feb 19, 2020
#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.
domenic added a commit that referenced this issue Feb 19, 2020
#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.
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

Successfully merging a pull request may close this issue.

2 participants