| Summary: | ProxyPass regex destination is not recognized | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Alexandre Schaff <alexandre.schaff> |
| Component: | mod_proxy | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 2.4.37 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
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. |
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.