Re: regression with forward proxy due to Revision 1912459

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 <[email protected]> wrote:
>>>
>>> On Mon, May 19, 2025 at 5:47 PM Ruediger Pluem <[email protected]> wrote:
>>>>
>>>> On 5/19/25 5:27 PM, Yann Ylavic wrote:
>>>>> On Mon, May 19, 2025 at 4:54 PM Stefan Eissing via dev
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>>> Am 19.05.2025 um 16:46 schrieb Yann Ylavic <[email protected]>:
>>>>>>>
>>>>>>>
>>>>>>> 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>