Hi Charles, On Sun Jan 26, 2025 at 2:40 AM CET, Charles Plessy wrote:
My understanding of the media type declarations is that all ecmascript files should be served as text/javascript, which is why I added the `es` extension to that type.
Yeah, all ECMAScript files should be served with `text/javascript`, but IANA registration also says that `text/javascript` files should only have the `.js` and `.mjs` file extensions.
The RFC also says that:- all the `application/*javascript*` and `text/*javascript*` are deprecated aliases for `text/javascript`. - all the `application/*ecmascript*` and `text/*ecmascript*` are deprecated aliases for `text/ecmascript`, which is itself obsolete.
In other words: `text/ecmascript` is obsolete, but it is *not* and alias for `text/javascript`.
Hence, the `.es` file extension is only for `text/ecmascript` files.
In addition, I am aware that some tools are going to pick the first occurence of a file extension in the list and associate it the media type it came with. Therefore if I would add `text/ecmascriopt es mjs`, some software would serve files with the `mjs` extension as ecmascript instead of javascript. This is another reason why there are no ecmascript types in /etc/mime.types.
This makes sense, and is a valid concern. Hadn't considered it!
Would it be fine for both you that I change text/javascript to place the `es` extension last in the list?
What about adding `text/ecmascript es`, with no `mjs` file extension? This would more closely align with the IANA declarations, and would not risk of introducing the issues you've mentioned. And, at the same time, would properly fix this issue (i.e. `text/javascript` would not risk being mapped to `es` based on the order of the suffixes).
Bye!
signature.asc
Description: PGP signature
