Bad side effect of (even unmatched) nested regex locations in regex locations with anonymous captures with try_files/alias

[Maxim Dounin]

Hello!

On Thu, Aug 02, 2012 at 05:59:40PM +0200, Christoph Schug wrote:

> On 2012-08-02 12:42, Maxim Dounin wrote:
> [...]
> >And this is why it's not recommended to use enumerated captures
> >except for very simple configurations (or "rewrite" directive,
> >where use of enumerated captures immediatly follows regexp
> >matching).  Use named captures instead and you'll be fine.
> 
> Thanks Maxim,
> 
> using named captures it exactly what I did. The question to me was
> more or less if the other configuration was intended to break. If
> that's the case, that this is mainly a documentation issue which
> should be added to either [1] or [2] (best with cross reference to
> each other).
> 
> [1] http://www.nginx.org/en/docs/http/ngx_http_core_module.html#alias
> [2]
> http://www.nginx.org/en/docs/http/ngx_http_core_module.html#location
> 
> The topic "named captures" is as far as I can see is only mentioned
> in [3]. It might be good to demonstrate its use in a wider context.
> While doing so, also a comment on the syntax might be great, as PCRE
> not always supported the Perl-style notation of "(?<name>)" [4].
> 
> [3] http://www.nginx.org/en/docs/http/ngx_http_core_module.html#server_name
> [4]
> http://vcs.pcre.org/viewvc/code/trunk/doc/pcre.txt?r1=91&r2=93#l3410

We have various details about the captures in general and the 
issue with enumerated captures discussed in an introduction 
article here:

http://nginx.org/en/docs/http/server_names.html#regex_names

Adding links to every directive which support variables and/or 
execute regular expressions might be a bit too verbose.

Maxim Dounin