[nginx] Update mime-types

Maxim Dounin mdounin at mdounin.ru
Thu Mar 28 02:20:29 UTC 2024


Hello!

On Tue, Mar 26, 2024 at 10:25:34PM +0300, Lafiel wrote:

> Hello!
> 
> Again I forgot to fix minor bugs in commits, I fixed it.
> Any plans to add a git mirror? :)

It's in TODO list.

> Maxim Dounin писал(а) 2024-03-26 06:29:
> > Apache still uses application/x-shockwave-flash.  Still, given
> > that Flash is EoLed since 2020, this probably doesn't matter.
> > 
> > OTOH, it might be a good idea to don't touch it, specifically
> > because it is EoLed anyway, and such a change is not expected to
> > improve things, but might break some installations which still
> > work.
> > 
> > Overall, I'm mostly neutral on the change.  Are there any specific
> > reasons for the change?
> 
> There are no specific reasons for the change. There is no way to
> check these change. Сan ignore this commit.

Thanks for the details.  I would rather drop it then.

> > In practice, "crt" extension is used for PEM files with
> > certificates.  As such, changing "pem" and not changing "crt"
> > looks wrong.
> > 
> > Further, PEM-format files, which use "pem" extension, are
> > certainly not just certificate chain files.  While PEM files might
> > indeed contain application/pem-certificate-chain data, as defined
> > in RFC 8555, that's certainly not the only option.
> > 
> > Overall, I would rather refrain from the change unless there are
> > some better reasons than "because there is an IANA-registered
> > type".
> 
> Added additional information and links in commit. Also added an
> additional commit.

Thanks for the details, see comments below.

> > Any specific reasons for the change?
> > 
> > While application/vnd.microsoft.portable-executable type might be
> > more correct based on the IANA registration,
> > application/octet-stream is expected to be at least equally good
> > from practical point of view.
> 
> Updating current MIME types :)
> In addition, application/octet-stream already has many different
> extensions.

Well, number of extensions mapped to application/octet-stream is 
certainly shouldn't be a deciding factor - this is essentially a 
catch-all type, suitable for most files.

Further, application/vnd.microsoft.portable-executable type looks 
questionable.  In particular, Microsoft's own IIS uses 
application/x-ms-download for "dll" files, and 
application/octet-stream for "exe" files.  Apache uses 
application/x-msdownload for both.

Based on this data, I would rather refrain from changes.  Thanks 
for trying.

> > Any specific reasons for the change?
> 
> Added additional information and links in commit.
> In addition application/vnd.debian.binary-package type is used on Debian
> update servers.
> Example:
> $ curl --head
> https://ftp.debian.org/debian/pool/main/n/nginx/nginx_1.24.0-2+b2_amd64.deb
> 2>1 | grep 'content-type:'
> content-type: application/vnd.debian.binary-package

Yep, thanks for the details, this looks like a valid enough 
reason.

> I still haven't received a response regarding extensions for Excel
> and PowerPoint. Nevertheless, the proposed extension options are
> used in Apache.

I believe we've agreed that there are no data to support inclusion 
of additional extensions.

> 
> 
> -- 
> Best regards,
> Lafiel
> mailto:lafiel at elven.pw

> # HG changeset patch
> # User Yuriy Izorkin <lafiel at elven.pw>
> # Date 1711471188 -10800
> #      Tue Mar 26 19:39:48 2024 +0300
> # Node ID 60523370528bd10ca360233c48a911eb097ac04c
> # Parent  28fbf78841dc3cefb8ecc24adeab5510772d3f8c
> MIME: changed type for rar files to application/vnd.rar.
> 
> The application/x-rar-compressed type is deprecated and is now
> replaced by application/vnd.rar [1].
> 
> Link for reference:
> 
> [1] https://www.iana.org/assignments/media-types/application/vnd.rar
> 
> diff -r 28fbf78841dc -r 60523370528b conf/mime.types
> --- a/conf/mime.types   Thu Mar 21 22:50:11 2024 +0300
> +++ b/conf/mime.types   Tue Mar 26 19:39:48 2024 +0300
> @@ -51,6 +51,7 @@
>                                                       xlsx;
>      application/vnd.openxmlformats-officedocument.wordprocessingml.document
>                                                       docx;
> +    application/vnd.rar                              rar;
>      application/vnd.wap.wmlc                         wmlc;
>      application/wasm                                 wasm;
>      application/x-7z-compressed                      7z;
> @@ -60,7 +61,6 @@
>      application/x-makeself                           run;
>      application/x-perl                               pl pm;
>      application/x-pilot                              prc pdb;
> -    application/x-rar-compressed                     rar;
>      application/x-redhat-package-manager             rpm;
>      application/x-sea                                sea;
>      application/x-shockwave-flash                    swf;

