Re: [whatwg/fetch] CORB: nosniff handling (#686)

If we need CORB-filtered responses and other implementers are on board with them we should add them. It seems to me those would not expose any headers, but perhaps I'm missing something?

Once we add them we'd need to do nosniff differently, indeed, but I think the more we can handle as a network error the better, so what we say is a network error in this PR ideally remains to be so over time.

(And doing this all incrementally seems like a very good approach to me, especially as a change like this can be isolated from a much more invasive change such as CORB-filtered responses or sniffing.)

> if an implementation convinces itself that a JSON security prefix never appears in images or media then it can block without any observable impact

I don't agree with that line of thinking. Applications might come to rely on this happening and then other browsers have a vulnerability.

<hr>

I didn't realize that the `track` element had that section. I only read

> If the type of the resource is not a supported text track format, the load will fail, as described below.

and not the big box below. I guess we'd have to look at implementations. Filing a bug against WPT or HTML seems like the way to go. 😟

<hr>

As for test coverage, the more the better. If you cannot obtain something through script, http://web-platform-tests.org/writing-tests/reftests.html would be the way to go. That should still be relatively fast.

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