- From: Moonchild <notifications@github.com>
- Date: Thu, 23 Nov 2017 05:11:44 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/636/346533307@github.com>
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
Received on Thursday, 23 November 2017 05:12:21 UTC