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.