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

> Distinguishing a Response object from an ordinary object is somewhat ugly and not possible unless you branch on internal slots, which are not available to normal JavaScript. I'm not sure we should do that for the first iteration. Also, it's not the common case, so it's weird to optimize for that.

Ah, okay. That's unfortunate but makes sense. I'll change it that way.

> I think it's okay to update the "cors filtered response" to account for a different kind of safelist. I'm not entirely sure I'm comfortable storing state on filters though. There might be rewrapping happening, especially with multiple levels of nesting, and that would then somehow need to account for that state, which seems very fragile. Agreed that it's problematic with regards to what's observable. I guess we'll need to be clearer on how a response actually moves between environments. As far as I can tell that needs to be some kind of cloning (with potential user agent optimizations under the hood, of course).

Agreed that storing state on filters is rather icky. But it seems that the conclusion of #850 might be that we'll be cloning the internal response anyway (at least in spec language), so modifying the internal response to set the list of exposed headers shouldn't be a problem then.

---
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-197970909