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