JavaScript type should be text/javascript

[broofa]

Apparently text/javascript is the new hotness now...? https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

I first noticed this on MDN's Common MIME Types page, which now shows text/javascript.

@mathiasbynens, @domenic: Can you provide insight into what's going on at the standards body level? When do you expect to see the IANA registry updated? What about mime.types for Apache or NGINX? (mime-db pulls from all three of these places.)

[mathiasbynens]

Thanks for the ping!

This is not really "new"; the HTML Standard has included a willful violation of RFC 4329 for a long time:

The term "JavaScript" is used to refer to ECMA-262, rather than the official term ECMAScript, since the term JavaScript is more widely known. Similarly, the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329. [RFC4329]

And:

Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types.

RFC 4329 does not match reality. The HTML Standard does (in this particular case), and https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ is in the final stages of being standardized so that RFC 4329 is officially deprecated at the IETF/IANA level.

There's a bit of a chicken-egg problem in that server software often has a policy of only considering IETF/IANA even when those standards are clearly out of touch with reality, like in this case. This leads to ridiculous situations like Python's built-in SimpleHTTPServer adding support for .mjs with the wrong application/javascript MIME type. 🤷‍♂️

I hope you consider changing changing mime-db's without waiting for https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ to be finalized.

[dougwilson]

Ultimately this module is not a MIME registry service and not in the business of handling such disputes. It is an aggregation of the sources in the readme, which is where these types of changes need to be made and this module will passively update the records to reflect changes in the source registries.

[cybersupernova]

@dougwilson I completely agree with you, but the least we can do is add "extensions": ["js"] in text/javascript key until the dispute is resolved.
It really breaks all my validations since there is no way to get the extension of text/javascript files which keeps getting uploaded from clients.
For now, I am doing regex matching to bypass this.

[dougwilson]

@cybersupernova this module is not here to resolve "disputes" -- it is here to provide a aggragate json database of the types as defined from the three sources at the top of the readme.

[cybersupernova]

@dougwilson I am not asking to resolve any dispute, but giving no extension for so common MIME text/javascript makes no sense.
I am using the database but still, I have to return extension for this MIME with extra if condition. I cannot overlook this in my app since it's a commonly used file type.

Anyways, thanks for your time.

[dougwilson]

Hi @cybersupernova I definately understand, but this module is here to provide a aggragate json database of the types as defined from the three sources at the top of the readme. This really means you are saying that the issue is that none of those three sources are providing an extension for that MIME type, is that correct? If we have an issue where it actually is in one of those sources and we are not populating in this database, that is definately an issue. If you are saying that our upstream sources do not provide that mapping, then it can always be corrected. The IANA source provides a method to add them, noted in our README: http://tools.ietf.org/html/rfc6838#section-5

[getify]

@dougwilson According to this tweet (by @bmeck), it seems like maybe the RFC has now received official approval? I may be misunderstanding the status, so apologies if so.

But if it's indeed been "approved", can this library now move forward with updating to "text/javascript"? If not, what else is necessary to update?

//cc @broofa

[mathiasbynens]

The RFC-to-be's current IESG status is "Approved-announcement to be sent". The draft has been formally approved, but there are some administrative things left to take care of before it gets officially published as an RFC.

I don't think we should wait for that to happen to take action here, though.

[Martii]

My 2 cents is not to jump the gun... drafts are drafts for a reason... it's something that can be achieved when it's actually published. While it would be nice to have it more standardized patience would be a good thing to make sure the draft doesn't expire at its expiry date without a resolution.

[getify]

First of all, this has been literally years in the making... it's not like they drafted this last week. It widely represents web reality for at least 5+ years now.

Moreover:

"The draft has been formally approved, but there are some administrative things..."

This doesn't at all sound like a draft that's in jeopardy of being abandoned. Let's not deal in generalities here, but focus on the specifics of this RFC and the reality of it.

---

This database drives libraries that many widely used static file servers use to determine and serve mime types for JS files. Every minute, 10s or 100s of thousands of these files are being served up to clients, most with "incorrect" headers.

In my case, the incorrect headers were causing problems with my PWA not being properly/fully validated by tools in the chrome ecosystem like Lighthouse. So I had to fork the static file server and add logic to override the mime-type. I've had to maintain that fork for 3+ years now. Quite frankly, that's a huge security risk even if it wasn't also a giant pain.

Point being: there are real costs to being slow to adopt/reflect the reality of this change.

If the change was still in debate/discussion, I would definitely understand the hesitation. But the period for that has now passed. I think it's time to act.

[wesleytodd]

Just wanted to update here, this just got published with 1.53.0 just today. I am going to unlock this thread in case we need any additional input with it out in the wild.