Is there a length limitation on file extensions?

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

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265148,265148#msg-265148

j.o.l:

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

works here, so your assumption seems wrong.

server {
listen *:80;
server_name localhost;
location / {
autoindex on;
alias /tmp/;
}
types {
application/x-ms-executable application;
}
}

$ touch /tmp/foo.application

$ curl -I localhost/foo.application
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 07 Mar 2016 22:29:42 GMT
Content-Type: application/x-ms-executable
Content-Length: 0
Last-Modified: Mon, 07 Mar 2016 22:26:52 GMT
Connection: keep-alive
Accept-Ranges: bytes

$

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;
            ssl_certificate_key 

/etc/letsencrypt/live/xxx/privkey.pem;
root /usr/local/nginx/conf/websites/xxx;
autoindex on;
types {
application/x-ms-application application;
}
}

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.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265148,265162#msg-265162

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.

B. R.

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!

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265148,265197#msg-265197

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.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265148,265200#msg-265200

j.o.l:

Any other idea what to try or check?

I would write two separate server blocks,

server {
listen 8080;

server_name xxx;
root /usr/local/nginx/conf/websites/xxx;
autoindex on;
types {
application/x-ms-application application;
}
}

server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/xxx/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/xxx/privkey.pem;

server_name xxx;
root /usr/local/nginx/conf/websites/xxx;
autoindex on;
types {
application/x-ms-application application;
}
}

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs