<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The <a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#location" target="_blank">location</a> documentation states the following:<br><i>A location can either be defined by a prefix string, or by a regular expression.</i><br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Thus, ~ and ~* being regex modifiers, the rest is considered as being classified as 'prefix.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That means the following is a 'prefix' location block:<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><span style="font-family:monospace,monospace">location /whatever/ {<br>}</span><br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That said, this block will match the <span style="font-family:monospace,monospace">/whatever/</span> string anywhere in the URI string, not only at its start.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">As a consequence, to me, the meaning of 'prefix' was not tied to the location of the matched string in the URI, but rather a definition more like 'matching a string in the URI'.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Without any modifier, a prefix location will be sensitive to the presence of regex locations, while with the ^~ modifier it also won't match the same cases.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That modifier actually have 2 consequences, instead of only the first being documented. My brain hurts...<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Note that if you remove the capability of the default (without any modifier) location to match the string anywhere in the URI (thus becoming 'prefix' <i>per se</i>), you do not have any other means to match a string regardless of its position in the URI than regex ones... which are discouraged from being used (see recent answer from Maxim on a similar topic).<br></div><div class="gmail_extra"><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​Where is the exit of the maze again?​</div><div><div><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 Tue, Dec 8, 2015 at 9:40 AM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Dec 07, 2015 at 10:08:40PM +0100, B.R. wrote:<br>
<br>
Hi there,<br>
<br>
> Does the ^~ location modifier finds a matching string at the start of an<br>
> URI?<br>
<br>
Yes.<br>
<br>
> I naively thought it was just a variant of the classic prefix search,<br>
<br>
Yes.<br>
<br>
> without any constraint on the placement of the matched string in an URI.<br>
<br>
No.<br>
<br>
> Is there a simple way of matching the longest prefix location anywhere in<br>
> an URI, discarding any regex location at the same level?<br>
<br>
"prefix" means "at the start".<br>
<br>
I'm not sure what you're asking.<br>
<br>
The first regex location that matches is used (with caveats). So if you<br>
have a regex location which is just your desired string, that is first in<br>
the config file, then it will be used ahead of any other regex locations<br>
that might have been used.<br>
<span><font color="#888888"><br>
        f<br>
--<br>
Francis Daly        <a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">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><br>
</font></span></blockquote></div><br></div></div>