> On Jun 28, 2025, at 00:01, Larry Garfield <la...@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
signature.asc
Description: Message signed with OpenPGP
