Weird location choice

[Maxim Dounin]

Hello!

On Wed, Nov 18, 2015 at 09:18:51PM +0100, B.R. wrote:

> WIth the following configuration:
> server {
>     listen      80;
>     listen      [::]:80;
> 
>     location / {
>         location ~* "^/[[:alnum:]]+$" {
>             default_type text/plain;
>             return 200 "KO";
>         }
>     }
> 
>     location ~* "^/test" {
>         default_type text/plain;
>         return 200 "OK";
>     }
> }
> 
> ​I noticed that calling example.org/test returns KO.​
> 
> The location docs
> <http://nginx.org/en/docs/http/ngx_http_core_module.html#location> say the
> longest prefix match ('/') is remembered then regex are checked. Since the
> 'test' regex is on the same level, you would expect higher precedence for
> it compared to the embedded 'alnum' one, which is one level deeper.

When using nested locations within the location "/" (the longest 
prefix location found at top level) nginx will repeat location 
search: it will search for a longest prefix location (won't find 
anything as there are no prefix locations within "/"), and then 
will search for regex locations (will find one with "alnum").  As 
a regex location was found, searching stops.

> If secondary-level regex locations have the same priority as others, you
> are basically doomed trying to prioritize regex locations between each
> others using prefix locations at an upper-level.

Things are not that bad, as only locations within the longest 
prefix location are considered.  And, actually, when using regex 
locations you are doomed anyway.

Here is Igor's talk about configuration scalability, in particular 
he talks about regex locations and why it's better to avoid them 
(I believe you've been there, actually):

http://www.youtube.com/watch?v=YWRYbLKsS0I

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