Pushed, thanks.

> # HG changeset patch
> # User Yuriy Izorkin <lafiel at elven.pw>
> # Date 1711471456 -10800
> #      Tue Mar 26 19:44:16 2024 +0300
> # Node ID e51ad92ff810714aa15d394a8dc14e67e234131a
> # Parent  60523370528bd10ca360233c48a911eb097ac04c
> MIME: changed type for swf to application/vnd.adobe.flash.movie.
> 
> The application/x-shockwave-flash type is considered non-standard,
> it is recommended to use application/vnd.adobe.flash.movie [1].
> 
> Link for reference:
> 
> [1] https://www.iana.org/assignments/media-types/application/vnd.adobe.flash.movie
> 
> diff -r 60523370528b -r e51ad92ff810 conf/mime.types
> --- a/conf/mime.types   Tue Mar 26 19:39:48 2024 +0300
> +++ b/conf/mime.types   Tue Mar 26 19:44:16 2024 +0300
> @@ -35,6 +35,7 @@
>      application/pdf                                  pdf;
>      application/postscript                           ps eps ai;
>      application/rtf                                  rtf;
> +    application/vnd.adobe.flash.movie                swf;
>      application/vnd.apple.mpegurl                    m3u8;
>      application/vnd.google-earth.kml+xml             kml;
>      application/vnd.google-earth.kmz                 kmz;
> @@ -63,7 +64,6 @@
>      application/x-pilot                              prc pdb;
>      application/x-redhat-package-manager             rpm;
>      application/x-sea                                sea;
> -    application/x-shockwave-flash                    swf;
>      application/x-stuffit                            sit;
>      application/x-tcl                                tcl tk;
>      application/x-x509-ca-cert                       der pem crt;

Dropped this one as discussed above, thanks.

> # HG changeset patch
> # User Yuriy Izorkin <lafiel at elven.pw>
> # Date 1711474326 -10800
> #      Tue Mar 26 20:32:06 2024 +0300
> # Node ID ba304001c62554448b3656777da41e6f399c524f
> # Parent  e51ad92ff810714aa15d394a8dc14e67e234131a
> MIME: changed type for pem files to application/x-x509-ca-cert.

Nitpicking: wrong summary, the change is to 
application/pem-certificate-chain.

> 
> For .pem files, the MIME type is application/pem-certificate-chain
> mime type used in accordance with section 9 of RFC 8555 [1] and
> IANA [2].
> 
> There is also an alternativevariant application/x-pem-file that is
> used in Let's Encrypt [3]. Boulder does not process Accept headers
> for Content-Type negotiation when retrieving certificates [4]. No
> matter what you pass you're going to be getting a chain of PEM
> formatted certificates [3].

It is not clear how Boulder handling of the Accept request header 
is relevant here.

Also, link [3] contains at least two comments which are directly 
relevant and contradicts to what the patch suggests, notably:

https://community.letsencrypt.org/t/formats-of-certificates-issued-by-lets-encrypt/194990/2

"You are also asking about file extensions being .cer, .crt, .pem, 
but there really isn't a standardized meaning for those extensions 
or their contents. Certbot uses .pem for files that are for a 
single certificate, a chain of certificates, or a private key, and 
much other software integrating with ACME follows that convention 
as well. Windows tends to use .cer for single certificates and 
.crt for certificates intended to be used as trust anchors, but 
doesn't care if they're DER-encoded or PEM-encoded, they just have 
different default behavior when double-clicking on them (as .crt 
will default to asking if you want to add it to your trust store 
and .cer will default to just showing you, at least when I last 
tried them)."

