Unclear when CORB requires nosniff

[jakearchibald]

https://fetch.spec.whatwg.org/#corb-check.

4. If response’s status is 206 and mimeType (ignoring parameters) is a CORB-protected MIME type, then return blocked.

Step 4 checks the mime type for 206 responses whether nosniff is set or not.

5. Let nosniff be the result of extracting header values from the first header whose name is a byte-case-insensitive match for X-Content-Type-Options in response’s header list.
6. If nosniff is not failure and mimeType (ignoring parameters) is a CORB-protected MIME type or text/plain, then return blocked.

Note: CORB only protects text/plain responses with a X-Content-Type-Options: nosniff header. Unfortunately, protecting such responses without that header when their status is 206 would break too many existing video responses that have a text/plain MIME type.

The note suggests that only text/plain responses require the nosniff header to allow CORB, but from step 6 it seems like all types require nosniff in order to be protected, unless the response is 206.

It seems weird that 206 responses don't require nosniff. A note explaining why would be useful.

Maybe I'm getting confused because step 5 isn't clear on what should happen if the response does not have a X-Content-Type-Options header.

[annevk]

It means to suggest that text/plain isn't covered for 206.

Requiring less for 206 is done because we could. Ideally nosniff wouldn't be required at all after all.

[annevk]

My plan is to close this when #1441 lands. Its replacement, worked on in #1442, will likely not have this note.