Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125917
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> <CA+NMNO39aqeq5dAzb5gZsec+gLZNpBMbgTN8fLXj56gZ2o6GVg@mail.gmail.com>
In-Reply-To: <CA+NMNO39aqeq5dAzb5gZsec+gLZNpBMbgTN8fLXj56gZ2o6GVg@mail.gmail.com>
Date: Wed, 6 Nov 2024 11:03:29 +0000
Message-ID: <CABHuAWxBcgtfFbgjH0QLYLeYA7N4w9ycKkxiN5Ww+wd34cAhhw@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Add persistent curl share handles
To: erictnorris@gmail.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006f526206263c78fd"
From: t.carnage@gmail.com (Chris Riley)

--0000000000006f526206263c78fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 5 Nov 2024 at 19:35, Eric Norris <eric.t.norris@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 m=
y
> > 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=9Cs=
hare
> > connections across requests=E2=80=9D when initializing a CurlHandle sho=
uld
> > 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

--0000000000006f526206263c78fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, 5 Nov 2024 at 19:35, Eric Norris =
&lt;<a href=3D"mailto:eric.t.norris@gmail.com">eric.t.norris@gmail.com</a>&=
gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">&gt; &gt; That said, as I mentioned above I would be =
fine with removing cookie<br>
&gt; &gt; jar persistence if that was necessary to secure a passing vote, s=
ince<br>
&gt; &gt; it&#39;s not our primary focus.<br>
&gt;<br>
&gt; Given the information regarding the TLS re-use, the cookie sharing is =
my<br>
&gt; only remaining concern. In fact with cookie sharing disabled it might<=
br>
&gt; not even be necessary for the user to choose an ID: Given that libcurl=
<br>
&gt; does the heavy lifting, as a user I should only need a single share<br=
>
&gt; handle and let libcurl figure out the details, no? A boolean =E2=80=9C=
share<br>
&gt; connections across requests=E2=80=9D when initializing a CurlHandle sh=
ould<br>
&gt; probably sufficient.<br>
<br>
I realized I completely forgot to respond to this point. I had<br>
actually considered this when you first mentioned that you did not<br>
like choosable persistent IDs, but I think we&#39;d need to consider how<br=
>
this would interact with CURLOPT_MAXCONNECTS. A single shared handle<br>
would mean a user couldn&#39;t create separate connection pools, and so it<=
br>
may cause churn if the pool size wasn&#39;t large enough.<br>
I don&#39;t think that&#39;s an insurmountable problem, however. I will rai=
se<br>
that as a part of a v2 discussion attempt if this fails to pass.<br></block=
quote><div><br></div><div>I&#39;m also a bit late to this, but I&#39;m not =
convinced on the design myself either though from a different direction. To=
 me, persisting connections should be a deployment decision=C2=A0not a deve=
lopment decision; in order to use these new persistent connections I have t=
o change my code to opt into it, or I have to wait for the libraries I&#39;=
m using to do so. In reality, It&#39;d be much better if PHP could enable o=
r disable persistent connections globally, pools can then be tuned in php.i=
ni per environment. If you were excluding cookies from the store (a good ch=
oice as cookies are better handled at user land) and curl already handles S=
SL related differences, this behaviour can and should be transparent to the=
 calling code - reusing or creating a new connection shouldn&#39;t have any=
 impact on how the request/response is processed other than the speed at wh=
ich things happen.</div><div><br></div><div>~C</div></div></div>

--0000000000006f526206263c78fd--