after some more experiments it looks like I was caught by a looking at cached data. I was reloading the file for https as it was displayed as text (happens to be readable xml). However this reload was answered with not-modified without content-type (which is afaik standard conformant). Only on hard reload Chrome got a new copy with content type header. Goofish or not, maybe others stumble accrby j.o.l - Nginx Mailing List - English
yes, nginx -t reports OK. I tried the empty types block with default_type as suggested - no change to the behavior. I verified that there is no other block processing the request. There is no other block that uses that certificate on port 443, and the port 8080 is used for that server block only. I also added an access_log to that server block redirecting output to a different file, and yes, thby j.o.l - Nginx Mailing List - English
Thanks a lot for providing a working example. I reproduced it and yes works with that server block. Then I tried to change until I discovered the following. Here is my server block: server { listen 443 ssl; listen 8080; server_name xxx; ssl_certificate /etc/letsencrypt/live/xxx/fullchain.pem;by j.o.l - Nginx Mailing List - English
I am using Nginx to serve a website that hosts a .Net application. The file a user needs to download and that triggers installation is a *.application file, and an MS Internet Information Server associates that with the mime type application/x-ms-application. However that file never gets any Content-Type header. I edited the mime.types configuration file to include that, but Nginx ignores that. Whby j.o.l - Nginx Mailing List - English