Re: [nginx] Update mime-types

Fri, 22 Mar 2024 05:47:19 -0700 

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@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:laf...@elven.pw


Attachment:
0xFAB0C3D2.asc

Description: application/pgp-keys



Attachment:
signature.asc

Description: OpenPGP digital signature


-- 
nginx-devel mailing list
nginx-devel@freenginx.org
https://freenginx.org/mailman/listinfo/nginx-devel






















					Reply via email to