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

> semantics are subtly different from CORS so re-using CORS headers isn't ideal?

If we reuse CORS headers, then passing the response back without thinking could reveal more info than intended.

> `Response.makeVisibleTo(…)`

Feels weird to put a method on `Response` that only really applies to foreign fetch. I prefer `foreignFetchEvent.makeVisibleTo()`.

Another possibility is to make `foreignFetchEvent.respondWith` receive (a promise for) an object, so the usage would be:

```js
self.addEventListener('foreignfetch', event => {
  event.respondWith(
    fetch(url).then(response => ({
      response,
      visibility: {
        origin: '…',
        headers: […]
      }
    }))
  );
});
```

You lose the opaque default with this method though. Not sure if that's a feature or a bug.

> there is also the question if foreign fetch should keep using the same `FetchEvent` interface or have its own `ForeignFetchEvent`

I think it must, as we'd want to expose details about the receiving origin. From the explainer, `event.request.origin` is always going to match `location.origin`, which is unlikely to happen in foreign fetch.

> Another option might be to change `respondWith` to be able to be called asynchronously (as long as `waitUntil` promises haven't all resolved yet)

This gets tricky when it comes to multiple listeners. There'd either be a race to `respondWith`, or `waitUntil` would need to change so it prevents the next event listener being called. I don't think either is particularly nice.

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