I am using Nginx to serve a website that hosts a .Net application. The
a user needs to download and that triggers installation is a
file, and an MS Internet Information Server associates that with the
type application/x-ms-application. However that file never gets any
Content-Type header. I edited the mime.types configuration file to
that, but Nginx ignores that. When I rename the file to .app, and use a
type definition for that file it works. I also tried various other file
extensions of varying length, and it looks like there is a limit of 10
characters in a file type extenion of Nginx, and if that is exceeded
will be no Content-Type header.
Is my assumption correct? Where is this in the source files? (I know how
compile Nginx). Or any other idea what causes my problem?
Are you sure this configuration gets loaded (nginx -t OK, no error on
You could try to replace your types block with an empty one (to override
defaults if they are defined at upper level, or simply remove them) and
the following directive:
You should se the Content-Encoding set to this special value by
with HTTP on port 8080 and HTTPS on port 443.
If you get anything different, your request is probably served
yes, nginx -t reports OK.
I tried the empty types block with default_type as suggested - no change
I verified that there is no other block processing the request. There is
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
block redirecting output to a different file, and yes, the output goes
that different file. I even defined my own log_format that logs
$sent_http_content_type, and it reports application/x-ms-application for
http, and - when using https…
Any other idea what to try or check?
Thanks a lot!
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
(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 accross the same problem and this
help them to resolve the issue.