Location ^~ modifier

Server NGINX
1

Hello,

I got kind of a newbie question:
Does the ^~ location modifier finds a matching string at the start of an
URI?

I naively thought it was just a variant of the classic prefix search,
without any constraint on the placement of the matched string in an URI.

Is there a simple way of matching the longest prefix location anywhere
in
an URI, discarding any regex location at the same level?

​Thanks,​

B. R.

2

On Mon, Dec 07, 2015 at 10:08:40PM +0100, B.R. wrote:

Hi there,

Does the ^~ location modifier finds a matching string at the start of an
URI?

Yes.

I naively thought it was just a variant of the classic prefix search,

Yes.

without any constraint on the placement of the matched string in an URI.

No.

Is there a simple way of matching the longest prefix location anywhere in
an URI, discarding any regex location at the same level?

“prefix” means “at the start”.

I’m not sure what you’re asking.

The first regex location that matches is used (with caveats). So if you
have a regex location which is just your desired string, that is first
in
the config file, then it will be used ahead of any other regex locations
that might have been used.

f

Francis D. [email protected]

3

The location
http://nginx.org/en/docs/http/ngx_http_core_module.html#location
documentation states the following:
A location can either be defined by a prefix string, or by a regular
expression.

Thus, ~ and ~* being regex modifiers, the rest is considered as being
classified as 'prefix.
That means the following is a ‘prefix’ location block:
location /whatever/ {
}

That said, this block will match the /whatever/ string anywhere in the
URI
string, not only at its start.

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’.

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.
That modifier actually have 2 consequences, instead of only the first
being
documented. My brain hurts…

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’ per se), 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).

​Where is the exit of the maze again?​

B. R.

4

On Tue, Dec 08, 2015 at 06:33:52PM +0100, B.R. wrote:

Hi there,

That means the following is a ‘prefix’ location block:
location /whatever/ {
}

That said, this block will match the /whatever/ string anywhere in the URI
string, not only at its start.

No, it won’t.

===
location / {
return 200 “in location /\n”;
}

location /aaa/ {
    return 200 "in location /aaa/\n";
}

===

$ curl http://localhost/aaa/bbb/
in location /aaa/

$ curl http://localhost/bbb/aaa/
in location /

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’.

No.

“prefix” has its normal English language meaning. The documentation at
Module ngx_http_core_module is correct.

(I think the documentation there is incomplete, as it is not
immediately
clear to me how nested locations are searched. But that has been
clarified
on the mailing list recently, and that clarification matches what can
be seen in tests.)

Where is the exit of the maze again?

prefix matches – without modifier, with modifier ^~, and (technically,
probably) with modifier = – are exact string matches at the start of
the url. (And consequently should all start with the character “/”.)

If you want to match something that is not an exact string match at the
start of the url, you must use something that is not a prefix match.

f

Francis D. [email protected]

5

Thanks Francis,

I directly went back to the basics nginx 101 lesson.
I feel dumb all of a sudden…

The maze was made of my misconceptions!
I wonder where they came from. I was sure I tested what I said… which
is
impossible.

B. R.