ProxyPass can get its first argument (the path) from a wrapping Location block. ProxyPassMatch can get its first argument (the regex) from a wrapping LocationMatch (or Location ~, which I won't mention again) block. The ProxyPass docs are pretty clear about the first case. They don't really mention the second case, and also don't describe what happens if you mix and don't match - in particular, a ProxyPass within LocationMatch is probably not going to do what the user hopes. And also, ProxyPassReverse is only discussed in the context of Location. For any who wonder - my understanding is that when these directives are used inside a Location or LocationMatch block, the argument to the block is used verbatim as the argument to the directive. When one is expecting a regex and the other a path, results may be surprising, but httpd will not complain about the syntax. I propose changes to three sections: 1) http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass Mention that if you're trying to put this inside LocationMatch, you probably want the ProxyPassMatch directive instead. 2) http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch Explain that inside LocationMatch, the first argument comes from the block. Currently the syntax marks the regex as optional, while not explaining where it would come from. 3) http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreverse Explain that inside Location or LocationMatch, the first argument comes from the block, and that this is probably not desirable inside LocationMatch (perhaps there should be a ProxyPassReverseMatch?).
Created attachment 26127 [details] Proposed patch for the mod_proxy docs Attaching proposed changes - would appreciate someone evaluating and applying it.
Thanks Luke -- committed and backported to 2.2.x in r1021471.