Re: regression with forward proxy due to Revision 1912459

Yann Ylavic <[email protected]>
Newsgroups gmane.comp.apache.devel
Message-ID <CAKQ1sVPP2io7n_mftorr-DLNetakQn2-caDrb7bKT+2acfod=Q@mail.gmail.com>
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?

>
> Regards;
> Yann.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.