Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127943
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>
In-Reply-To: <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
Reply-To: erictnorris@gmail.com
Date: Mon, 7 Jul 2025 12:53:38 -0400
Message-ID: <CA+NMNO1e1vsz-3Yjj7iwUvJy9nkeunRFgPVvWMUXmHr_4PAy=w@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 Wed, Jul 2, 2025 at 11:48=E2=80=AFAM Eric Norris <eric.t.norris@gmail.co=
m> wrote:
>
> > Based on the feedback so far (I do plan on waiting for more responses
> > 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 separate
> > 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 methods
> > on my low(est)-level curl object" and the "I'd like to do basic HTTP
> > stuff with curl, without a library" crowds.
> >
> > Barring that, my preference would be 2, but I'd accept 1 just to have
> > 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 PSR7
> 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!