Add a MIME type API

[annevk]

If you write a library and consume some kind of server-side code you might want to verify MIME types in the same way as browsers do. E.g., not reject MIME types that end with ;.

const mime = new MIMEType("text/javascript;charset=utf-8");
mime.type; // "text"
mime.subtype; // "javascript"
mime.essence; // "text/javascript"
mime.param("charset"); // "utf-8"

It also seems to make sense somewhat to make the object iterable from an IDL perspective so you can get all the parameters that way easily.

[domenic]

It's worth surveying the existing JS library APIs such as:

• https://github.com/jsdom/content-type-parser
• https://github.com/jshttp/content-type
• Lots more: 1, 2

although I am sure we'll have our own concerns that will mean none of them are immediately translateable.

[annevk]

They all basically look the same. Main difference seems to be whether to group type and subtype (I suggest we offer both) and whether it's mutable (I'd suggest it's not).

@dougwilson seems responsible for some packages so might have thoughts. (For context, this is about a MIME type parser exposed to JavaScript in the browser.) @jasnell might as well given that this is something Node.js might want to pick up.

[annevk]

Is overrideMimeType() sufficient precedent to name it MimeType rather than MIMEType?

[domenic]

No, we should follow the usual acronym rules for new features.

[annevk]

The other thing we need to consider is what to return for x/x;charset="\"". I suspect we want get() that returns unquoted value (") and rawGet() or some such that returns the value as stored ("\""). (See #40 for more details.)

[domenic]

A big choice is whether this API is mutable (like URL) or immutable (as the OP outlines). For purposes like changing the charset, or adding params in general, mutable is necessary.

[annevk]

Yeah, maybe we should just stick to that and if you want immutable you use a string. Should have a section similar to the one URL has on usage elsewhere.

[jasnell]

mutable works for me.

Another question would be: will this provide any built in mechanism for wild cards and matching or is this purely a parsing function and everything else is left to user land to figure out?

For instance, would there be any provision for the following kinds of action:

const m = new MIMEType('text/javascript');
const n  = new MIMEType('text/*');
n.match(m);  // true
m.match(n);  // true

Would generally prefer that it not get in to that level.

[annevk]

The initial API would just be parsing, exposing the resulting (mutable) structure, and serializing. #48 has some ideas for constant-like operations (e.g., is this an XML MIME type), but I don't think we want to invent generic matching schemes (at least for now).

[domenic]

I've prototyped my take on this API in https://www.npmjs.com/package/whatwg-mimetype, FWIW. Including some experimental type testers.

[devsnek]

in reference to that node pr, could work be done at this point to normalise a spec which hopefully also includes sniffing? i'd be happy to help however i can.

[annevk]

@devsnek sorry for not responding sooner. Yes, this can be formalized at this point. An API for sniffing should very much be a separate effort I think. That might also be worthwhile, but let's not include that here as it would have a very different API.

[jimmywarting]

Would be nice if browsers mime sniffing algoritm would somehow be exposed too.
One usecase comes from unzipping a bunch of files but knows nothing about their types so creating a right mime type for use with createObjectURL is tuff without npm's mime

A api for looking up mimetype with extension & magic number would be nice too.

var mime = MIME.fromType("text/javascript;charset=utf-8")
var mime = MIME.fromExtension("txt")
var mime = await MIME.fromBlobOrFile(blob) // magic number lookup

Another solution would be if File, Blob constructor had an option for auto detecting the type according to mime sniffing standard. createObjectURL could have an auto detecting too, but i would like an api that works in service worker too.

[annevk]

(I realized today that the HTML standard exposes MimeType as an interface. I don't think we should reuse that here though and given the different capitalization it doesn't matter much, but wanted to note it.)