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
