Operate on internal response

[annevk]

When getting a response back from the service worker, need to operate on internal response.

[annevk]

The problem is that initially Fetch was a closed system and we'd only add a restriction on response on the way out. Service workers however allow injecting a response half-way in with a restriction in place.

So we should probably fix this by making everything aware of a response potentially being a filtered response. On the way out we then need to decide whether to switch filters or not.

[annevk]

In HTTP Fetch step 2.2 we check request's mode, we could also check request's response tainting. The difference would be that a opaque response to a same-origin (but no-cors) request would not be allowed whereas that is allowed today. Status quo is probably okay.

[annevk]

So for HTTP Fetch we need to acknowledge there's a response and potentially an internal response. If there's an internal response we want to check the internal response's status, headers, etc. in that algorithm.

For fetch step 11 I think we should basically skip responses that already have an internal response (i.e. that are filtered responses). Combined with HTTP Fetch step 2.2 that works fine I think.

@nikhilm @jakearchibald @wanderview am I missing anything?

[nikhilm]

Are you saying step 11 can be skipped because the response returned from the SW will already be filtered due to SW being able to obtain a filtered response only from fetch() or cache.match(), both of which will 'do the right thing'? That sounds correct.

[annevk]

Yeah, that was my reasoning. Combined with the fact that we already disallow certain responses from the service worker (e.g. opaque response is not allowed if the request wasn't no-cors).

[annevk]

So I don't really see how a service worker can end up with a response that's opaque which HTTP fetch would need to worry about. The only opaque responses it can get are at the end of a redirect or authentication chain, no?

[annevk]

Closing this since I think I'm correct and I fixed the other issue.

[annevk]

I should have worried about authentication at least. That works in a no-cors scenario. And soon redirects will be a tad more exposed too. I apparently also missed various cases in what is now "main fetch" but they should all be fixed now.