args and rewrite vars always empty

User user24 at
Fri May 24 10:43:35 UTC 2019

On 5/24/19 9:50 AM, Maxim Dounin wrote:
> The first line shows actual matching - regular expression itself
> and the string it matches, and the second one shows the result. 
> The above two lines were obtained with the following trivial
> configuration:

Yes, thanks. I clearly understand it all. I know how regex work and $1
expected result must be directory name. My "rewrite_log on" logs
attached at the first message. It's almost the save server {}
configuration. Currently:

server {
  listen SERVERIP:80;
  error_log  /var/log/nginx/ notice;
  access_log off;
  rewrite_log on;
  index index.php;
  root /home/user/;

  location /product/ {
   rewrite ^/product/(.*)/$ /$1/$2/$3/$0/end.txt last;


Look at this! My little investigation. I try to find where $1 is lost
and for this purposes added other possible variables $0 $2 $3 from
regex. And what I see? $0 is not empty and guess what?  Seems that it
contain some of my root user command from shell. All other variables are
empty as I wrote at the first post.

Logs: ( for request url )

2019/05/24 10:16:23 [notice] 7030#7030: *39639 "^/product/(.*)/$"
matches "/product/moon/", client:, server:, request:
"GET /product/moon/?xxxx=yes HTTP/1.1", host: ""
2019/05/24 10:16:23 [notice] 7030#7030: *39639 rewritten data:
"////./", args: "xxxx=yes", client:, server:, request: "GET /product/moon/?xxxx=yes HTTP/1.1", host:

Looks like that nginx execute preg_match (regex) at bash shell(?) and
get results from it and they are wrong for unknown reason.....

"./" is one of my scripts that I run from root user manually. I

don't even have any idea why nginx add it to $0 variable from regex.

P.S. Sorry, previously send this message to your email directly not to

And I found that yes, nginx not build with pcre library, but seems it
execute it at the shell each time:

And it return not expected results for some reasons.

More information about the nginx mailing list