Correct JavaScript MIME types + extensions per RFC 9239

[mathiasbynens]

This patch updates the MIME type configuration per RFC 9239.
https://www.rfc-editor.org/rfc/rfc9239

First, the recommended MIME type is now text/javascript:

The most widely supported media type in use is text/javascript; all
others are considered historical and obsolete aliases of text/javascript.

Second, the .mjs extension is now explicitly registered:

The .mjs file extension signals that the file represents a JavaScript
module. Execution environments that rely on file extensions to
determine how to process inputs parse .mjs files using the Module
grammar of [ECMA-262].

IANA template: https://www.iana.org/assignments/media-types/text/javascript

Bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61383

[mathiasbynens]

Related PRs:

• nginx/nginx PR
• jshttp/mime-db PR
• python/cpython PR

[icing]

Thanks for you PR. I see no problem with adding .mjs to the list. However, redefining .js to another mime type has potential to break existing deployments (not of Apache itself, but for software that was coded to expect a certain Content-Type).

We can take in that change into our trunk, but I would hesitate to add the redefinition to a 2.4.x release.

What are your expectations?

[mathiasbynens]

Browsers continue to support all JavaScript MIME types equally: https://mimesniff.spec.whatwg.org/#javascript-mime-type It's just that text/javascript is the recommended default. This has been the case for many years in the HTML Standard:

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. [RFC9239]

The new RFC finally makes this reality official at the IETF level as well.

So it's exactly like you said: the switch from application/javascript to text/javascript has no observable behaviors, other than the MIME type itself. This would only break e.g. unit tests that are hardcoded to expect the outdated type -- that is breakage that's unavoidable at one point anyway, unless you decide not to implement RFC 9239.

I don't have any strong opinions on which version this patch should make it into. I would understand if you'd rather wait for a minor release (v2.5.0?). I trust the Apache team to make that decision. My main concern is simply the timing: waiting "too long" to land this could cause more deployments to diverge from what is now a cross-standard MIME type agreement.

[icing]

The new RFC finally makes this reality official at the IETF level as well.

It's good to define that clearly going forward, I agree.

So it's exactly like you said: the switch from application/javascript to text/javascript has no observable behaviors, other than the MIME type itself. This would only break e.g. unit tests that are hardcoded to expect the outdated type -- that is breakage that's unavoidable at one point anyway, unless you decide not to implement RFC 9239.

I envy your optimism. In my experience, I would expect several enterprise proxies to break on such a mime type change.

I don't have any strong opinions on which version this patch should make it into. I would understand if you'd rather wait for a minor release (v2.5.0?). I trust the Apache team to make that decision. My main concern is simply the timing: waiting "too long" to land this could cause more deployments to diverge from what is now a cross-standard MIME type agreement.

Ok, added to trunk in r1901273.

[mathiasbynens]

Ok, added to trunk in r1901273.

Thank you! f4230a5

Should we close this PR now?

[icing]

Indeed. Thanks for making the PR!

[reschke]

Browsers continue to support all JavaScript MIME types equally: https://mimesniff.spec.whatwg.org/#javascript-mime-type

FWIW, not all user agents are browsers.