several sibling location block

[Ingo Schmidt]

Hi!

> to nginx, as follows:
>
>
> location / {
>
>     # force download for ceratain file types
>     location ~* \.(?:fb2|mobi|mp3)$ {
>          add_header Content-Disposition "attachment";
>     }
>     location ~* \.fb2$ {
>          add_header Content-type "text/fb2+xml";
>     }
>     location ~* \.mobi$ {
>          add_header Content-type "application/x-mobipocket-ebook";
>     }
>     location ~* \.mp3$ {
>          add_header Content-type "audio/mpeg";
>     }
>
> ...
> }
>
> Content-Disposition "attachment" seems to be added properly to the
> header, however not the Content-type. Why? Can several sibling location
> blocks that match be proceeded or only one?
Several things to note here:
- nesting is completely unnecessary here since you use the default 
location which always matches (if there are no other rules being more 
specific)
- when processing a request, nginx will search for exactly one location 
that matches your request, following the rules described in detail in 
the docs: http://nginx.org/en/docs/http/ngx_http_core_module.html#location
- regex locations are considered in order or appearance. Your first 
location is found and used, and only that one.
- stop thinking apache (I believe I alread told you that? ;-)): check 
the mime.types file of nginx in /etc/nginx/. It comes with the 
installation and this is how you specify content-type headers. If the 
provided mapping doesn't suite you, create your own and include that 
instead. So you dont need all your content-type locations at all.

And use the docs, they are pretty concise (sometimes you need to read a 
couple of times, but it almost always turns out to be accurate :-))
http://nginx.org/en/docs/

And I promise you once again, once you know how to configure nginx and 
once it works for you, you'll wonder how you ever could have used Apache 
(just my personal opinion, of course!)

Cheers, Ingo =;->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170614/f82d4a60/attachment.html>