[nginx] Update mime-types

[Maxim Dounin]

Hello!

On Fri, Mar 29, 2024 at 08:25:18PM +0300, Lafiel wrote:

> Hello!
> 
> Maxim Dounin писал(а) 2024-03-28 05:20:
> > It's in TODO list.
> 
> Then should take a closer look at Forgejo. It is developing a new
> ForgeFed protocol for collaborative development:
> https://forgefed.org

Interesting, thanks.

> > 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.
> 
> The configuration file `conf/nginx.conf` contains parameter
> `default_type application/octet-stream;`. It is entirely possible
> to change it to default instead of `text/plain` and remove remaining
> `application/octet-stream` types from the mime.types file.
> Small optimization :)

The mime.types file does not assume any default type, and rather 
specifies usable types for well-known extensions.  It is expected 
to work with all possible default types set - including text/plain 
(which is the default), application/octet-stream (which is in the 
example configuration and believed to be better suited for 
configurations with at least some basic mime.types available), and 
even no default type at all (in case we'll ever decide to follow 
Apache and switch to no default type, see 
https://bz.apache.org/bugzilla/show_bug.cgi?id=13986).

That is, removing application/octet-stream extensions from the 
mime.types file does not look like a valid option.

> > 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.
> 
> I checked that they use `application/octet-stream` type on their servers:
> $ curl --head https://download.microsoft.com/download/1/7/1/1718CCC4-6315-4D8E-9543-8E28A4E18C4C/dxwebsetup.exe
> 2>1 | grep 'Content-Type:'
> Content-Type: application/octet-stream

Just for the record, I've checked IIS mappings as available in 
applicationHost.config on hosts with IIS installed.  Not sure if 
there is a current mapping officially available online, but at 
least some not very old copy can be found here:

https://github.com/aspnet/AspLabs/blob/main/src/dotnet-iis/src/dotnet-iis/Resources/applicationHost.config#L370

> > 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.
> 
> I wanted to give as an example that changing type to another should not
> affect the work.

Well, Boulder simply ignores the Accept request header, that is, 
it ignores client preference for a particular type, nothing more.  
It provides no information if changing the response type will 
affect various clients or not.

> > 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.
> 
> There is no .crl extension in httparchive statistics, so I didn’t add it.
> I can try updating the commit :)

I think we can consider this at some point later, if/when there 
will be more information available.

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