Should we still sniff if Content-Type is text/html?

[cdumez]

I recently investigated a web-platform-test failure (html/semantics/embedded-content/the-iframe-element/iframe_sandbox_anchor_download_block_downloads.tentative.html) in WebKit/CFNetwork and found out that it was caused by sniffing when the Content-Type is text/html:

• Add X-Content-Type-Options: nosniff header to download_stash.py web-platform-tests/wpt#41037

This test is passing in Chrome and Firefox so I am wondering. Does the specification (https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource) really match Chrome and Firefox here?

Should CFNetwork stop sniffing when the Content-Type is text/html?

[cdumez]

cc @annevk

[annevk]

As far as I can tell from https://chromium.googlesource.com/chromium/src/net/+/refs/heads/main/base/mime_sniffer.cc Chromium does not appear to sniff text/html responses. They only invoke SniffXML (which is what they have for "feeds") for text/xml and application/xml. (Which seems to contradict step 4 of https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource which does not allow sniffing of XML MIME types.)

@MattMenke2 I see you touched that Chromium code quite a bit, any thoughts?

@valenting @mozfreddyb do either of you know what Gecko does for text/html responses? Do they get sniffed for feeds as the MIME Sniffing standard suggests in step 5 of https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource or are they not sniffed at all? (I got a bit lost trying to find the relevant callers of the functions in https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp.)

[MattMenke2]

I don't claim to be an expert on what MIME sniffing should actually do, but yes, my reading is also that Chrome does not sniff responses with a text/html content-type.

I also agree that Chrome's sniffing of files with those XML MIME types looks to violate spec, and would certainly love to see more standardization here (especially in the direction of less sniffing). Note that I'm no longer on Chrome's networking team. I'm still on Chrome, and still happy to talk about these things, just not a good decision person or driver of changes around, e.g., not sniffing files with XML types.

[josepharhar]

ccing some people who might be able to help with this
@ricea @horo-t @mikewest

[valenting]

@valenting @mozfreddyb do either of you know what Gecko does for text/html responses? Do they get sniffed for feeds as the MIME Sniffing standard suggests in step 5 of https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource or are they not sniffed at all? (I got a bit lost trying to find the relevant callers of the functions in https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp.)

As far as I can tell we we don't create an nsUnknownDecoder if it's already present on the response.
@farre and @sefeng211 have been working with this code recently so they might know more.

[farre]

There's also a sniff happening here, if LOAD_CALL_CONTENT_SNIFFERS is set, which it is in nsDocShellLoadState::CalculateChannelLoadFlags, but I'm not sure if we're hitting that path, I'd have to check. And I also don't know which sniffers would get called there in that case. It might just be media sniffers.

[mikewest]

cc @otherdaniel, who's looking into sniffing (or not) insofar as it impacts ORB.