[nginx] Update mime-types

Thu Mar 21 20:01:30 UTC 2024

Hello!

On Wed, Mar 20, 2024 at 09:13:36PM +0300, Lafiel wrote:

> Maxim Dounin писал(а) 2024-03-18 21:54:
> > Hello!
> > 
> > On Fri, Mar 15, 2024 at 02:01:13PM +0300, Lafiel wrote:
> > 
> > 
> > Since the bmp extension is already there, it hardly make sense to
> > refer to HTTP Archive data.  Rather, I would focus on the browsers
> > compatibility, as mentioned earlier in the thread.  Please take a
> > look at the patch below.
> > 
> > ...
> 
> Okay, I agree with this variant.

Thanks for prodding this, committed.

> > Note that Apache uses audio/x-mpegurl, which is a separate type.
> > 
> > The m3u extension is historically used by audio playlists in the
> > MP3 URL format as originally introduced Fraunhofer, see
> > https://en.wikipedia.org/wiki/M3U.
> > 
> > While Apple's playlist format is based on the original MP3 URL
> > format, the are differences.  In particular, m3u files were
> > expected to be in the native charset, while
> > application/vnd.apple.mpegurl files are expected to be in UTF-8.
> > While HLS specification (RFC 8216, independent submission, an
> > informational RFC from Apple) makes no distinction between the two
> > extensions, it is quite possible the distinction remains in
> > practice.  Apple itself recommends m3u8 extension for HLS
> > playlists
> > (https://developer.apple.com/documentation/http-live-streaming/deploying-a-basic-http-live-streaming-hls-stream).
> > 
> > While the m3u extension might be worth adding to mime.types, the
> > question of the expected type remains.  Using a vendor-specific
> > type which implies different handling than a vendor-neutral well
> > known format might not be what real users want/expect.
> 
> I think it's worth sticking with the IANA option rather than supporting
> legacy type. In addition, Nginx did not previously have the m3u type and
> it was identified as application/octet-stream. I don't think there will
> be any new problems with application/vnd.apple.mpegurl type.

Unfortunately, IANA MIME types registry is not an universal source 
of truth for extensions to MIME types mapping.  Especially when it 
comes to vendor-specific types.  It merely lists registered MIME 
types, and extensions vendors consider to be associated with these 
types.  As long as one tries to build a mapping from extensions to 
types, there are obvious conflicts even within IANA MIME types 
registry itself (the wbxml extension is a good example), not to 
mention potential conflicts with other uses of the extensions.

And such conflicts might manifest itself even if there were no 
explicit mapping previously: if particular files work well with 
application/octet-stream type (for example, a player assumes 
correct handling based on the extension, or the file is simply 
saved by the browser and can be opened by a correct player), they 
might not work with application/vnd.apple.mpegurl (if the player 
prefers the explicit type specified over extension-based 
assumptions).

Further, in configurations where the m3u extension is explicitly 
added with correct MIME type, adding another one will cause a 
warning during configuration testing which is not possible to 
suppress.

Not to mention that distinct types can be needed to provide proper 
charsets for m3u files.

Summing the above, I would rather keep it as is, at least till 
there is some input from streaming services.  Especially keeping 
in mind that m3u8 is way more popular:

m3u8,68033,503050
m3u,15,302

> > The numbers provided does not support the idea of adding these
> > extensions.
> 
> Yes, but in Apache MS Excel and Powerpoint extensions are rare, but are
> used.
> Or can shorten it to "xls xlt" in MS Excel extensions.

You mean, based on

xls,22,38
xlt,2,2

in the HTTP Archive data?  Numbers for both xls and xlt seems very 
low, and clearly below various garbage extensions, such as 

sk%2f,1280,17999
au%2f,2983,13775
js at 6,3913,4520

While this might be a result of what HTTP Archive data are 
expected to contain (it is mostly focused on how sites are built, 
and not on various files available for download), it clearly does 
not demonstrate significance of the extensions.  There should be 
some other data to support such a change.

> > WAP in general and WML particularly are dead for a long time now,
> > and I would rather consider removing the wmlc extension, as well
> > as other vnd.wap types.
> > 
> > Further, wbxml files have their own vendor MIME type registered in
> > IANA:
> > 
> > https://www.iana.org/assignments/media-types/application/vnd.wap.wbxml
> > 
> > It can be also seen in Apache mime.types as mentioned in the
> > commit log.  If at all, the application/vnd.wap.wbxml type
> > probably should be used for such files.  I don't see reasons
> > to add wbxml files though.
> 
> Then is it better to make a commit that removes this type, or add .wbxml
> separately, like in Apache?

I'm mostly neutral on removing WAP-related types (including 
text/vnd.wap.wml, image/vnd.wap.wbmp, application/vnd.wap.wmlc, as 
well as text/vnd.wap.wml in default charset_types): while mostly 
unused now and probably safe to remove, these don't hurt much.

As for wbxml, I don't see any data supporting the idea of adding 
this extension.  If you think it's actually used, please share the 
details.

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