If we take this sample: RedirectMatch permanent ^/foo/?$ http://some.external.site/?var1=val1&var2=val2&var3=val3 and the URL entered is: http://first.site/foo/ the redirect is to: http://some.external.site/?var1=val1/foo/var2=val2/foo/var3=val3 Therefore, the & has extended to the whole text matched by the "left" regex, just like it does with "classic dialect" regex engines such as sed and vi. The same behavior has been observed with SetEnvIf and RewrireRule. Probably other modules are affected as well. This comes as quite a surprise given that Apache uses PCRE. I'd have expected $& to work, but not a plain ampersand. This is true of Apache 2.0.54 and also 2.2.9, installed by default on Centos/RHEL 4.x and 5.x respectively. But this also holds true for the Apache 2.2.x coming with the latest Debian (I don't remember the exact version) and Apache 2.2.14 on Gentoo. For coherency, I'd say that $& should replace & for this purpose, to be more inline with perl's regexes. But then it seems that Apache has behaved this way for quite a while (since 2.0.x times at least, I don't know for 1.3) and this change could break some setups...
This is an undocmented special case in ap_pregsub: & is an alias for $0. mod_rewrite doesn't implement the same special behaviour. I therefore agree that this is surprising and should be dropped. And introducing $& as alias for $0 is a good idea, too, because people may expect that from perl. Making this change in 2.4 should be no problem as long as it is documented somewhere.
Removed use of & in r904765
fixed in 2.4.1