So it sounds like my only solution is to restructure the locations to avoid the original match in /. I don't have access to the servers again until tomorrow, but I'm wondering if something like this would work:

location / {
#base content
}

location ~ regex2 {
#alternate folders to proxy_pass from .Net servers
}

location ~ regex3 {
#catch all css, js, images, and other static files

location ~ regex4 {
#same as regex2. Alternate static location for .Net apps
}
location / {
#match all "static files" not caught by regex4
}
}


If I'm understanding location precedence correctly, the regex3 location should always hit first, because its regex will contain an exact match for the file types. The nested regex4 (identical to regex2) will then match the folder name in that request, so the custom configuration can be applied only to the regex3 file types contained within the regex4 folders. Requests for the regex3 file types at locations not matching regex4 will be handled by the nested /.

Will this work, or will the second nested / location break things?

________________________________________
From: nginx-bounces@nginx.org [nginx-bounces@nginx.org] on behalf of Maxim Dounin [mdounin@mdounin.ru]
Sent: Monday, February 17, 2014 5:13 AM
To: nginx@nginx.org
Subject: Re: Proxy pass location inheritance

Hello!

On Mon, Feb 17, 2014 at 08:55:02AM +0000, Brian Hill wrote:

> Close, it's more akin to:
>
> location / {
> location ~ regex1 {
> # regex inside /
> }
> }
>
> location ~ regex2 {
> location ~ regex3 {
> # regex inside regex2
> }
> }
>
> And the question is: where will a request matching both regex1
> and regex3 be handled?

Much like in the previous case, regex1 is checked first because
it's inside a prefix location matched. And matching stops once it
matches a request.

> Regex 1 & 3 look for the same file types and are identical, but
> contain different configurations based on the parent location.
> Currently, regex1 is catching all matches, irrespective of the
> parent location.

That's expected behaviour.

> If I understand correctly, I could solve my problem by moving
> the regex2 location block before the / location block, and then
> rewriting regex3 so that it included the elements of both the
> current regex2 and regex3. That way, regex3 would ONLY hit for
> items that matched both the current regex2 and regex3, and it
> would appear before regex1 in the order of execution.
>
> Is this correct, or will NGINX always give priority to the /
> location?

No. There is no difference between

location / { location ~ regex1 { ... } }
location ~ regex2 { ... }

and

location ~ regex2 { ... }
location / { location ~ regex1 { ... } }

Locations given by regular expressions within a matching prefix
location (not necessary "/") are always checked first.

--
Maxim Dounin
http://nginx.org/

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

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