Rowan, all, Thanks again for your comments. PHP8.2 is going to be feature freeze in exactly one month now and as the currently proposed improvements have not received any interest (and that's OK), I will put those aside for the moment and come back with a new approach that I hope will be better for the future release (8.3 ?)
However, about the new Curl URL API, I think it's still time to finalize the discussions and include it in the 8.2 release as it allows us to solve some potential security issues. What do you think ? Do you see any interest in adding the new CurlUrl class in PHP8.2 ? Again currently proposed implementation can be found here [1] and is waiting for your new comments. Pierrick [1] https://github.com/adoy/php-src/pull/1/files#diff-5bd329a70f563b5b6eded3b710514a4fac605329087a7bd118e40f80b9fc8ee3 Le dim. 19 juin 2022, à 09 h 55, Rowan Tommins <rowan.coll...@gmail.com> a écrit : > On 19 June 2022 03:53:17 BST, Pierrick Charron <pierr...@php.net> wrote: > > > >I hope you don't mind, I took some of your code from your "Enable > >strict_types checking for curl_setopt()" pull request [1] to do some test > >on introducing this but only on the OOP API. It's working very well [2]. > >Can I know why this PR was closed ? Any issues ? Or was it more because it > >was too much of a change for the procedural API ? > > While a few type errors there might be useful, it still feels a bit like > polishing a turd. > > I count about 180 different options that can be passed to curl_setopt. > Some of them are used by nearly every user of PHP, and some are for very > obscure niche uses. Many of them are useless on their own, and exist only > to tweak the behaviour of some other option, or need to be used in groups > like usernames and passwords. Others have unintuitive and unhelpful > defaults, that need to be overridden with a different option. The manual > page has long topped the league table for user comments, currently standing > at 102. It is simply not a practical design for what most users of PHP need. > > I think one way out of this mess is to start grouping options together, > and providing specific methods to set them, with named, type-safe > parameters. For instance, CurlHandle::setProxyOptions(string $url, ?string > $authUserName, ?string $authPassword, ...) and so on. > > If the long lists of parameters still feel a bit messy, we could go a step > further and make objects for building sets of options, with methods taking > short lists of genuinely dependent options, e.g. > CurlProxyOptions::setAuth(string $userName, string $password) and > CurlProxyOptions::disableAuth() > > Some of the options should be rethought in the process to make more sense > to PHP's common usage, rather than libcurl's. As just one example, enabling > CURLOPT_VERBOSE sends some debug information to stderr, but on a web server > that is normally a log file where it will be mixed in with other > information. To capture it instead you need to also set CURLOPT_STDERR, > which requires an open file handle. What most users *actually* want is for > that information to be available to them as a string after the request is > executed. > > Another thing that might be useful is some new factory methods that set > sensible defaults, like CurlHandle::createForHttp(string|CurlUrl $url, > string $method) > > If we can build these things on top of the existing CurlHandle, we can > release a few things first, and progressively add features. Rather than > having to decide which extension to use, users will still have access to > curl_setopt for things there isn't a nicer interface for yet. We can even > leave it in place as something like CurlHandle::setRawOption for when users > want fine control of the library, or some really obscure setting. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
