Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope and structure of mimesniff #152

Open
GPHemsley opened this issue Sep 3, 2021 · 3 comments
Open

Scope and structure of mimesniff #152

GPHemsley opened this issue Sep 3, 2021 · 3 comments

Comments

@GPHemsley
Copy link
Member

@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
Copy link
Member Author

GPHemsley commented Sep 4, 2021

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
Copy link
Member Author

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 GPHemsley pinned this issue Sep 4, 2021
@GPHemsley
Copy link
Member Author

GPHemsley commented Sep 9, 2021

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

@annevk annevk unpinned this issue Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant