Re: [whatwg/fetch] Define parsing for X-Content-Type-Options in detail (#818)

> @MattMenke2 so I updated the tests and ran them again and Chrome and Safari both treat `nosniff` immediately followed by 0x0B or 0x0C as a "valid value". Firefox does so for 0x0C only. I think that's why I went with treating 0x0C as valid and 0x0B as invalid. I'm happy for them to both be restricted, but are you equally sure about wanting this after knowing these results?

Running just Chrome's MIME sniffer through a test case (With a real HTTP server), "X-Content-Type-Options: nosniff\x0C" doesn't result in MIME sniffing, and there is no code anywhere in Chrome's network stack that could account for that.

However, it looks to me like Blink's code, however, uses "nosniff" in a couple places, and that code *does* use a more permission definition of space:

inline bool IsASCIISpace(CharType c) {
  return c <= ' ' && (c == ' ' || (c <= 0xD && c >= 0x9));
}

So it looks to me like what's happening is the network stack sniffs the type, and gives "text/plan" to the renderer.  Blink then applies its own header parsing logic, sees the header as being a no-sniff header, and decides that "text/plain" just isn't going to cut it in a script tag, with what it views as a valid nosniff header.

For more well-behaved tags that don't have their own nosniff logic in Blink, like images (I assume), the network stack's interpretation will be respected, but in at least the particular case of Javascript, no so much...  So that gets us back where we started.

-- 
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/818#issuecomment-434350841