Nested location block for merging config returns 404?

[Valentin V. Bartenev]

On Tuesday 21 January 2014 08:29:18 WheresWardy wrote:
> I want a location to proxy to another service, and need to add an extra
> header for certain file types, but when trying to merge the configuration
> with a nested location instead of duplicating nginx instead returns a 404.
> 
> For example, this configuration works:
> 
> location ~ /(dir1/)?dir2/ {
>   add_header X-My-Header value1;
>   proxy_pass http://myproxy;
> }
> 
> location ~ /(dir1/)?dir2/.*\.(txt|css) {
>   add_header X-My-Static value2;
>   add_header X-My-Header value1;
>   proxy_pass http://myproxy;
> }
> 
> Passing valid URLs to the above config works perfectly, and I'll get the
> extra header set if it's a txt or css file (examples for the sake of
> argument). However, what I want to accomplish is to merge these two blocks
> into one nested location block to save on the duplication, however when I do
> that I just get a 404 returned for the previously workings URLs:
> 
> location ~ /(dir1/)?dir2/ {
>   location \.(txt|css) {
>     add_header X-My-Static value2;
>   }
>   add_header X-My-Header value1;
>   proxy_pass http://myproxy;
> }
> 
> Can location blocks actually be nested in this way? I'm wondering if the 404
> is because it's only parsing the specific nested block, and doesn't fallback
> onto the remaining config underneath (and therefore never gets sent to the
> proxy, and it's nginx returning a 404 which would be expected for that URL).
[..]

Yes, they can.  But, please note that the proxy_pass directive is not
inherited, and you should duplicate it in your nested location block.

There is a good article on the topic:
http://blog.martinfjordvald.com/2012/08/understanding-the-nginx-configuration-inheritance-model/ 

  wbr, Valentin V. Bartenev