Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#270 closed defect (invalid)

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

Reported by: j.vonpreussen@… Owned by:
Priority: critical Milestone:
Component: nginx-core Version: 1.3.x
Keywords: location regex "stop searching'' prefix Cc:
uname -a: Linux domain.tld 2.6.18-pony6-3 #1 SMP Tue Mar 13 07:31:44 PDT 2012 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.3.9 built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-http_geoip_module --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --with-file-aio --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-upstream-fair --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-upload-progress-module --add-module=/builddir/build/BUILD/nginx-1.3.9/mod_zip-1.1.6 --add-module=/builddir/build/BUILD/nginx-1.3.9/ngx_http_auth_pam_module-1.2 --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-upload-module-2.2 --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-rtmp-module-master

Description

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

Change History (7)

comment:1 Changed 6 years ago by vbart

^~ 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).

comment:2 Changed 6 years ago by vbart

  • Resolution set to invalid
  • Status changed from new to closed

comment:3 Changed 6 years ago by j.vonpreussen@…

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.

comment:4 Changed 6 years ago by vbart

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.

Last edited 6 years ago by vbart (previous) (diff)

comment:5 Changed 6 years ago by j.vonpreussen@…

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

comment:6 Changed 6 years ago by vbart

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

comment:7 Changed 6 years ago by vbart

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.

Last edited 6 years ago by vbart (previous) (diff)
Note: See TracTickets for help on using tickets.