And 
https://community.letsencrypt.org/t/formats-of-certificates-issued-by-lets-encrypt/194990/4, 
which suggests mapping from extensions to MIME types.  In 
particular, it uses application/x-pem-file for pem files.

Similarly, letsencrypt.org is using application/x-pem-file for pem 
files, notably for their own keys.

> 
> Link for reference:
> 
> [1] https://www.rfc-editor.org/rfc/rfc8555#section-9
> [2] https://www.iana.org/assignments/media-types/application/x-x509-ca-cert
> [3] https://community.letsencrypt.org/t/formats-of-certificates-issued-by-lets-encrypt/194990
> [4] https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md#section-742
> 
> diff -r e51ad92ff810 -r ba304001c625 conf/mime.types
> --- a/conf/mime.types   Tue Mar 26 19:44:16 2024 +0300
> +++ b/conf/mime.types   Tue Mar 26 20:32:06 2024 +0300
> @@ -32,6 +32,7 @@
>      application/json                                 json;
>      application/mac-binhex40                         hqx;
>      application/msword                               doc;
> +    application/pem-certificate-chain                pem;
>      application/pdf                                  pdf;

Nitpicking: wrong sorting.

>      application/postscript                           ps eps ai;
>      application/rtf                                  rtf;
> @@ -66,7 +67,7 @@
>      application/x-sea                                sea;
>      application/x-stuffit                            sit;
>      application/x-tcl                                tcl tk;
> -    application/x-x509-ca-cert                       der pem crt;
> +    application/x-x509-ca-cert                       der crt;
>      application/x-xpinstall                          xpi;
>      application/xhtml+xml                            xhtml;
>      application/xspf+xml                             xspf;

As previously noted, I think it is utterly wrong to use different 
MIME types for "crt" and "pem" files, since these are typically 
used as synonyms for certificate files in PEM format.

Just for the record, Apache uses application/x-x509-ca-cert for 
"der" and "crt" files, and no specific type for "pem" (hence the 
default will be used).  IIS uses application/x-x509-ca-cert for 
"crt", "der", and also no specific type for "pem".

Overall, I would rather refrain from the change, at least till 
there there is a good understanding what any why we want to 
change, and how it will affect various use cases.

Dropped this for now, thanks.

> # HG changeset patch
> # User Yuriy Izorkin <lafiel at elven.pw>
> # Date 1711475606 -10800
> #      Tue Mar 26 20:53:26 2024 +0300
> # Node ID 0c981a83e6de7b7ae52f8d8c17f7ee79c9355b5b
> # Parent  ba304001c62554448b3656777da41e6f399c524f
> MIME: add application/pkix-cert mime type.
> 
> Extension usage statistics, according to httparhcive.org [3]:
> $ awk 'NR==1||/^cer,/' httparchive_exts.csv
> ext,total_pages,total_requests
> cer,8998,13225
> 
> The csv file was made with the following query:
> 
> SELECT
>   ext,
>   COUNT(distinct pageid) total_pages,
>   COUNT(0) total_requests
> FROM
>   `httparchive.summary_requests.2024_01_01_desktop`
> GROUP BY
>   ext
> ORDER BY
>   total_requests DESC
> 
> In Apache also uses this type [2]:
> $ awk '/^application\/pkix-cert/' mime.types
> application/pkix-cert                           cer
> 
> Link for reference:
> 
> [1] https://httparchive.org
> [2] https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
> 
> diff -r ba304001c625 -r 0c981a83e6de conf/mime.types
> --- a/conf/mime.types   Tue Mar 26 20:32:06 2024 +0300
> +++ b/conf/mime.types   Tue Mar 26 20:53:26 2024 +0300
> @@ -33,6 +33,7 @@
>      application/mac-binhex40                         hqx;
>      application/msword                               doc;
>      application/pem-certificate-chain                pem;
> +    application/pkix-cert                            cer;
>      application/pdf                                  pdf;
>      application/postscript                           ps eps ai;
>      application/rtf                                  rtf;

(Nitpicking: wrong sorting.)

