[nginx] Update mime-types

[Lafiel]

Hello!

Maxim 
Dounin 
писал(а) 
2024-03-21 
23:01:
> 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

Ok.


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

Yes, 
based 
on 
this 
data.
There 
is 
speculation 
that 
these 
extensions 
may 
be 
used 
more 
frequently
in 
attachments 
when 
forwarding 
emails. 
These 
types 
will 
be 
relevant 
when
viewing 
via 
the 
web 
interface. 
But 
I 
don't 
have 
such 
statistics.


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

A 
quick 
internet 
search 
for 
using 
the 
wbxml 
extension 
yielded 
no 
results.


-- 
Best 
regards,
Lafiel
mailto:lafiel at elven.pw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAB0C3D2.asc
Type: application/pgp-keys
Size: 1461 bytes
Desc: not available
URL: <http://freenginx.org/pipermail/nginx-devel/attachments/20240322/ea9ceec1/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://freenginx.org/pipermail/nginx-devel/attachments/20240322/ea9ceec1/attachment.sig>