Re: regression with forward proxy due to Revision 1912459

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