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

Reply via email to