Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125914
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO16_p1=vmjpKSfWgSVCVqgxC0v-VGgfX4H5RhfGNNpSvg@mail.gmail.com>
 <6e533102b9a2e9c8f6a2183440b2601a@bastelstu.be> <CA+NMNO3rNd3vDth_0n6MOEdDorfHZXGymQXnk_ehwM=htvLeyQ@mail.gmail.com>
 <cd7343897b0a92d43c82062a49520fa5@bastelstu.be> <CA+NMNO0HVQAXkzcyYPjuF0KQBs-=1DE0-Bki2w0KXPUmvfjovA@mail.gmail.com>
 <9dd47a928fd4dc673a137c6433cd3130@bastelstu.be>
In-Reply-To: <9dd47a928fd4dc673a137c6433cd3130@bastelstu.be>
Reply-To: erictnorris@gmail.com
Date: Tue, 5 Nov 2024 14:35:12 -0500
Message-ID: <CA+NMNO39aqeq5dAzb5gZsec+gLZNpBMbgTN8fLXj56gZ2o6GVg@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Add persistent curl share handles
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: eric.t.norris@gmail.com (Eric Norris)

> > That said, as I mentioned above I would be fine with removing cookie
> > jar persistence if that was necessary to secure a passing vote, since
> > it's not our primary focus.
>
> Given the information regarding the TLS re-use, the cookie sharing is my
> only remaining concern. In fact with cookie sharing disabled it might
> not even be necessary for the user to choose an ID: Given that libcurl
> does the heavy lifting, as a user I should only need a single share
> handle and let libcurl figure out the details, no? A boolean =E2=80=9Csha=
re
> connections across requests=E2=80=9D when initializing a CurlHandle shoul=
d
> probably sufficient.

I realized I completely forgot to respond to this point. I had
actually considered this when you first mentioned that you did not
like choosable persistent IDs, but I think we'd need to consider how
this would interact with CURLOPT_MAXCONNECTS. A single shared handle
would mean a user couldn't create separate connection pools, and so it
may cause churn if the pool size wasn't large enough.

I don't think that's an insurmountable problem, however. I will raise
that as a part of a v2 discussion attempt if this fails to pass.