I haven't see any requests for adding this extension and type.  
While httparchive indeed suggests it is actually used, it seems to 
be way less popular than crt:

$ grep -n 'crt\|cer' httparchive_exts.csv 
33:crt,182646,209814
93:cer,8998,13225
6578:cert,3,3

Unless there are requests, I would rather refrain from adding 
it.  Also, if at all, this probably should be added along with 
"crl" from the same RFC.

Dropped this for now, thanks.

> # HG changeset patch
> # User Yuriy Izorkin <lafiel at elven.pw>
> # Date 1711475987 -10800
> #      Tue Mar 26 20:59:47 2024 +0300
> # Node ID 6fe9c45cbf6fdc33ab3a48f984b5803c9576f07e
> # Parent  0c981a83e6de7b7ae52f8d8c17f7ee79c9355b5b
> MIME: changed type for exe and dll files to application/vnd.microsoft.portable-executable.
> 
> For .exe and .dll files the application/vnd.microsoft.portable-executable
> mime type is used according to IANA [1].
> 
> Link for reference:
> 
> [1] https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable
> 
> diff -r 0c981a83e6de -r 6fe9c45cbf6f conf/mime.types
> --- a/conf/mime.types   Tue Mar 26 20:53:26 2024 +0300
> +++ b/conf/mime.types   Tue Mar 26 20:59:47 2024 +0300
> @@ -41,6 +41,7 @@
>      application/vnd.apple.mpegurl                    m3u8;
>      application/vnd.google-earth.kml+xml             kml;
>      application/vnd.google-earth.kmz                 kmz;
> +    application/vnd.microsoft.portable-executable    exe dll;
>      application/vnd.ms-excel                         xls;
>      application/vnd.ms-fontobject                    eot;
>      application/vnd.ms-powerpoint                    ppt;
> @@ -74,7 +75,7 @@
>      application/xspf+xml                             xspf;
>      application/zip                                  zip;
> 
> -    application/octet-stream                         bin exe dll;
> +    application/octet-stream                         bin;
>      application/octet-stream                         deb;
>      application/octet-stream                         dmg;
>      application/octet-stream                         iso img;

As per the discussion above, dropped this for now, thanks.

> # HG changeset patch
> # User Yuriy Izorkin <lafiel at elven.pw>
> # Date 1711477808 -10800
> #      Tue Mar 26 21:30:08 2024 +0300
> # Node ID 11dedb9aa2bc4c70f52d11c5dc6a518bc288369f
> # Parent  6fe9c45cbf6fdc33ab3a48f984b5803c9576f07e
> MIME: changed type for deb and udeb files to application/vnd.debian.binary-package.
> 
> For .deb files to application/vnd.debian.binary-package mime type used in accordance
> with man pages [1] and IANA [2]. Also added .udeb extension.
> 
> This type is also used on update servers.
> 
> Link for reference:
> 
> [1] https://manpages.debian.org/bookworm/dpkg-dev/deb.5.en.html
> [2] https://www.iana.org/assignments/media-types/application/vnd.debian.binary-package
> 
> diff -r 6fe9c45cbf6f -r 11dedb9aa2bc conf/mime.types
> --- a/conf/mime.types   Tue Mar 26 20:59:47 2024 +0300
> +++ b/conf/mime.types   Tue Mar 26 21:30:08 2024 +0300
> @@ -39,6 +39,7 @@
>      application/rtf                                  rtf;
>      application/vnd.adobe.flash.movie                swf;
>      application/vnd.apple.mpegurl                    m3u8;
> +    application/vnd.debian.binary-package            deb udeb;
>      application/vnd.google-earth.kml+xml             kml;
>      application/vnd.google-earth.kmz                 kmz;
>      application/vnd.microsoft.portable-executable    exe dll;
> @@ -76,7 +77,6 @@
>      application/zip                                  zip;
> 
>      application/octet-stream                         bin;
> -    application/octet-stream                         deb;
>      application/octet-stream                         dmg;
>      application/octet-stream                         iso img;
>      application/octet-stream                         msi msp msm;

Pushed with minor commit log cleanup, thanks.

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



More information about the nginx-devel mailing list