[nginx] Update mime-types

[Lafiel]

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


> 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 
:)


> 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


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


> 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 
:)


-- 
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/20240329/2ee13b03/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/20240329/2ee13b03/attachment.sig>