Weird location choice

B.R. reallfqq-nginx at yahoo.fr
Wed Nov 18 21:24:04 UTC 2015


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>


More information about the nginx mailing list