Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127790
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <ab051ed8-8961-4074-b5e7-2abbfd272ef4@app.fastmail.com>
Date: Mon, 30 Jun 2025 10:06:06 +0300
Message-ID: <CAL0xaBHk1Vy2g5qctnmuayhtb5ikoub_qtkp7zk6vN4dAQfiQA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008f50950638c4ab7c"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--0000000000008f50950638c4ab7c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 28 Jun 2025 at 08:03, 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 peop=
le
> 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 o=
f
> 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 ne=
ed
> for async multiplexing, for example.  But sending GET and POST requests
> with straightforward bodies should be table-stakes for a web language, an=
d
> 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.
--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--0000000000008f50950638c4ab7c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, 28 Jun 2025 at 08:03, Larry Garfi=
eld &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a=
>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 27, 2025, at 4:58 PM,=
 Ayesh Karunaratne wrote:<br>
<br>
&gt; However, I softly oppose this RFC in its current state and the way it<=
br>
&gt; seems to be going.<br>
<br>
So I think we&#39;ve identified a key disagreement about not just the goal,=
 but the intent.=C2=A0 To what extent should PHP core ship with a usable HT=
TP client?<br>
<br>
Right now it ships with Curl, which... in its current form is not usable.=
=C2=A0 It&#39;s a low-level tool with an inscrutable API we inherited from =
C.=C2=A0 It&#39;s not viable as a user-facing tool.=C2=A0 It&#39;s a tool t=
hat&#39;s only useful to people writing client libraries like Guzzle or Cur=
lClass or Symfony HTTP or such.<br>
<br>
On the one hand, Marco is correct that for a web-centric language to not sh=
ip with a non-sucky way to send web requests is... kinda embarrassing.=C2=
=A0 Even if the use cases where you can&#39;t install a 3rd party library a=
re few, they are non-zero.=C2=A0 And that also doesn&#39;t help new users f=
igure out what to use.=C2=A0 (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&#39;t even understand.=
=C2=A0 Because he didn&#39;t know that things like Guzzle even existed.)<br=
>
<br>
On the other hand, Ben is correct that an HTTP client is a not-small task, =
with a very deep rabbit hole.<br>
<br>
So there&#39;s two closely related but distinct asks here:<br>
<br>
1. Make working with curl suck less (giving it an OOP interface is part of =
that but not all)<br>
2. Ship a useful first-party HTTP client that can handle the 80% case, even=
 if it&#39;s not full featured.<br>
<br>
Beefing up Curl&#39;s interface until it fulfills part 2 is one approach, b=
ut not the only.<br>
<br>
At one extreme would be the &quot;do nothing, status quo is fine&quot; posi=
tion.=C2=A0 Ayesh seems to be close to that position, maybe with a little p=
olish for funsies.=C2=A0 The other extreme would essentially be &quot;Guzzl=
e in core,&quot; which I don&#39;t think anyone is advocating.=C2=A0 Where =
between those extremes we should land is debatable.<br>
<br>
Personally I&#39;m of the mind that a simple, basic-features HTTP client in=
 core would be a good thing; that&#39;s central enough that it should not b=
e left to userland.=C2=A0 It doesn&#39;t need to offer every possible featu=
re; no need for async multiplexing, for example.=C2=A0 But sending GET and =
POST requests with straightforward bodies should be table-stakes for a web =
language, and right now, that&#39;s a second class citizen.=C2=A0 If it&#39=
;s written in such a way that it can be extended easily in user-space, so m=
uch the better.<br>
<br>
Whether that basic-features client is Curl itself or a bundled wrapper that=
 uses Curl, I have no strong preference.=C2=A0 The challenge of making it s=
eparate from Curl is, shocker, that it&#39;s bikeshed bait.=C2=A0 Does that=
 imply using the new URL/URI classes?=C2=A0 Does it imply we need request/r=
esponse objects?=C2=A0 The rabbit hole indeed gets deep fast.<br>
<br>
So the first question, I think, is what is the consensus between these thre=
e coarse-grained positions:<br>
<br>
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 l=
ife easier for Guzzle et al.<br>
2. We should develop the Curl API until it&#39;s usable for basic HTTP beha=
vior, but no further.<br>
3. We should bundle an HTTP client that wraps Curl (with or without minor i=
mprovements to Curl), exact scope TBD.<br>
<br>
Personally, I&#39;m open to either 2 or 3.=C2=A0 3 is more bikesheddable, b=
ut possibly the better end result.<br>
<br>
Where does everyone else stand?<br>
<br>
--Larry Garfield<br>
</blockquote></div><div><br clear=3D"all"></div><div>I think #2 is the way =
to go. I personally just use Symfony&#39;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.</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">=C2=A0I&#39;m not even sure it&#39;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&#39;s doc is awesome, but it cannot compete with the det=
ails provided by curl&#39;s doc on the topic.</blockquote><div><br></div><d=
iv>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 ensur=
e that things are referenced (like the new Enum options having very obvious=
 links to the original constants and to the curl documentation), making dis=
coverability easy.</div><div>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 mes=
sy.</div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"l=
tr" class=3D"gmail_signature"><div dir=3D"ltr"><div><br></div>Arv=C4=ABds G=
odjuks<div>+371 26 851 664</div><div><a href=3D"mailto:arvids.godjuks@gmail=
.com" target=3D"_blank">arvids.godjuks@gmail.com</a></div><div>Telegram: @p=
sihius=C2=A0<a href=3D"https://t.me/psihius" target=3D"_blank">https://t.me=
/psihius</a></div></div></div></div>

--0000000000008f50950638c4ab7c--