Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127789
Content-Type: multipart/signed;
	boundary="Apple-Mail=_6BE8A42D-D57E-42DD-8AE1-95A7F8283D33";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Date: Sun, 29 Jun 2025 19:47:00 -0500
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>
To: php internals <internals@lists.php.net>
In-Reply-To: <ab051ed8-8961-4074-b5e7-2abbfd272ef4@app.fastmail.com>
Message-ID: <87DC9AA0-52DB-4DA8-A1DC-1940B0051185@php.net>
From: ramsey@php.net (Ben Ramsey)


--Apple-Mail=_6BE8A42D-D57E-42DD-8AE1-95A7F8283D33
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jun 28, 2025, at 00:01, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Fri, Jun 27, 2025, at 4:58 PM, Ayesh Karunaratne wrote:
>=20
>> However, I softly oppose this RFC in its current state and the way it
>> seems to be going.
>=20
> So I think we've identified a key disagreement about not just the =
goal, but the intent.  To what extent should PHP core ship with a usable =
HTTP client?
>=20
> Right now it ships with Curl, which... in its current form is not =
usable.  It's a low-level tool with an inscrutable API we inherited from =
C.  It's not viable as a user-facing tool.  It's a tool that's only =
useful to people writing client libraries like Guzzle or CurlClass or =
Symfony HTTP or such.
>=20
> On the one hand, Marco is correct that for a web-centric language to =
not ship with a non-sucky way to send web requests is... kinda =
embarrassing.  Even if the use cases where you can't install a 3rd party =
library are few, they are non-zero.  And that also doesn't help new =
users figure out what to use.  (Eg, the person who wrote most of the =
code for our main application at work, learning PHP as he went, is =
sending lots of requests using... an ungodly mess of curl that can't =
even understand.  Because he didn't know that things like Guzzle even =
existed.)
>=20
> On the other hand, Ben is correct that an HTTP client is a not-small =
task, with a very deep rabbit hole.
>=20
> So there's two closely related but distinct asks here:
>=20
> 1. Make working with curl suck less (giving it an OOP interface is =
part of that but not all)
> 2. Ship a useful first-party HTTP client that can handle the 80% case, =
even if it's not full featured.
>=20
> Beefing up Curl's interface until it fulfills part 2 is one approach, =
but not the only.
>=20
> At one extreme would be the "do nothing, status quo is fine" position. =
 Ayesh seems to be close to that position, maybe with a little polish =
for funsies.  The other extreme would essentially be "Guzzle in core," =
which I don't think anyone is advocating.  Where between those extremes =
we should land is debatable.
>=20
> Personally I'm of the mind that a simple, basic-features HTTP client =
in core would be a good thing; that's central enough that it should not =
be left to userland.  It doesn't need to offer every possible feature; =
no need for async multiplexing, for example.  But sending GET and POST =
requests with straightforward bodies should be table-stakes for a web =
language, and right now, that's a second class citizen.  If it's written =
in such a way that it can be extended easily in user-space, so much the =
better.
>=20
> Whether that basic-features client is Curl itself or a bundled wrapper =
that uses Curl, I have no strong preference.  The challenge of making it =
separate from Curl is, shocker, that it's bikeshed bait.  Does that =
imply using the new URL/URI classes?  Does it imply we need =
request/response objects?  The rabbit hole indeed gets deep fast.
>=20
> So the first question, I think, is what is the consensus between these =
three coarse-grained positions:
>=20
> 1. Status quo is fine. PHP core not having a user-friendly way to send =
HTTP requests is acceptable. Maybe make Curl a little nicer, but only to =
make life easier for Guzzle et al.
> 2. We should develop the Curl API until it's usable for basic HTTP =
behavior, but no further.
> 3. We should bundle an HTTP client that wraps Curl (with or without =
minor improvements to Curl), exact scope TBD.
>=20
> Personally, I'm open to either 2 or 3.  3 is more bikesheddable, but =
possibly the better end result.
>=20
> Where does everyone else stand?
>=20
> --Larry Garfield


I=E2=80=99m also open to 2 or 3, but 3 sounds more like something that I =
think should live in userland, so I lean much more towards 2.

Cheers,
Ben


--Apple-Mail=_6BE8A42D-D57E-42DD-8AE1-95A7F8283D33
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCaGHehAAKCRCwLZeYnIwH
G14RAP9hx1pR0S0Kxo2cPudyoiQQFxHRbBplnssEiWnLhECqcwD/a/DSpiDBVD8n
00Kd4nYg9nESm+9UbM+x3VgEnpsVjpQ=
=4MDd
-----END PGP SIGNATURE-----

--Apple-Mail=_6BE8A42D-D57E-42DD-8AE1-95A7F8283D33--