csg
August 22, 2012 07:54AM
On 2012-08-02 07:39, Christoph Schug wrote:

> 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.

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

-cs

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

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

csg August 02, 2012 01:40AM

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

csg August 22, 2012 07:54AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 231
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready