Should foreign fetch work same-origin?

[jakearchibald]

If I register a SW with scope /, let it install, and activate, but do not refresh so my page remains uncontrolled, will a subresource request for /foo go through the foreign fetch handler of the new worker?

What if I shift-reload the page to avoid this page being controlled?

[mkruisselbrink]

That's an interesting question. Fetches from that SW should definitely not go through its own foreign fetch handler, so at some point we'd need to somewhat special case same origin foreign fetch. I'm not sure about request from same origin uncontrolled pages (or even same origin but distinct service workers). I think there is pretty much three options:

1. same origin requests from (uncontrolled) clients do go through the foreign fetch handler, and requests from distinct same origin service workers do as well
2. same origin requests from (uncontrolled) clients do go through the foreign fetch handler, but request from any same origin service worker do not
3. no same origin requests will ever go through the foreign fetch handler

I think of these options maybe 3. would be the least confusing?

[jakearchibald]

I guess it comes down to how distinctly we'd want to consider distinct apps that exist on the same origin. Eg github pages, and well, Google.com

[annevk]

Ah, more joyous fallout from scope. I think we should only consider it for cross-origin. If you want multiple apps on an origin and enable foreign fetch, use some future technology such as suborigins.

[delapuente]

I see the point on going against this feature as if we accept it, it would be like going against the need of having two different events (as you could reimplement fetch on the top of same-origin foreign fetch). Maybe we should rethink if foreign fetch can not be simply a special case of fetch. I'm not talking at implementation level but at user level.

[mkruisselbrink]

I actually started out with using the same event for foreign fetch and fetch. But I think the need to deal with CORS like behavior (expose responses to explicit origins etc) is a good enough reason to have separate events, as it makes the API easier to use. And even with two separate events it's not that hard to share 99% of the code for both event handlers, and at least you have to be somewhat conscious about the fact that you're possibly exposing data cross origin.

[delapuente]

Then perhaps make sense to force foreign fetch to not handle same origin requests.

[mkruisselbrink]

Closing this issue as not handling same origin requests with foreign fetch is already what is specified (step 9 in Handle Foreign Fetch).