[PATCH] Correct JavaScript MIME types + extensions per RFC 9239

[Mathias Bynens]

On Fri, May 27, 2022 at 1:55 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Mon, May 23, 2022 at 11:32:08AM +0200, Mathias Bynens via nginx-devel
> wrote:
>
> > Thank you, Maxim. Is there anything else I can do to help move this
> > along? The change is rather small and clearly follows the latest RFC,
> > so I would expect it to be uncontroversial.
>
> On the other hand, the RFC itself is rather controversial, as it
> changes preferred MIME type for javascript for no apparent reason,


Are you suggesting that RFCs can be published "for no apparent reason"? The
publication of this RFC ends a year-long cross-standard disagreement
between WHATWG/HTML & IETF/IANA. The controversy is finally over!

I don’t understand why nginx would willingly refuse to follow a now
universally-agreed up IETF standard. This patch has already landed in
apache/httpd, by the way.

and it adds the "mjs" extension, which is known to be mostly used
> in NodeJS-specific environments and was originally introduced with
> quite questionable claim that "on the web file extensions doesn't
> matter".
>

What do you think is questionable? It’s a fact that browsers do not care
about file extensions. (They care about MIME types and Content-Type HTTP
header.)

For example, https://mathiasbynens.be/ loads a JavaScript file at /js — no
extension. I could have named that file js.html or js.css or anything I
wanted, as long as I serve it with the proper Content-Type header, browsers
happily accept it.

Of course, file extensions are still useful for servers to send the proper
Content-Type header.


> I don't think we are in position to add the mjs extension, it does
> not seem to qualify as something commonly used on the web now.


What’s the harm in adding the extension mapping? If it’s not used, then
there’s no harm done.

The ticket referenced in the previous message can be used to track
> the request.
>
> As for the MIME type change from "application/javascript" to
> "text/javascript", this is something we'll consider as the outcome
> of the change suggested by the RFC becomes more clear.


What is unclear?


> For now,
> it looks like this might need more compatibility shims (such
> as adding both "text/javascript" and "application/javascript" to
> the default list of types handled by the charset module) and more
> changes (such as change of the MIME type used by autoindex with
> JSONP format).
>
> Hope this helps.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list -- nginx-devel at nginx.org
> To unsubscribe send an email to nginx-devel-leave at nginx.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20220527/8bccec6f/attachment.htm>