On Tue, 5 Nov 2024 at 19:35, Eric Norris <eric.t.nor...@gmail.com> wrote:

> > > 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 “share
> > connections across requests” when initializing a CurlHandle should
> > 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.
>

I'm also a bit late to this, but I'm not convinced on the design myself
either though from a different direction. To me, persisting connections
should be a deployment decision not a development decision; in order to use
these new persistent connections I have to change my code to opt into it,
or I have to wait for the libraries I'm using to do so. In reality, It'd be
much better if PHP could enable or disable persistent connections globally,
pools can then be tuned in php.ini per environment. If you were excluding
cookies from the store (a good choice as cookies are better handled at user
land) and curl already handles SSL related differences, this behaviour can
and should be transparent to the calling code - reusing or creating a new
connection shouldn't have any impact on how the request/response is
processed other than the speed at which things happen.

~C

Reply via email to