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

I started trying to write a spec for this ([ForeignFetchEvent](https://rawgit.com/mkruisselbrink/ServiceWorker/foreign-fetch-cors/spec/service_worker/index.html#foreign-fetch-event-section) and the updated [Handle Foreign Fetch](https://rawgit.com/mkruisselbrink/ServiceWorker/foreign-fetch-cors/spec/service_worker/index.html#on-foreign-fetch-request-algorithm) algorithm). Overall I don't think it's too bad, but getting all the corner cases right and correctly dealing with all the various ways existing filtered responses should be treated is definitely tricky. Also at some parts of this should move to the fetch spec, but for now it seemed easier to just keep it all together in one place.

> You always need to pass a dictionary, even when you're not passing origin/headers.

I'm not sure I see the benefit of this? If we allow passing just a `Response` as `respondWith({response: response})`, why wouldn't we also allow `respondWith(response)`? It might not be the common case, but supporting it really doesn't complicate anything.

> Foreign-fetch filtered responses's will need some kind of header safelist stored on them (or maybe on the internal response).

Currently I've kind of hand-wavy stored this list on the filtered response, not the internal response. Storing it on the internal response seems like it could be potentially problematic (our foreign fetch handler somehow got hold of a response that already is a foreign fetch filtered response. It then tries to respond with that response and some shorter header list. If we just blindly update the header safelist on the internal response that would also change the headers visible to the javascript code in the foreign fetch handler, unless we clone the internal response first).

I do wonder if having a separate "foreign fetch filtered response" and a "cors filtered response" is really the best approach here though. It might be cleaner to somehow update the definition of "CORS filtered response" to make it usable for this, since after all both filtered response types do nothing but setting the type to "cors", and filtering the header list using some whitelist.

> I don't think we want to make filtered responses multiple layers deep since that would complicate things elsewhere. Though it might be worth trying to think through that angle too.

At first I thought that having multiple layers of filtered responses might actually make sense, since it would make sure we never accidentally expose something another filter tried to hide, but I now agree that that indeed wouldn't really simplify anything. Foreign fetch code would still need to be careful to correctly deal with all the various filtered responses the original response can be (a foreign fetch filtered opaque response should just be an opaque response, etc).

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/841#issuecomment-197582203