'^~' 'location' 'prefix' fails with named captures & '^~*' usage also fails totally

[j vp]

1.) one should expect that case sensitivity plays no role when using the "stop searching" notation (a '^') for 'location' regex's, but the '^~' prefix works and '^~*' does not.

2.) one can get the '^~' syntax verified at start-up with named captures as per this example:

location ^~ ^(?<epre>.+)?/error(?<efile>\/.+)$ {}

but as soon as you add usage of the named captures, the verification fails at that point (not at the regex itself). however, this does not happen 100% of the time! occasionally, if you have just one (1) named capture; the verification step completes w/o error.

this was discovered when the previous example was working with only the 'epre' capture and began to fail when the 'efile' was added. thereafter, removing the second capture would sometimes verify and sometimes not. seemingly, the problem is positional in its intermittency; since removing the first capture and leaving the second one never verified.

it seems the "stop searching" notation is not well-known/-documented and this may be why this problem is not widely reported.

distro: centos 6.3
perl: 5.16.2

[Valentin V. Bartenev]

^~ isn't regexp location prefix at all.

See the docs: ​http://nginx.org/r/location

A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified by prepending them with the “~*” prefix (for case-insensitive matching), or with the “~” prefix (for case-sensitive matching).

[j vp]

may i suggest some reading of the documentation:
​http://wiki.nginx.org/HttpCoreModule#location

to save you a click: 'If this match used the "^~" prefix, searching stops.'

i said this usage was not well-known, but i failed to comprehend the possibility that someone so ill-informed had the power to close defect reports on nginx's own site.

please re-instate this defect report so that someone can look into the problem.

[Valentin V. Bartenev]

Ok, I will try to explain better. There are only three types of locations:

1. Prefix locations (no prefix, or ^~). Simple string matching is performed.
2. Exact match locations (=). Actually it is a subtype of 1.
3. Regexp locations (~ or ~*).

Note: there's no ^~*.

When you write something like location ^~*/(a|b)/(.+) {, it's interpreted as prefix location (^~) with */(a|b)/(.+) matching string (not regular expression!). So your request must look like this one: GET */(a%7Cb)/(.+) HTTP/1.0, which isn't even a valid request line.

[j vp]

OK!

i believe what you are saying is that 'location zxc' is the equivalent of 'location ^~ zxc'. EXCEPT: using ^~ will match and stop the search while using nothing will match but the search goes on for something better and will come back to it only if the additional search fails. right?

if this is true, i still experienced something strange during my un-enlightened phase. when i used:
location ^~ ^(?<epre>.+)?/error(\/.+)$
{ set $subs $epre;

set $efile $2;

}
i cannot count the times that i re-started without any problems, but you are saying that this should not have worked at all. thus, there may be something wrong with the verification/assembly step(s).

thank you for your added time on this matter.

johann

[Valentin V. Bartenev]

i believe what you are saying is that location zxc is the equivalent of location ^~ zxc. EXCEPT:

Yes.

using ^~ will match and stop the search while using nothing will match but the search goes on for something better and will come back to it only if the additional search fails. right?

Yes, right. ^~ just prevents searching for regular expressions locations, if this prefix location is chosen after the prefix locations search. ^~ is like [NO]~

i cannot count the times that i re-started without any problems, but you are saying that this should not have worked at all. thus, there may be something wrong with the verification/assembly step(s).

It doesn't prevent nginx to start, since ^(?<epre>.+)?/error(\/.+)$ looks like a valid string for nginx, but it just will not work at runtime (no request will match this location).

[Valentin V. Bartenev]

Anyway, if something is not like that, and you really experience the previous example was working with only the 'epre' capture and began to fail when the 'efile' was added, while it must not work in both cases, then please provide a full minimal config to reproduce the bug.