On 6/27/25 08:01, Deleu wrote:
With that said, for me this also threads into the bikeshedding area that could spiral into a failed RFC. Be it a single Enum for everything, constants, context-based enums or type-based enums, I would much rather have this RFC than not have it. PHP is one of the most important Web applications in the world and it severely lacks the ability to simplify Http. We could take inspiration from Python Requests [1] or Node Fetch [2] as a really simple and straightforward API that covers the vast majority of cases.
Python Requests and Node Fetch are simple and straightforward for users *because* they're not simple and straightforward to develop. A lot of care and detailed decisions have gone into those APIs to make them feel simple and straightforward when used. Python Requests[^1] is a massive third-party library that users install separately from Python. It also depends on urllib3[^2], another massive third-party library that serves as its underlying HTTP client. Node Fetch uses the WHATWG Fetch Living Standard[^3], which, again, is neither simple nor straightforward. It just feels that way when using it because they did a damn good job defining it. As I said earlier,[^4] this level of detail should live in userland. Arguably, as in the case of Fetch, something like this *could* live in core. There was an RFC over 10 years ago that proposed moving pecl_http into core.[^5] However, if we decide to go that route, I think it needs to be a much bigger undertaking, perhaps with a working group formed tohash out the details and design the API. I think it's better to let userland handle something like this, so core can focus on optimizations
that reduce the "if it's in C, it'll be faster" arguments.
I take the point that we don't need to go all the way and invent a RequestClient library in PHP and this RFC is threading on the small step of converting Curl procedural API into OOP, which is where Larry and Rowans recommendations about some minor helper methods go a really really long way compared to where we are today.
I'm fully on board with making the curl extension API easier to use. Let's clearly state the problem and use-case we're attempting to solve for and focus on a solution targeting that and nothing more (without limiting ourselves for future expansion, of course). Maybe after stating the problem clearly, we'll find it easier to build consensus on a solution. The RFC hints at type safety and converting the curl procedural API into OOP as motivating factors. I don't think these clearly state the problem we're trying to solve, so if they continue to be the motivating factors, this discussion is bound to continue into bikeshedding territory. Here are some of the more concrete things I've seen mentioned that hint at the problem: From Rowan:
But that long list is also exactly why we badly need helpers for common use cases - the manual page for curl_setopt has been at the top of the charts for number of user comments for years, because nobody wants to read the descriptions for two hundred options they'll never need.
From Marco:
perform basic HTTP requests in a friendly way
These are great starts. Solving for the documentation problem might not even require changes to the extension. We probably need to further define what is meant by "friendly," though. Otherwise, we'll find ourselves back at the bike shed.
So, what's the problem (from a user's perspective) this RFC solves? Cheers, Ben [^1]: https://github.com/psf/requests [^2]: https://github.com/urllib3/urllib3 [^3]: https://fetch.spec.whatwg.org [^4]: https://news-web.php.net/php.internals/127760 [^5]: https://wiki.php.net/rfc/pecl_http
OpenPGP_signature.asc
Description: OpenPGP digital signature
