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. When I rename the file to .app, and use a
mime
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
there
will be no Content-Type header.
Is my assumption correct? Where is this in the source files? (I know how
to
compile Nginx). Or any other idea what causes my problem?
Thanks, Joachim
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:
When I access that server using http, Content-Type is returned as
defined,
when accessing it via https, Content-Type is missing. Strange, isn´t it?
Btw. I am using nginx 1.8.0.
Are you sure this configuration gets loaded (nginx -t OK, no error on
configuration -re-loading)?
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
add
the following directive:
default_type application/x-ms-application
You should se the Content-Encoding set to this special value by
requesting
with HTTP on port 8080 and HTTPS on port 443.
If you get anything different, your request is probably served
elsewhere.
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, the output goes
to
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
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 accross the same problem and this
will
help them to resolve the issue.