Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128163
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <CANLbj-ppn+QtYij2uHXmNvbXckKzz84fkj6f-6iw_7wioFN0dA@mail.gmail.com>
 <ab051ed8-8961-4074-b5e7-2abbfd272ef4@app.fastmail.com> <CA+NMNO1G2v=PBV8L9ZZdeQJfSgRR+N6tKr7P0cpUiHGn=qZv1A@mail.gmail.com>
 <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
 <CA+NMNO1e1vsz-3Yjj7iwUvJy9nkeunRFgPVvWMUXmHr_4PAy=w@mail.gmail.com> <CA+NMNO0VM2MSFxz0zQSGjvHv7ek+Cy_N3u7KcWgkY58ZtH2N2w@mail.gmail.com>
In-Reply-To: <CA+NMNO0VM2MSFxz0zQSGjvHv7ek+Cy_N3u7KcWgkY58ZtH2N2w@mail.gmail.com>
Reply-To: erictnorris@gmail.com
Date: Mon, 21 Jul 2025 11:17:19 -0400
Message-ID: <CA+NMNO0nD6R+Fswq68rfN=up2c6Mf9LBb1WPhzRDHdbnFkAX_Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Cc: 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)

On Mon, Jul 21, 2025 at 10:47=E2=80=AFAM Eric Norris <eric.t.norris@gmail.c=
om> wrote:
>
> On Mon, Jul 7, 2025 at 12:53=E2=80=AFPM Eric Norris <eric.t.norris@gmail.=
com> wrote:
> >
> > On Wed, Jul 2, 2025 at 11:48=E2=80=AFAM Eric Norris <eric.t.norris@gmai=
l.com> wrote:
> > >
> > > > Based on the feedback so far (I do plan on waiting for more respons=
es
> > > > to your email), and on my own preferences, I wonder if there is a
> > > > hybrid option I could propose. Perhaps the RFC could offer both a
> > > > \Curl\Handle (tentative name) to address position 1, and a
> > > > \Curl\BasicHttpHandle (also tentative name) that addresses position=
 2?
> > > > If people were amenable, I'd even make the BasicHttpHandle a separa=
te
> > > > vote.
> > > >
> > > > I agree that 3 is both more bikesheddable and also possibly ideal, =
but
> > > > I feel my above suggestion maybe strikes the right balance between =
the
> > > > "status quo is fine, I don't want to see random HTTP-related method=
s
> > > > on my low(est)-level curl object" and the "I'd like to do basic HTT=
P
> > > > stuff with curl, without a library" crowds.
> > > >
> > > > Barring that, my preference would be 2, but I'd accept 1 just to ha=
ve
> > > > it pass - like I mentioned elsewhere, I think there is value in
> > > > introducing namespaces and object-oriented APIs for "modernization"
> > > > and language consistency reasons.
> > >
> > > Having thought about this some more, while I'm still feeling somewhat
> > > positive about my suggestion I'm just not sure it's the best way to
> > > proceed. I started to sketch what a BasicHttpHandle class would look
> > > like, and I'm stuck on how to get data about the response out of the
> > > class.
> > >
> > > Naively, we could have $response_status_code and $response_headers
> > > properties, and have the same fetch() and execute() methods I
> > > suggested elsewhere to get the response body. Alternatively, we could
> > > return a simple CurlHttpResponse object which contains all three
> > > properties in the fetch() and execute() implementations for the
> > > BasicHttpHandle class.
> > >
> > > Both of these are fine, but they would lock us out of being PSR7
> > > compatible. I think that people would probably desire PSR7
> > > compatibility, and I would feel uncomfortable with eliminating or
> > > tainting the possibility of achieving this. For example, if we had
> > > this BasicHttpHandle and then later introduced PSR7 response objects,
> > > we'd need to either break backwards compatibility for the class, or
> > > introduce a second class. We could also go straight to returning a
> > > PSR7 compatible response for the BasicHttpHandle class, but I think
> > > that likely deserves its own RFC.
> > >
> > > So in closing, if people felt generally okay with the limitation of
> > > not being PSR7 compatible, I'd probably still add some form of my
> > > BasicHttpHandle suggestion as a secondary vote. If people thought PSR=
7
> > > was necessary, I'd drop it, and leave a PSR7-in-core RFC for the
> > > future. In that case, I'd go with Larry's option 1 for the RFC; I've
> > > currently updated the RFC to match that option for now.
> >
> > Thanks Ben, Larry, and Paul for your responses to my suggestion for a
> > BasicHttpHandle class. After reflecting further, I have decided to
> > move this to the Future Scope section, as it feels weighty enough to
> > stand as its own RFC. I'd like to think about this a bit more, but I
> > will note that having a Request and Response interface in core would
> > greatly simplify the proposal for a simple curl-based HTTP client, so
> > I'd likely support any effort on that front.
> >
> > I've also updated the Curl\MultiHandle class proposal to account for
> > removing the CURLOPT_RETURNTRANSFER option.
> >
> > At this point I believe the RFC is in a semi-final state at this
> > point, barring any additional discussion. Thanks all for the feedback
> > so far!
>
> I'd like to bring this to a vote since discussion has died down, but I
> feel that I should implement the proposal before doing so. As always
> this is the hard part, and since I'm back from an extended break at
> work I will have less time to focus on this.
>
> I've mentioned this before, but if anyone would like to collaborate on
> the implementation, please reach out! Otherwise, I'll update this
> thread with a link to the implementation at some point in the future,
> give it a little more time for discussion, and bring the proposal to a
> vote.

Apologies, quick clarification: I do not intend to target PHP 8.5, and
will update the RFC to note this.