Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118198
Message-ID: <79b23d28-6f74-fcd3-3e8b-590252c237e6@gmail.com>
Date: Tue, 5 Jul 2022 11:58:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Content-Language: en-GB
To: internals@lists.php.net
References: <CAOfKkdR0cab4-rWdVpzGPtg8nraNBWLN3whe9xs2mAw5x1MVyw@mail.gmail.com>
In-Reply-To: <CAOfKkdR0cab4-rWdVpzGPtg8nraNBWLN3whe9xs2mAw5x1MVyw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Vote] New Curl URL API
From: rowan.collins@gmail.com (Rowan Tommins)

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]