map regex matching affects rewrite directive

[Pascal Jungblut]

Using a regex in the map directive changes the capture groups in a rewrite directive. This happens only if the regex in map is matched. A minimal exampe config:

http {
        map $http_accept_language $lang {
                default en;
                 ~(de) de;
        }
        server {
                server_name test.local
                listen 80;
                rewrite ^/(.*)$ http://example.com/$lang/$1 permanent;
        }
}

Expected:

$ curl -sI http://test.local/foo | grep Location
Location: http://example.com/en/foo
$ curl -H "Accept-Language: de" -sI http://test.local/foo | grep Location
Location: http://example.com/de/foo

Actual:

$ curl -sI http://test.local/foo | grep Location
Location: http://example.com/en/foo
$ curl -H "Accept-Language: de" -sI http://test.local/foo | grep Location
Location: http://example.com/de/de

If I leave out the parentheses in ~(de) de; (so it becomes ~de de;), $1 is simply empty:

$ curl -H "Accept-Language: de" -sI http://test.local/foo | grep Location
Location: http://example.com/de/

[Josh DeWald]

Per the docs, this seems to be by design:

​http://nginx.org/en/docs/http/ngx_http_map_module.html

"A regular expression can contain named and positional captures that can later be used in other directives along with the resulting variable."

[Maxim Dounin]

This case clearly shows that the current behaviour is bad, and should be fixed. While positional captures are clearly bad in most cases, but just a rewrite should be simple enough for them to work.

[claudeha@…]

It would be more useful IMO if the positional captures could be used within the map directive itself. Here's a silly example that could be achieved with other things, but just to show what I mean:

map $http_accept_language $myindex {
    default index.en.html;
    ~(.*) index.$1.html;
}

I ran into a case recently where it would have been very useful to have some regex with different numbers of matches replaced within a map directive ​http://serverfault.com/questions/769373/porting-rewritecond-query-string-from-apache2-to-nginx

[Maxim Dounin]

See also #1044.

[Maxim Dounin]

See also #1142.

[higuita]

the nginx docs should be clear that named captures should always be used to avoid problems. By not saying that, users will use positional captures until something breaks and wasting lots of time debugging a simple badly documented feature.

Simply point to named captures in the docs, give one example and everyone will start to use then. without it, people fallback to the simplest capture and fail at random times

[Maxim Dounin]

See also #1285.

[https://stackoverflow.com/users/1100117/higuita]

can someone change the component to documentation, as this is mostly a documentation bug

thanks

[Maxim Dounin]

See also #1498.

[Maxim Dounin]

See also #1934.

[edrandall@…]

This bug is classified as 'minor', but in our opinion it should be 'critical'.

Are named captures restricted to the same context in which they are used?
For example, if I were to use the same name ?<p1> for the first capture parameter in several places, would I also run into the same issues when using $p1 as if I'd used $1?

The documentation very clearly uses numbered positional parameters in regex examples, which encourages developers to fall victim to this bug.

For example: ​http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite