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

[Maxim Dounin]

Hello!

On Fri, May 27, 2022 at 09:23:47AM +0200, Mathias Bynens via nginx-devel wrote:

> On Fri, May 27, 2022 at 1:55 AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > 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.

For sure there are reasons.  For example, RFC 2324 was also 
published for a reason.  The question is: how it aligns with the 
real world usage, and how it should be implemented, if at all.

In this particular case, the RFC itself talks about "text/*" being 
an incorrect, and only used because "the industry widely adopted 
text/* anyway".  On the other hand, httparchive.org data suggests 
that "application/javascript" is more popular now than 
"text/javascript":

Query:

SELECT
  mimeType,
  COUNT(distinct pageid) total_pages,
  COUNT(0) total_requests
FROM
  `httparchive.summary_requests.2022_03_01_desktop`
GROUP BY
  mimeType
ORDER BY
  total_requests DESC

Results:

Row	mimeType	total_pages	total_requests	
1	application/javascript 5346744 95187099
2	image/jpeg 4608713 78732193
3	image/png 5129850 58321805
4	text/css 5546313 56797104
5	text/html 5718485 41375375
6	text/javascript 4670822 36042510
...
11	application/json 3641048 16939555
12	application/x-javascript 2577400 14903323
...

>From the rationale provided in the RFC it is not clear why 
"application/javascript", which is more popular, was dropped in 
favor of the "text/javascript", which is incorrect and less 
popular.

> > 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.

Your patch clearly shows that the file extension does matter on 
the web: servers use them to provide proper content type.  As 
such, adding arbitrary additional file extensions is going to hurt 
the web, since servers won't be able to provide appropriate 
content type.

> > 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.

Additional types and extensions imply additional resources on all 
MIME type lookups.  As such, nginx doesn't try to maintain all the 
mime types and extensions, but rather tries to supply types 
generally needed for a web server.

> > 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?

I believe I've provided a few things not considered by your patch 
in the following sentence, including the one which is a 
compatibility problem and can result in non-working sites due to 
an unexpected MIME type change, resulting in incorrect charset 
information.

-- 
Maxim Dounin
http://mdounin.ru/