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

Clarify behavior with subresource requests and subframe navigations #34

Open
letitz opened this issue Feb 15, 2021 · 0 comments
Open

Clarify behavior with subresource requests and subframe navigations #34

letitz opened this issue Feb 15, 2021 · 0 comments

Comments

@letitz
Copy link

letitz commented Feb 15, 2021

Subresource requests and subframe navigations are simpler as they cannot introduce a new first-party context. If the request matches the first-party URL's owner's manifest but is not currently recorded as being in that first-party set, the browser validates membership as above before making the request. Any Sec-First-Party-Set headers are ignored and, in particular, the browser should never read or write state for a first-party set other than the current one. This simpler process also avoids questions of retrying requests. The minVersion parameter in the header ensures that the browser's view of the owner's manifest is up-to-date enough for this logic.

I don't follow this paragraph.

  1. I feel like a word is missing from the second sentence. What does it mean for a request to match a manifest? The "not currently recorded as being in that first-party set" makes me think the object is a registrable domain? Was the intention to say "the registrable domain of the fetched resource", or somesuch?

  2. What does it mean for the browser to validate membership before making the request?

Maybe a couple of example request flows would help clarify the expected behavior here.

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