<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Thanks Maxim,<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Well, regex location for this particular exemple is indeed useless, but might prove very useful when URI description is not trivial.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Too bad they are that flawed.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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)<br></div><div class="gmail_extra"><div><div class="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Wed, Nov 18, 2015 at 9:43 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Wed, Nov 18, 2015 at 09:18:51PM +0100, B.R. wrote:<br>
<br>
> WIth the following configuration:<br>
> server {<br>
>     listen      80;<br>
>     listen      [::]:80;<br>
><br>
>     location / {<br>
>         location ~* "^/[[:alnum:]]+$" {<br>
>             default_type text/plain;<br>
>             return 200 "KO";<br>
>         }<br>
>     }<br>
><br>
>     location ~* "^/test" {<br>
>         default_type text/plain;<br>
>         return 200 "OK";<br>
>     }<br>
> }<br>
><br>
> ​I noticed that calling <a href="http://example.org/test" rel="noreferrer" target="_blank">example.org/test</a> returns KO.​<br>
><br>
> The location docs<br>
</span>> <<a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#location" rel="noreferrer" target="_blank">http://nginx.org/en/docs/http/ngx_http_core_module.html#location</a>> say the<br>
<span class="">> longest prefix match ('/') is remembered then regex are checked. Since the<br>
> 'test' regex is on the same level, you would expect higher precedence for<br>
> it compared to the embedded 'alnum' one, which is one level deeper.<br>
<br>
</span>When using nested locations within the location "/" (the longest<br>
prefix location found at top level) nginx will repeat location<br>
search: it will search for a longest prefix location (won't find<br>
anything as there are no prefix locations within "/"), and then<br>
will search for regex locations (will find one with "alnum").  As<br>
a regex location was found, searching stops.<br>
<span class=""><br>
> If secondary-level regex locations have the same priority as others, you<br>
> are basically doomed trying to prioritize regex locations between each<br>
> others using prefix locations at an upper-level.<br>
<br>
</span>Things are not that bad, as only locations within the longest<br>
prefix location are considered.  And, actually, when using regex<br>
locations you are doomed anyway.<br>
<br>
Here is Igor's talk about configuration scalability, in particular<br>
he talks about regex locations and why it's better to avoid them<br>
(I believe you've been there, actually):<br>
<br>
<a href="http://www.youtube.com/watch?v=YWRYbLKsS0I" rel="noreferrer" target="_blank">http://www.youtube.com/watch?v=YWRYbLKsS0I</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></font></span></blockquote></div><br></div></div>