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@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/ -- nginx-devel mailing list nginx-devel@freenginx.org https://freenginx.org/mailman/listinfo/nginx-devel
