On Sat, 28 Jun 2025 at 08:03, 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 think #2 is the way to go. I personally just use Symfony's HTTP Client 99.9% of the time - there is one exception in recent years where I had to go low-level cURL and craft an extremely specific HTTP request. Yes, it is a SOAP service for a government system, because of course it is. I'm not even sure it's a good idea to add those namespaced options: using > CURLOPT_SSL_VERIFYHOST is perfect to find the corresponding curl > documentation with your favorite search engine. php's doc is awesome, but > it cannot compete with the details provided by curl's doc on the topic. Valid. This cannot be avoided if any kind of RFC is to be accepted, so I think the next best solution is to put effort into documentation and ensure that things are referenced (like the new Enum options having very obvious links to the original constants and to the curl documentation), making discoverability easy. The good thing is that OOP API is purely new, so there is not going to be tons of old content about it to make things messy. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
