On 5/19/25 9:05 PM, Ruediger Pluem wrote:
On 5/19/25 8:13 PM, Yann Ylavic wrote:
On Mon, May 19, 2025 at 7:42 PM Yann Ylavic <ylavic....@gmail.com> wrote:
On Mon, May 19, 2025 at 5:47 PM Ruediger Pluem <rpl...@apache.org> wrote:
On 5/19/25 5:27 PM, Yann Ylavic wrote:
On Mon, May 19, 2025 at 4:54 PM Stefan Eissing via dev
<dev@httpd.apache.org> wrote:
Am 19.05.2025 um 16:46 schrieb Yann Ylavic <ylavic....@gmail.com>:
Hm, r1912459 added this test to disable reuse for CONNECT connections
to ProxyRemote, because I thought that CONNECT requests were not
reusable.
Hmm, what kind of CONNECT connections are reusable? The common use case is a
TLS tunnel, I think. It would not work to reuse that.
I mean reusing the same TLS tunnel created with the target host
through the RemoteProxy, pushing more data/requests to it as they
come.
I think it's no different than reusing a TLS connection to some direct
backend, the same SSL* is used until it's shut down / closed (e.g.
forward_info mismatch).
Maybe I am lost now, but when the client uses us as a forward proxy and does a
CONNECT to us the CONNECT to a remote proxy cannot
be used any longer once the client shuts down the connection to us.
Yes but this is a case handled by mod_proxy_connect and there is no
way that connections created by mod_proxy_connect are reused, they
never go in the reslist, not using ap_proxy_determine_connection() or
ap_proxy_release_connection().
It could work fine if the client uses a different HTTP method that requires us
to do a CONNECT to the remote proxy. In this case
we could reuse the connection provided that host and port fit.
This is the ap_proxy_determine_connection() case, where the origin
server is to be connected through a ProxyRemote.
This happens in reverse proxy configurations too, and in this case
reusing the tunnel is useful because the target host/port is always
the same (I think Jean Frederic is having a use case like this given
the performance regression).
For a forward proxy configuration I don't think keeping the tunnel
alive is useful since the next request is likely for some other
target, maybe we should not reuse ProxyRemote connections for this
case only?
Actually connections attached to the "proxy:forward" worker are never
recycled so this last point is moot.
So I think we should be good by keeping conn->forward connections
alive (if not closed by other means) when the existing forward_info
still matches?
Sounds sensible as the cases where it does not make sense should trigger a
closure anyway.
Nevertheless I am keen to understand Jean Frederic's use case to see if it
matches what you outlined.
Regards
Rüdiger
Find the configuration I have used to reproduce the customer issue,
thanks for all explanations for far ;-)
--
Cheers
Jean-Frederic
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule http2_module modules/mod_http2.so
LoadModule proxy_http2_module modules/mod_proxy_http2.so
Listen 8443
<VirtualHost *:8443>
SSLEngine on
ServerName host14.example.com
SSLCertificateFile /home/jfclere/CERTS/host14.example.com/newcert.pem
SSLCertificateKeyFile /home/jfclere/CERTS/host14.example.com/newkey.txt.pem
ErrorLog logs/host14_ssl_error_log
TransferLog logs/host14_ssl_access_log
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
Protocols h2
H2Direct on
H2Upgrade on
ProxyPass /proxy h2://localhost:8443/proxyee
ProxyPassReverse /proxy h2://localhost:8443/proxyee
ProxyRemote * http://fproxy.example.com:8080/
</VirtualHost>
Timeout 600
ProxyTimeout 600
KeepAlive On
KeepAliveTimeout 300
<VirtualHost _default_:8443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
SSLEngine on
SSLCertificateFile /home/jfclere/CERTS/localhost/newcert.pem
SSLCertificateKeyFile /home/jfclere/CERTS/localhost/newkey.txt.pem
Protocols h2
H2MaxSessionStreams 5
</VirtualHost>
Listen 8080
<VirtualHost *:8080>
ErrorLog "logs/forerror_log"
LogLevel debug
ServerName fproxy.example.com
ProxyRequests on
AllowCONNECT 8443
</VirtualHost>
