Re: [whatwg/fetch] "3.3.1. ..." Allow on empty content-type (#636)

I mean that you can't really compare 2 values when one doesn't exist; see my original post on this issue above. How can you have a **mis-match** (which is what I read the intention of this header to be about) when you can't match 2 items because one isn't there?

It's neither a match nor a mis-match if the MIME type of the content is unknown.

If no content-type is specified, the way you can determine what the content is is either through assuming by file name/extension, or through sniffing. Even if sniffing isn't allowed, a client can still assume the content type based on the file name - in your interpretation, even that should be blocked while, strictly speaking, no sniffing is involved.

In addition: The way this is intended by you (strict check, even including an empty string as a match value), as a consequence, enforces **always** having a content-type specified; that's also not in the spec but a very real effect of interpreting the XCTO header that way.

As you can see there's a few things that aren't clear at all. Adding a statement that a MIME type must always be specified if the XCTO:nosniff header is sent in the response (and blocking otherwise) would make it unambiguous what the intended matching/blocking behavior is.

-- 
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#issuecomment-346533307