Re: [whatwg/fetch] CORB: blocking of nosniff and 206 responses (#686)

> What I meant to say is that if fetching returns a filtered response, the response will have come from a service worker (and will therefore already have gone through a CORB check). We could perform one again but that seems pointless? And if we did one again presumably we should do it on the internal response, not the wrapper, but I really don't see why.

You're right - ignoring service worker responses is actually required for [_some_ scenarios](https://chromium.googlesource.com/chromium/src/+/86b1e8b59c08effaa1e120c6c0cc15b8df2d9ffd/services/network/cross_origin_read_blocking.cc#621) and I agree that ignoring responses from service workers in _all_ scenarios is still okay (e.g. CORB only cares about blocking the responses from the _network_).

> If the response comes from the network or HTTP cache it won't be a filtered response at this point.

Thanks for highlighting/confirming that.  This makes me much more comfortable that skipping filtered responses is okay.

> (I guess it's okay that these responses can still enter the HTTP cache.)

It's not only okay, but it is required to retain some of performance benefits of [link prefetching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ) (although I am not sure how often in practice one encounters a scenario where 1) a HTML/JSON/XML resource from bar.com is first prefetched in a foo.com's frame and 2) later bar.com frame accesses the same resource in a performance-sensitive path).  Note that so far [we've failed to create a WPT test](https://bugs.chromium.org/p/chromium/issues/detail?id=809261#c9) that verifies this scenario.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/686#issuecomment-387432176