Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][Vote] New Curl URL API »

[RFC][Vote] New Curl URL API

php.internals

Pierrick Charron

4 years ago
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

Pierrick Charron

4 years ago
Sorry, I forgot to include the RFC Url : https://wiki.php.net/rfc/curl-url-api Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron <pierrick@php.net> a écrit :

Mark Randall

4 years ago
On 05/07/2022 00:34, Pierrick Charron wrote:
> 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'm voting no on this one based on the discussions from R11. The deadline being close is not a good enough reason to rush a change like this that will be difficult to unwind later. I agree with some of the other comments made that it would be preferable to come up with a more generic solution that can be used by multiple components rather than something specific to Curl. Mark Randall

A.L.E.C

4 years ago
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

Pierrick Charron

4 years ago
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

Marco Pivetta

4 years ago
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, <pierrick@php.net> wrote:

Nicolas Grekas

4 years ago
> 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

Rowan Collins

4 years ago
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]

Pierrick Charron

4 years ago
Hi Internals, The RFC has been declined with a vote of 10 in favor and 14 against. Thank you for the votes. Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron <pierrick@php.net> a écrit :