Re: [ServiceWorker] Define some way for foreign fetch to decide on opaqueness of responses (#841)

Hmm, good point about needing a new filtered response type. If fully opaque/fully visible was all we cared about opaque filtered vs not filtered is all that we would need. But with selectively exposed headers thrown in the mix some new response type is probably needed. It might also be an option to extend the definition of a CORS filtered response to take these annotations into account, but that might be weird.

And if we do add a new filtered response type, should that also include a new `ResponseType` value, which will be visible in the `Response` object? Or should this from the point of view of whoever initiated the fetch still be a "cors" response? I don't really mind exposing the fact that a foreign fetch handler was involved, but I think it still would be nice if these foreign fetch exposed responses would still just be regular "cors" responses from the point of view of the fetcher.


> Not convinced makeVisibleTo should take a promise either. It could be synchronous right?

I think the only benefit of makeVisibleTo take a promise is that (at least in theory) browser could detect patterns like `respondWith(fetch(...))` and `respondWith(makeVisible(fetch))` and not have to keep the worker alive while the fetch is in progress. But I'm not even sure if such an optimization really makes sense.


So still trying to decide whether foreignfetch should reuse FetchEvent, or if it should have its own ForeignFetchEvent class. Benefits of using the same event class could be that it makes it easier to use the same event handler for fetch and foreign fetch events (whether that is something that should be encouraged is a separate question of course). Are there different things we'd want to expose to foreign fetch handlers as opposed to regular fetch handlers? The requests's origin has been mentioned, but that's already part of the request (even though it's not exposed to javascript at the moment). As sort of a substitute the request does expose the referrer, which seems like it would provide most of the same information (unless it's set to no-referrer).

What about having `makeVisibleTo` be a non-static member of a Response? If `makeVisibleTo` really just sets some annotations on the response (which I think makes a lot of sense) there isn't really any reason for it to consume/return a response. It can just modify the response it is called on and set its "foreign fetch exposed headers" and "foreign fetch exposed origin" (not sure about those names). Also `makeVisibleTo` should presumably throw if the response it is called on is already an opaque response. (and should these new annotations on the response be part of what is stored in a cache? And I guess we'd need to decide what should happen if `makeVisibleTo` is called on a response that already has these annotations set).

The entire codepath related to regular fetches would just ignore these extra annotations on the response, but when handling a foreign fetch event, some code (either in Handle Foreign Fetch in SW, or in HTTP Fetch where that algorithm will be called) would:
- check if any of these annotations are set. If not, return an opaque filtered response (like currently specced)
- otherwise verify that the origin the response was annotated with matches the request (sort of like CORS check done in the http fetch algorithm today)
- and then return a "foreign fetch filtered response" (or maybe a different name?) which "is a filtered response whose type is "cors", header list excludes any headers in internal response's header list whose name is not a foreign-fetch-safelisted response-header name, given internal response's foreign fetch exposed headers." 



---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/841#issuecomment-189469948