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@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/
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-leave@nginx.org