mdounin at mdounin.ru
Fri May 27 16:00:13 UTC 2022
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
> 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
COUNT(distinct pageid) total_pages,
Row mimeType total_pages total_requests
2 image/jpeg 4608713 78732193
3 image/png 5129850 58321805
4 text/css 5546313 56797104
5 text/html 5718485 41375375
11 application/json 3641048 16939555
>From the rationale provided in the RFC it is not clear why
> > 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
> 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
> > 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.
> > 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
More information about the nginx-devel