Scope and structure of mimesniff

[GPHemsley]

@annevk from #70:

There's two places where we have a need for sniffing in the web platform as I understand it:

1. Navigation. Here the point is to determine whether it's HTML, plain text, media, PDF, or a download. For media there is of course some decision about what decoder to use at some point, but the most important decision here is whether it will be send to the decoder at all.

2. Individual endpoints. Here it's mostly about documenting what decoders accept and should reject. We don't really care whether an implementation uses a single decoder for all of media or has separate pipelines for various media formats. That's indeed the realm of other specifications that define what a byte stream results in. (And note that often there is a step before invoking this in the individual endpoints where the MIME type is checked first. E.g., image/svg+xml is handled in a special manner in the image endpoint pipeline.)

And there will be a third: https://github.com/annevk/orb.

The original purpose of mimesniff was the first point, but many authors have been using it for the second point.

We should discuss whether the second point is within the scope of mimesniff and, if so, how to structure the spec to avoid conflating the two (or three).

[GPHemsley]

Likely of relevance (last updated 2015):
https://wiki.whatwg.org/wiki/Contexts

Which has possibly been replaced by:
https://fetch.spec.whatwg.org/#concept-request-destination

[GPHemsley]

From 4.2. MIME type miscellaneous:

A MIME type is supported by the user agent if the user agent has the capability to interpret a resource of that MIME type and present it to the user.

This needs more work. See w3c/preload#113.

[GPHemsley]

As mentioned above, the original intent of mimesniff was for safely dealing with Web resources missing a Content-Type header or having been tagged with an incorrect MIME type; in other words, the legacy Web. (It originated from a paper published in 2009.)

However, after I took over as editor (circa 2012), I added the Context-specific sniffing section (6220ba2) in anticipation of its use by editors of specs like HTML or CSS for tying in their new features (like <audio> and <video> or @font-face). Around the same time, I also started that Contexts wiki page I linked above (which just so happened to parallel the efforts going into CORS and CSP around the same time), in an attempt to enumerate the potential use cases of sniffing on the Web.

Soon after that, I stepped back from editing to do life stuff, having done little communication/outreach with other spec authors and leaving behind little documentation of my reasoning.

Somewhere along the way, #4 happened, without any of the above being known, and with no one having stepped in to formally take my place as spec editor. Sometime after that, #70 was filed pointing out some issues.

Fast forward to today. A lot of the things that were in their infancy when I was originally editing have since come into their own. There are slightly more urgent needs for what I have termed context-specific sniffing, before Bad Things™ become permanent.

In order to help jump-start this discussion, and others, I've been working this week on actually getting a basic test suite into wpt (web-platform-tests/wpt#30403). (It turns out there is a lot of disagreement between browser vendors and the spec, which is not great.) While I can't guarantee that I'll be able to put a ton of dedicated time into the spec in the future, I'm hoping this will at least provide the activation energy for others to passively maintain things.

I'm also hoping that this issue here can serve as a place to hash out the needs of the various stakeholders in mimesniff without inadvertently working at cross-purposes and hopefully to help build a stronger document.

/cc @annevk @domenic @padenot @dd8