Opened 9 months ago

Closed 9 months ago

#2334 closed defect (invalid)

regex capture with $1 not work in 1.20.0 but in 1.19.10

Reported by: rawbin-@… Owned by:
Priority: minor Milestone:
Component: documentation Version:
Keywords: Cc:
uname -a: Linux 5.10.75-79.358.amzn2.x86_64 #1 SMP Thu Nov 4 21:08:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.20.0
built by gcc 7.3.1 20180712 (Red Hat 7.3.1-13) (GCC)
built with OpenSSL 1.1.1g FIPS 21 Apr 2020
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --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=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'

Description (last modified by Maxim Dounin)

with the following rule:

	location ~*  ^/([^/]+)\/? {
                root /usr/share/nginx/html/;
                index index.html;
		try_files $uri $uri/ /$1/index.html;
        }

when access with http://mytest.server.com/myproject/browser/route/
path /browser/route/ does not exist which expected to to use /myproject/index.html

it works on my macOS with nginx 1.19.10(use /myproject/index.html expected) and not work on the server with nginx 1.20.0(used /index.html with empty capture expected capture "myproject" and use /myproject/index.html)

macOS works

nginx version: nginx/1.19.10
built by clang 13.0.0 (clang-1300.0.29.30)
built with OpenSSL 1.1.1m 14 Dec 2021
TLS SNI support enabled
configure arguments: --prefix=/opt/homebrew/Cellar/nginx-full/1.19.10 --with-http_ssl_module --with-pcre --with-ipv6 --sbin-path=/opt/homebrew/Cellar/nginx-full/1.19.10/bin/nginx --with-cc-opt='-I/opt/homebrew/include -I/opt/homebrew/opt/pcre/include -I/opt/homebrew/opt/openssl@1.1/include' --with-ld-opt='-L/opt/homebrew/lib -L/opt/homebrew/opt/pcre/lib -L/opt/homebrew/opt/openssl@1.1/lib' --conf-path=/opt/homebrew/etc/nginx/nginx.conf --pid-path=/opt/homebrew/var/run/nginx.pid --lock-path=/opt/homebrew/var/run/nginx.lock --http-client-body-temp-path=/opt/homebrew/var/run/nginx/client_body_temp --http-proxy-temp-path=/opt/homebrew/var/run/nginx/proxy_temp --http-fastcgi-temp-path=/opt/homebrew/var/run/nginx/fastcgi_temp --http-uwsgi-temp-path=/opt/homebrew/var/run/nginx/uwsgi_temp --http-scgi-temp-path=/opt/homebrew/var/run/nginx/scgi_temp --http-log-path=/opt/homebrew/var/log/nginx/access.log --error-log-path=/opt/homebrew/var/log/nginx/error.log --with-debug --add-module=/opt/homebrew/share/echo-nginx-module

Darwin 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:29:10 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T8101 arm64 arm64 MacBookPro17,1 Darwin

server env (not working) nginx 1.20.0

nginx version: nginx/1.20.0
built by gcc 7.3.1 20180712 (Red Hat 7.3.1-13) (GCC)
built with OpenSSL 1.1.1g FIPS 21 Apr 2020
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --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=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'

Linux 5.10.75-79.358.amzn2.x86_64 #1 SMP Thu Nov 4 21:08:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

which get capture with empty string (when with-debug)

the following rule works on the server nginx 1.20.0

location ~*  ^/(?<prefix>[^/]+)\/? {
                root /usr/share/nginx/html;
                index index.html;
                try_files $uri $uri/ /$prefix/index.html;
        }

Attachments (2)

iShot2022-03-15 11.16.04.png (79.2 KB ) - added by rawbin-@… 9 months ago.
rule prefix
iShot2022-03-15 11.19.17.png (68.8 KB ) - added by rawbin-@… 9 months ago.
rule $1

Download all attachments as: .zip

Change History (7)

by rawbin-@…, 9 months ago

rule prefix

comment:1 by rawbin-@…, 9 months ago

Description: modified (diff)

by rawbin-@…, 9 months ago

rule $1

comment:2 by rawbin-@…, 9 months ago

Description: modified (diff)

comment:3 by Maxim Dounin, 9 months ago

Description: modified (diff)

Both location blocks provided works fine here.

Note though that using numbered captures is error prone, because numbered captures are used from the last regular expression executed. For example, adding any rewrite directive to the first location block will break things, as the rewrite directive will use regular expressions, overwriting the $1 .. $9 variables. The fact that the second location block works for you when the first one doesn't likely indicate that this is exactly what happens in your case.

To further confirm what exactly breaks in your case, please provide full (yet minimal) nginx configuration which is not working. Output of nginx -T would be optimal.

comment:4 by rawbin-@…, 9 months ago

finally found the case, It seems that some detail was missing, and the non-capture group which expected to do nothing still rewrite the $1

location ~* /(?<prefix>[/]+)\/? {

root /usr/share/nginx/html;
index index.html;
#try_files $uri $uri/ /$1/index.html;
try_files $uri $uri/ /$prefix/index.html;
if ( $request_filename ~* .*\.(?:htm|html)$ ){ ## this line will rewrite the $1

add_header Cache-Control "private, no-store, no-cache, must-revalidate, proxy-revalidate";

}

}

comment:5 by Maxim Dounin, 9 months ago

Resolution: invalid
Status: newclosed

Thanks for confirming. That's exactly why using numbered captures is not recommended: the $1 .. $9 variables can be easily overwritten by executing other regular expressions.

It doesn't matter if there are any capturing groups in the regular expression, the $1 .. $9 variables always refer to the last match. If there were no capturing groups in the last matched regular expression, relevant variables will be empty.

Note: See TracTickets for help on using tickets.