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

Consider supporting Fetch Metadata. #885

Open
mikewest opened this issue Mar 24, 2019 · 3 comments

Comments

2 participants
@mikewest
Copy link
Member

commented Mar 24, 2019

https://mikewest.github.io/sec-metadata/ is starting to look pretty reasonable. I plan to put up some PRs to sketch out what the integration would look like, based on the thoughts in https://mikewest.github.io/sec-metadata/#fetch-integration. I think we'd need ~3 changes, but who knows? :)

  1. Add a boolean user activation flag to request objects, defaulting to false. We'd set it in HTML's navigation algorithm, based on whether the navigation was triggered by user activation.

  2. Call set the Fetch Metadata headers for a request. Probably from "main fetch"?

  3. Define "nested-navigate", as per #755.

WDYT?

@annevk

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

What's the expected interaction with service workers? Should service workers see these values exposed in two different places?

Also, if you decide to expose the headers to service workers, you can get in a situation where it appears as if the headers values are preserved, but then when the fetch is made from the service worker, the values get overridden by the fetch algorithm.

@mikewest

This comment has been minimized.

Copy link
Member Author

commented Mar 25, 2019

I'm imagining that these headers would be set in main fetch, before we hit the service worker. I could also easily live with the headers being set in HTTP-network-or-cache fetch, after we run through the service worker.

Either way, I'm a bit confused about the expectations for fetches from Service Workers, as my mental model matches what you suggest above ("the values get overridden by the fetch algorithm"), but I've also heard suggestions that "event.respondWith(fetch(event.request)) is the same as if service worker was not there", which would mean that things like destination, et al. carry over. That's not how it works in Chrome today for things like CSP (nor, I believe, does it work that way in Firefox), so it would be helpful to get some clarity.

@jakearchibald and @arturjanc have been discussing this in more detail over the last few days, and might have thoughts to share.

@annevk

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

It's not the same and cannot be. We aim for it mostly being the same (and that it never throws) so developers can use that kind of pattern safely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.