Re: [PHP-DEV] [RFC][Vote] New Curl URL API
On 05/07/2022 00:34, Pierrick Charron wrote: I opened voting for the new Curl URL API as part of PHP8.2. https://wiki.php.net/rfc/curl-url-api All recent discussions show that we are not even close to getting a consensus on how the new CurlUrl OO API should be done. After changing my mind 300 times in the last day, I decided to only propose the procedural implementation that stays consistent with other functions of the ext/curl to target 8.2. I know this is not the ideal scenario, but with 8.2 feature freeze in two weeks, this is I think the only approach that will not put us in a potentially bad/harmful situation for a better future with ext/curl. I agree with others that rushing to a vote is not the best way to handle the situation here. We are now essentially voting on an RFC that has had zero discussion time, since it has been completely rewritten. I understand that you are keen to get this into a release because you see it as a security feature, but that's exactly why we need to be sure we have the right design. I'm also still not clear who will use this API and how it will improve their security. There seems to be a risk of people using these functions in the wrong way, or the wrong circumstances, and actually making their code less secure. Because of all of the above, I have cast a No vote, because I would rather the right implementation was delayed until PHP 8.3 than the wrong implementation rushed into PHP 8.2. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] New Curl URL API
> Hi internals, > > I opened voting for the new Curl URL API as part of PHP8.2. > > All recent discussions show that we are not even close to getting a > consensus on how the new CurlUrl OO API should be done. After changing my > mind 300 times in the last day, I decided to only propose the procedural > implementation that stays consistent with other functions of the ext/curl > to target 8.2. I fully support this approach: php-src is not the proper layer to build an OOP API to me. Each time it's been done, it proved too rigid for userland and ppl wrote wrappers around. I think php-src should continue to provide thin layers on top of C libraries so that userland is then empowered to build and evolve OOP APIs at will. Nicolas
Re: [PHP-DEV] [RFC][Vote] New Curl URL API
Sorry about that const CURLUPART_USER = UNKNOWN; // what UNKNOWN? > UNKNOWN means that the value here is not relevant for the user to know. But for clarification, the values of those constants will be the exact same values of the same constants in libcurl. "All errors of libcurl will become CurlUrlException." > You have a small section about CurlUrlException, but if you have for example a bad port when you set it a CurlUrlException will be thrown, with a CurlUrlException::BAD_PORT_NUMBER error code and a more user friendly message. > > "Setting a part to a null value will effectively remove that part's > contents", but the $content argument is of type string not ?string. > My bad. I took the liberty of fixing this even if the voting was open since I don't think it will change the actual 3 voters' vote. Pierrick
Re: [PHP-DEV] [RFC][Vote] New Curl URL API
Clear "no" from me on this: this is something similar to a PSR-7 URI object, but with a clunky and mutable API. Something like this would/should go to packagist first, to assess adoption there, but I would certainly not use it. On Tue, 5 Jul 2022, 01:34 Pierrick Charron, wrote: > Hi internals, > > I opened voting for the new Curl URL API as part of PHP8.2. > > All recent discussions show that we are not even close to getting a > consensus on how the new CurlUrl OO API should be done. After changing my > mind 300 times in the last day, I decided to only propose the procedural > implementation that stays consistent with other functions of the ext/curl > to target 8.2. I know this is not the ideal scenario, but with 8.2 feature > freeze in two weeks, this is I think the only approach that will not put us > in a potentially bad/harmful situation for a better future with ext/curl. > > The vote will last for 2 weeks and end on 19th of July. > > Regards > Pierrick >
Re: [PHP-DEV] [RFC][Vote] New Curl URL API
On 05.07.2022 01:34, Pierrick Charron wrote: Hi internals, I opened voting for the new Curl URL API as part of PHP8.2. I found some not clear fragments in the RFC. const CURLUPART_USER = UNKNOWN; // what UNKNOWN? "All errors of libcurl will become CurlUrlException." "Setting a part to a null value will effectively remove that part's contents", but the $content argument is of type string not ?string. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC][Vote] New Curl URL API
Hi internals, I opened voting for the new Curl URL API as part of PHP8.2. All recent discussions show that we are not even close to getting a consensus on how the new CurlUrl OO API should be done. After changing my mind 300 times in the last day, I decided to only propose the procedural implementation that stays consistent with other functions of the ext/curl to target 8.2. I know this is not the ideal scenario, but with 8.2 feature freeze in two weeks, this is I think the only approach that will not put us in a potentially bad/harmful situation for a better future with ext/curl. The vote will last for 2 weeks and end on 19th of July. Regards Pierrick
