[whatwg/fetch] "3.3.1. Should response to request be blocked du..." (#636)

https://fetch.spec.whatwg.org/commit-snapshots/860ab8669fb3775b77b6f81e44e5a2609db0bc93/#should-response-to-request-be-blocked-due-to-nosniff?

> 3\.3\.1\. Should response to request be blocked due to nosniff?
> Run these steps:​
>     1. If response’s header list does not contain \`X\-Content\-Type\-Options\`, then return allowed\.
>     2. 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\.
>     3. If nosniff is failure, then return allowed\.
>     4. Let mimeType be the result of extracting a MIME type from response’s header list\.
>     5. Let destination be request’s destination\.
>     6. If destination is script\-like and mimeType \(ignoring parameters\) is not a JavaScript MIME type, then return blocked\.
>     7. If destination is "style" and mimeType \(ignoring parameters\) is not \`text/css\`, then return blocked\.
>     8. Return allowed\. 

Many websites will use a blanket "nosniff" option because it's being pushed as a recommended security measure. However, many sites also do not supply a content-type header with every document returned. As a result, any script or style that would not have a supplied content-type in the header would, according to this spec, be blocked. Blocking should only occur on a **mis-match** of MIME type in the intention of this spec as I understood, and not when the MIME type is missing altogether. Since you can't compare between two values when one of them is missing, it should be allowed.

I suggest adding an additional step between 4 and 6:
`If mimeType is empty, then return allowed.`

-- 
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/issues/636