Within method add_pass from mod_proxy.c, there is a call to "apr_fnmatch_test" in order to determine if cmd->path is a pattern (a regex) or a prefix (filename). apr_fnmatch_test does not recognize "^" or "("...")" as a pattern. The sample from https://httpd.apache.org/docs/2.4/mod/core.html#locationmatch is thus not recognized. A conf like : <LocationMatch ^/(api|truc)/$> Require all granted ProxyPass http://127.0.0.1:1234/$1 ProxyPassReverse http://127.0.0.1:1234/$1 </LocationMatch> does not proxypass due to result from apr_fnmatch_test(). Changing regex to "^/(api|truc)/[\w]*$" changes result from apr_fnmatch_test() and proxypass applies. Note : apr_fnmatch_test() tests for a limited regex scope (posix's glob). I added a new apr function : apr_fnmatch_test_regex() new functions adds "^" and "(.*)" to be recognized as regex, it works as expected for the given use-case, and maybe can be applied to other places (not checked). Dear Apache devs, what would be a better correction ? br, Alexandre.
It probably should be ProxyPassMatch in this case, apr_fnmatch_test() is just a easy try to "fix" a ProxyPass, but there is no way to do that absolutely anyway (e.g. "/api" is a valid regex although it won't match the same if it's used as a path or a regex).
(In reply to Yann Ylavic from comment #1) > It probably should be ProxyPassMatch in this case, apr_fnmatch_test() is > just a easy try to "fix" a ProxyPass, but there is no way to do that > absolutely anyway (e.g. "/api" is a valid regex although it won't match the > same if it's used as a path or a regex). Thank you Yvan, this makes sense. Expecting ProxyPass to "fix more" is not the solution.