> On Jun 28, 2025, at 00:01, Larry Garfield <larry@garfieldtech.com> wrote:
>
> On Fri, Jun 27, 2025, at 4:58 PM, Ayesh Karunaratne wrote:
>
>> However, I softly oppose this RFC in its current state and the way it
>> seems to be going.
>
> 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?
>
> 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.
>
> 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.)
>
> On the other hand, Ben is correct that an HTTP client is a not-small task, with a very deep
> rabbit hole.
>
> So there's two closely related but distinct asks here:
>
> 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.
>
> Beefing up Curl's interface until it fulfills part 2 is one approach, but not the only.
>
> 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.
>
> 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.
>
> 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.
>
> So the first question, I think, is what is the consensus between these three coarse-grained
> positions:
>
> 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.
>
> Personally, I'm open to either 2 or 3. 3 is more bikesheddable, but possibly the better
> end result.
>
> Where does everyone else stand?
>
> --Larry Garfield
I’m 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
Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc