MIME type oddity when using try_files in combination with location/alias using regex captures

Hello!

Given is following minimized test case

server {
listen 80;
server_name t1.example.com;

 root                            /data/web/t1.example.com/htdoc;

 location                        ~ ^/quux(/.*)?$ {
     alias                       /data/web/t1.example.com/htdoc$1;
     try_files                   '' =404;
 }

}

on Nginx 1.3.4 (but not specific to that version)

nginx -V

nginx version: nginx/1.3.4
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx
–conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin/nginx
–http-log-path=/var/log/nginx/access.log
–error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid
–user=nginx --group=nginx --with-openssl=openssl-1.0.1c --with-debug
–with-http_stub_status_module --with-http_ssl_module --with-ipv6

and following file system layout

find /data/web/t1.example.com/htdoc/

/data/web/t1.example.com/htdoc/
/data/web/t1.example.com/htdoc/foo
/data/web/t1.example.com/htdoc/foo/bar.gif

Accessing the file directly returns the expected ‘Content-Type’
response header with the value ‘image/gif’

$ curl -s -o /dev/null -D - -H ‘Host: t1.example.com
http://127.0.0.1/foo/bar.gif
HTTP/1.1 200 OK
Server: nginx/1.3.4
Date: Thu, 02 Aug 2012 05:13:40 GMT
Content-Type: image/gif
Content-Length: 68
Last-Modified: Thu, 02 Aug 2012 05:04:56 GMT
Connection: keep-alive
ETag: “501a0a78-44”
Accept-Ranges: bytes

Accessing the file via location /quux returns ‘Content-Type’ response
header with the value ‘application/octet-stream’ (basically it falls
back to the setting of ‘default_type’)

$ curl -s -o /dev/null -D - -H ‘Host: t1.example.com
http://127.0.0.1/quux/foo/bar.gif
HTTP/1.1 200 OK
Server: nginx/1.3.4
Date: Thu, 02 Aug 2012 05:13:42 GMT
Content-Type: application/octet-stream
Content-Length: 68
Last-Modified: Thu, 02 Aug 2012 05:04:56 GMT
Connection: keep-alive
ETag: “501a0a78-44”
Accept-Ranges: bytes

It is unclear to me if this is expected behavior (and if so, I am
having a hard time to find it in the documentation) and what would be
the best way to mitigate the problem. Defining nested locations within
the /quux one for each combination of file extension/MIME type works but
looks very wrong to me.

-cs

On 2012-08-02 07:39, Christoph Schug wrote:

    try_files                   '' =404;

–http-log-path=/var/log/nginx/access.log
/data/web/t1.example.com/htdoc/foo/bar.gif
Content-Length: 68
http://127.0.0.1/quux/foo/bar.gif
It is unclear to me if this is expected behavior (and if so, I am
having a hard time to find it in the documentation) and what would be
the best way to mitigate the problem. Defining nested locations
within
the /quux one for each combination of file extension/MIME type works
but looks very wrong to me.

No feedback so far, just wanted to add the the same behavior is
reproducible using Nginx 1.3.5.

-cs

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