I'm facing the problem that I have to use ProxyPassReverse inside a <LocationMatch> container, which is not really supported as documented in the last paragrpah at http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse
I find the 'workaround' mentioned in the docs quite useless: "The same occurs inside a <LocationMatch> section, but will probably not work as intended, as ProxyPassReverse will interpret the regexp literally as a path; if needed in this situation, specify the ProxyPassReverse outside the section, or in a separate <Location> section." How is this supposed to help me when facing such a situation ? If I need to have ProxyPassReverse understand a regex then it will not do so just because I placed it outside of the <LocationMatch> container since it *always* understands the path argument as literal string - or did I miss anyhing when looking at the ProxyPassReverse code ? In my concrete situation I have a <LocationMatch> container with a negative lookahead which I need to have ProxyPassReverse understand somehow. I'm thinking of patching ProxyPassReverse using the ProxyPassMatch code so it understands regexps correctly. However, this has surely been considered before and I'm wondering why it was not put in - after all similar code exists for ProxyPassMatch. Are there pitfalls which I haven't seen yet ? Some time ago I dig into some issues I had with using directives inside a <LocationMatch> container instead of a <Location> container. I remember being told in IRC <LocationMatch> behaves less like a <Location> and more like a <Directory> internally. Might this be connected to 'ProxyPassReverseMatch' not existing ? Cheers, Thomas
