Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127839
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 02 Jul 2025 11:06:53 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <544f5bea-bda9-438c-9355-68ee1aedd9ac@app.fastmail.com>
In-Reply-To: 
 <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
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>
 <CA+NMNO1G2v=PBV8L9ZZdeQJfSgRR+N6tKr7P0cpUiHGn=qZv1A@mail.gmail.com>
 <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 2, 2025, at 10:48 AM, Eric Norris wrote:
>> Based on the feedback so far (I do plan on waiting for more responses
>> to your email), and on my own preferences, I wonder if there is a
>> hybrid option I could propose. Perhaps the RFC could offer both a
>> \Curl\Handle (tentative name) to address position 1, and a
>> \Curl\BasicHttpHandle (also tentative name) that addresses position 2?
>> If people were amenable, I'd even make the BasicHttpHandle a separate
>> vote.
>>
>> I agree that 3 is both more bikesheddable and also possibly ideal, but
>> I feel my above suggestion maybe strikes the right balance between the
>> "status quo is fine, I don't want to see random HTTP-related methods
>> on my low(est)-level curl object" and the "I'd like to do basic HTTP
>> stuff with curl, without a library" crowds.
>>
>> Barring that, my preference would be 2, but I'd accept 1 just to have
>> it pass - like I mentioned elsewhere, I think there is value in
>> introducing namespaces and object-oriented APIs for "modernization"
>> and language consistency reasons.
>
> Having thought about this some more, while I'm still feeling somewhat
> positive about my suggestion I'm just not sure it's the best way to
> proceed. I started to sketch what a BasicHttpHandle class would look
> like, and I'm stuck on how to get data about the response out of the
> class.
>
> Naively, we could have $response_status_code and $response_headers
> properties, and have the same fetch() and execute() methods I
> suggested elsewhere to get the response body. Alternatively, we could
> return a simple CurlHttpResponse object which contains all three
> properties in the fetch() and execute() implementations for the
> BasicHttpHandle class.
>
> Both of these are fine, but they would lock us out of being PSR7
> compatible. I think that people would probably desire PSR7
> compatibility, and I would feel uncomfortable with eliminating or
> tainting the possibility of achieving this. For example, if we had
> this BasicHttpHandle and then later introduced PSR7 response objects,
> we'd need to either break backwards compatibility for the class, or
> introduce a second class. We could also go straight to returning a
> PSR7 compatible response for the BasicHttpHandle class, but I think
> that likely deserves its own RFC.
>
> So in closing, if people felt generally okay with the limitation of
> not being PSR7 compatible, I'd probably still add some form of my
> BasicHttpHandle suggestion as a secondary vote. If people thought PSR7
> was necessary, I'd drop it, and leave a PSR7-in-core RFC for the
> future. In that case, I'd go with Larry's option 1 for the RFC; I've
> currently updated the RFC to match that option for now.

The question of PHP-native request/response objects has come up a couple of times, and even had an RFC that went to a vote (declined).  My stance has been, and remains, that such objects do NOT need to match PSR-7... but they should be powerful enough to effectively replace/displace PSR-7.  If it's just another backend that PSR-7 consumes, we've added very little to the ecosystem.  If they're robust enough that they can replace PSR-7 and HttpFoundation in time, we've helped to standardize the ecosystem.  (And FIG will be able to adapt, don't worry.)

(Eg, I would strongly recommend leveraging properties instead of methods for any built-in objects, which didn't exist when PSR-7 was written but now so; we should absolutely use the new built-in URI/URL classes instead of user-space ones, etc.)

Of course, as you can expect, "design and include request/response objects powerful enough to supplant PSR-7" is a non-small and highly bikesheddable topic, and PHP is notoriously structurally bad at being able to have those conversations.  That's part of why it's never happened.

--Larry Garfield