Yeah... The logic in not re-using a worker is that the pattern matching aspect made it both difficult and somewhat inconsistent due to the dynamic nature of the situation, hence the use of the "default" worker for these.
We now have the functionality to handle this, but it is still a performance hit and in most cases enablereuse should be disabled. But we still make that an admin decision, and I think that's still the right move. Cheers! > On Oct 6, 2022, at 11:32 AM, Eric Covener <cove...@gmail.com> wrote: > > On Thu, Oct 6, 2022 at 10:21 AM Stefan Eissing via dev > <dev@httpd.apache.org <mailto:dev@httpd.apache.org>> wrote: >> >> Friends of mod_proxy, I have a question: >> >> In <https://github.com/icing/mod_h2/issues/235> someone reported wrong >> connection reuse for a config like: >> >> ProxyPassMatch ^/(prod|dev)/([-a-z0-9]+)/(.*)$ h2://$2.internal/$1/$2/$3 >> enablereuse=on keepalive=on >> >> Leaving aside the issue that such a pattern is insecure due to the client >> influencing the hostname, the fact remains that mod_proxy_http2 will use a >> previous connection, even if the matched hostname is different. I replicated >> that, using "just" ports in a test case: >> >> ProxyPassMatch ^/h2proxy/([0-9]+)/(.*)$ h2c://127.0.0.1:$1/$2 enablereuse=on >> keepalive=on >> >> Then >> 1. /h2proxy/5002/hello.py >> 2. /h2proxy/5004/hello.py >> >> results in 2) re-using the connection of 1). The log file says for 2): >> >> [proxy:debug] proxy_util.c(2538): AH00942: H2C: has acquired connection for >> (127.0.0.1:80) >> [proxy:debug] proxy_util.c(2596): [remote 127.0.0.1:60121] AH00944: >> connecting h2c://127.0.0.1:5004/hello.py to 127.0.0.1:5004 >> [proxy:debug] proxy_util.c(2819): [remote 127.0.0.1:60121] AH00947: >> connected /hello.py to 127.0.0.1:5002 >> [proxy_http2:trace1] mod_proxy_http2.c(374): [remote 127.0.0.1:60121] H2: >> determined connect to 127.0.0.1:5002 >> [proxy:trace2] proxy_util.c(3101): H2C: reusing backend connection >> 127.0.0.1:60120<>127.0.0.1:5002 >> >> and that looks wrong. >> >> Question: do we have a bug or do we consider such ProxyPassMatch as broken >> and require at least enablereuse=off? > > I can't find all the history, but some time ago proxypassmatch never > tried to find a matching worker > https://bz.apache.org/bugzilla/show_bug.cgi?id=62167 > <https://bz.apache.org/bugzilla/show_bug.cgi?id=62167> > > Later, we must have gotten some logic added but you still have to > opt-in, I think it is likely > http://home.apache.org/~ylavic/patches/httpd-2.4.x-ap_proxy_define_match_worker.patch > > <http://home.apache.org/~ylavic/patches/httpd-2.4.x-ap_proxy_define_match_worker.patch> > or adjacent > > Not sure if it helps
