Re: [RFC] OOP API for cURL extension
| From: | Thomas Bley | Date: | Thu, 15 Feb 2024 10:15:04 +0000 |
| Subject: | Re: [RFC] OOP API for cURL extension | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122380@lists.php.net to get a copy of this message | ||
> Sara Golemon <pollita@php.net> hat am 14.02.2024 19:47 CET geschrieben:
>
>
> Good afternoon folks, I'd like to open discussion on adding OOP APIs to the cURL
> extension.
> https://wiki.php.net/rfc/curl-oop
>
> This has been a long standing bug-bear of mine, and I think its time has come.
>
> try {
> (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
> } catch (\CurlHandleException $ex) {
> assert(false); // Why not?!
> }
>
> -Sara
Thanks a lot for the rfc.
Regarding secure default options, I'd like to mention this article:
https://php.watch/articles/php-curl-security-hardening
Since CurlHandle::setOpt() no longer returns true on success, it would be good to have an example in
the RFC how error handling should be implemented in user land regarding setting invalid, deprecated
or unknown options (e..g. SSLVERSION received some changes over the years: https://curl.se/libcurl/c/CURLOPT_SSLVERSION.html).
Also I'd prefer to have class constants for the options, e.g. CURLOPT::TIMEOUT instead of
CURLOPT_TIMEOUT.
Static code analysis for curl_getinfo() is currently difficult to implement (see https://github.com/phpstan/phpstan-src/blob/1.11.x/src/Type/Php/CurlGetinfoFunctionDynamicReturnTypeExtension.php).
So I'd suggest adding sth.. like curl_getinfo_all():CurlInfo-Class if possible.
Maybe Ondrej also has some suggestions regarding a more object oriented version or
curl_setopt(CurlOption-Class)? (see https://github.com/phpstan/phpstan-src/blob/1.11.x/src/Reflection/ParametersAcceptorSelector.php#L562)
Regards
Thomas