Weird location choice

[B.R.]

Thanks Maxim,

Well, regex location for this particular exemple is indeed useless, but
might prove very useful when URI description is not trivial.
Too bad they are that flawed.

I remember this talk very well indeed and think about it almost daily when
dealing with nginx configuration. I had hopes for regex locations... ;o)
---
*B. R.*

On Wed, Nov 18, 2015 at 9:43 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20151118/bef433e6/attachment.html>