>
>
> I haven't read back through the thread, but my impression was that *for
> the curl URL facility specifically* the opposite was the case: a simple
> object with no procedural equivalent would be everyone's preference.
> CurlFile provides enough of a precedent for adding that IMO.
>
+1
>
> E
On Sat, Jun 18, 2022 at 9:53 PM Pierrick Charron 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
On 20/06/2022 14:44, Christoph M. Becker wrote:
Given that designing a new OO API obviously isn't uncontroversial, and
that there are only four weeks left till feature freeze, it might be
best to go with a simple procedural API for PHP 8.2 only.
I haven't read back through the thread, but my i
On 20 Jun 2022, at 14:44, Christoph M. Becker wrote:
> On 20.06.2022 at 15:13, Pierrick Charron wrote:
>> 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.
>
> Given th
On 20.06.2022 at 15:13, Pierrick Charron wrote:
> 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
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 fo
On 19 June 2022 03:53:17 BST, Pierrick Charron 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 wa
Hi Sara
> This is so bizarre, I *know* I wrote an OOPified cURL extension some years
> ago (called it curli), and now I can't find it anywhere. What universe am
> I even in?
>
I don't know but if you pass through the parallel universe where Curli is,
I'm interested.
>
> Anyway, +1 on making a
Hi Rowan, all,
Thanks for your responses and comments.
> I think it's perfectly reasonable for CurlUrl to be designed the same way,
> regardless of what else we do with the extension.
>
As suggested by most of you, I created a new version of the proposed new
URL API with a friendlier interface
On Fri, Jun 17, 2022 at 6:14 PM Sara Golemon wrote:
>
> On Thu, Jun 16, 2022 at 2:10 AM Pierrick Charron wrote:
>
> > For a long time, ext/curl worked with handles as "curl resources" and
> > functions mapped to the libcurl functions, but since PHP8.0 "curl
> > resources" were converted to opaque
On Thu, Jun 16, 2022 at 2:10 AM Pierrick Charron wrote:
> For a long time, ext/curl worked with handles as "curl resources" and
> functions mapped to the libcurl functions, but since PHP8.0 "curl
> resources" were converted to opaque classes with no methods. So my main
> goal here is to come up w
Hi Pierrick,
On Thu, 16 Jun 2022 at 22:44, Pierrick Charron wrote:
> Is it OK to have one part
> that is a thin wrapper and another part that is a "remodeling" of the API ?
> (This is not a rhetorical question, I really ask myself the question).
>
I agree with others that the new API should b
Hi Lynn,
You have to be careful, even though most developers associate curl with an
http client and only use this feature, it's only part of what it is. It's
a multiprotocol file transfer library that supports DICT, FILE, FTP, FTPS,
GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP
On 17 Jun 2022, at 09:27, Lynn wrote:
> ... That said, we should avoid having: cURL procedural + cURL procedural in
> objects + cURL OOP. Having 2 different object based libraries to do the same
> thing PHP is confusing and will just end up in way too many Stack Overflow
> questions.
>
> Perha
Good timezone!
On Thu, Jun 16, 2022 at 11:44 PM Pierrick Charron wrote:
> About making a "Good OOP API", of course the goal is to make a *Good* OOP
> API. But there are things to take into consideration. The proposal here is
> yes to expose the new Curl URL API which is quite small, but also to
Thanks for taking the time to answer and give feedback, that's really
appreciated.
Firstly, about the procedural API, if everyone agrees that we should not
create it (and it looks like it) I will definitely not go against it. This
was just to make it consistent with the current ext/curl api. Readi
On Thu, Jun 16, 2022, at 2:10 AM, Pierrick Charron wrote:
> Hi internals,
>
> Since its version 6.62.0 [1], libcurl features a brand new URL API [2] that
> can be used to parse and generate URLs, using libcurl’s own parser. One of
> the goals of this API is to tighten a problematic vulnerable area
On 6/16/22 07:26, Robert Landers wrote:
On Thu, Jun 16, 2022 at 3:07 PM Kamil Tekiela wrote:
First of all, thank you for working on this. I wanted OO API for Curl for a
long time.
Exceptions all the way. Code that's not using exceptions is usually more
clunky and error-prone. The new OO API sh
On Thu, Jun 16, 2022 at 3:07 PM Kamil Tekiela wrote:
>
> First of all, thank you for working on this. I wanted OO API for Curl for a
> long time.
>
> Exceptions all the way. Code that's not using exceptions is usually more
> clunky and error-prone. The new OO API shouldn't have the possibility to
First of all, thank you for working on this. I wanted OO API for Curl for a
long time.
Exceptions all the way. Code that's not using exceptions is usually more
clunky and error-prone. The new OO API shouldn't have the possibility to
return null/false on error. This is considered a thing of the pas
Hi
On 6/16/22 09:10, Pierrick Charron wrote:
As of right now I still have some unanswered questions like how should we
handle errors on the new CurlUrl API ?
- Throw `CurlUrlException` on both the procedural and object oriented style
API (that's how current implementation works [5])
- Throw `Cur
On 16 June 2022 09:10:08 CEST, Pierrick Charron wrote:
> [...]
>- For consistency expose the new Curl URL API as functions mapped one to
>one to libcurl functions :
>
>function curl_url(?string $url = null): CurlUrl|false {}
>function curl_url_set(CurlUrl $url, int $part, string $content, int $fla
On Thu, Jun 16, 2022, 9:10 AM Pierrick Charron wrote:
> Hi internals,
>
> Since its version 6.62.0 [1], libcurl features a brand new URL API [2] that
> can be used to parse and generate URLs, using libcurl’s own parser. One of
> the goals of this API is to tighten a problematic vulnerable area fo
Hi internals,
Since its version 6.62.0 [1], libcurl features a brand new URL API [2] that
can be used to parse and generate URLs, using libcurl’s own parser. One of
the goals of this API is to tighten a problematic vulnerable area for
applications where the URL parser library would believe one thi
24 matches
Mail list logo
