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
