# MIME type oddity when using try\_files in combination with location/alias using regex captures

**URL:** <https://www.ruby-forum.com/t/mime-type-oddity-when-using-try-files-in-combination-with-location-alias-using-regex-captures/221852>\
**Category:** NGINX\
**Created:** [August 2, 2012, 7:40am UTC](https://www.ruby-forum.com/t/mime-type-oddity-when-using-try-files-in-combination-with-location-alias-using-regex-captures/221852 "2012-08-02T07:40:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [August 2, 2012, 7:40am UTC](https://www.ruby-forum.com/t/mime-type-oddity-when-using-try-files-in-combination-with-location-alias-using-regex-captures/221852/1 "2012-08-02T07:40:00Z")

</div>

Hello!

Given is following minimized test case

server {  
listen 80;  
server\_name [t1.example.com](http://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://t1.example.com)’  
[http://127.0.0.1/foo/bar.gif](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://t1.example.com)’  
[http://127.0.0.1/quux/foo/bar.gif](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

---

<div class="post-metadata">

**Author:** ![Christoph\_Schug](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c4cdca/32.png) [@Christoph\_Schug](https://www.ruby-forum.com/u/Christoph_Schug)\
**Post date:** [August 27, 2012, 2:00pm UTC](https://www.ruby-forum.com/t/mime-type-oddity-when-using-try-files-in-combination-with-location-alias-using-regex-captures/221852/2 "2012-08-27T14:00:22Z")

</div>

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](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