Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118007
MIME-Version: 1.0
References: <CAOfKkdRzoo7JuD07F8nkZBYvS5eDMiV2r6cNV-FgeLxBrdCsiQ@mail.gmail.com>
 <CAESVnVpzqT0xtEShqQp+FPXt2DQjeAXpkSVZTACAC0CW=8FBBg@mail.gmail.com>
 <CAOfKkdTu1f6jJ2HwGjOnBR2sO6P6qdOrjH1ZzumwLzf1syXa6Q@mail.gmail.com> <76FA5161-16C3-4570-9EF8-B75DF2E6530A@gmail.com>
In-Reply-To: <76FA5161-16C3-4570-9EF8-B75DF2E6530A@gmail.com>
Date: Mon, 20 Jun 2022 09:13:48 -0400
Message-ID: <CAOfKkdQGX5Lf5-jKyKnh5im9YYd-pKPx=AxnLgk9=tBoJ37E9Q@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008caf8c05e1e0e066"
Subject: Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
From: pierrick@php.net (Pierrick Charron)

--0000000000008caf8c05e1e0e066
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 for the
future release (8.3 ?)

However, 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.

What do you think ? Do you see any interest in adding the new CurlUrl class
in PHP8.2 ? Again currently proposed implementation can be found here [1]
and is waiting for your new comments.

Pierrick

[1]
https://github.com/adoy/php-src/pull/1/files#diff-5bd329a70f563b5b6eded3b71=
0514a4fac605329087a7bd118e40f80b9fc8ee3


Le dim. 19 juin 2022, =C3=A0 09 h 55, Rowan Tommins <rowan.collins@gmail.co=
m> a
=C3=A9crit :

> On 19 June 2022 03:53:17 BST, Pierrick Charron <pierrick@php.net> 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 tes=
t
> >on introducing this but only on the OOP API. It's working very well [2].
> >Can I know why this PR was closed ? Any issues ? Or was it more because =
it
> >was too much of a change for the procedural API ?
>
> While a few type errors there might be useful, it still feels a bit like
> polishing a turd.
>
> I count about 180 different options that can be passed to curl_setopt.
> Some of them are used by nearly every user of PHP, and some are for very
> obscure niche uses. Many of them are useless on their own, and exist only
> to tweak the behaviour of some other option, or need to be used in groups
> like usernames and passwords. Others have unintuitive and unhelpful
> defaults, that need to be overridden with a different option. The manual
> page has long topped the league table for user comments, currently standi=
ng
> at 102. It is simply not a practical design for what most users of PHP ne=
ed.
>
> I think one way out of this mess is to start grouping options together,
> and providing specific methods to set them, with named, type-safe
> parameters. For instance, CurlHandle::setProxyOptions(string $url, ?strin=
g
> $authUserName, ?string $authPassword, ...) and so on.
>
> If the long lists of parameters still feel a bit messy, we could go a ste=
p
> further and make objects for building sets of options, with methods takin=
g
> short lists of genuinely dependent options, e.g.
> CurlProxyOptions::setAuth(string $userName, string $password) and
> CurlProxyOptions::disableAuth()
>
> Some of the options should be rethought in the process to make more sense
> to PHP's common usage, rather than libcurl's. As just one example, enabli=
ng
> CURLOPT_VERBOSE sends some debug information to stderr, but on a web serv=
er
> that is normally a log file where it will be mixed in with other
> information. To capture it instead you need to also set CURLOPT_STDERR,
> which requires an open file handle. What most users *actually* want is fo=
r
> that information to be available to them as a string after the request is
> executed.
>
> Another thing that might be useful is some new factory methods that set
> sensible defaults, like CurlHandle::createForHttp(string|CurlUrl $url,
> string $method)
>
> If we can build these things on top of the existing CurlHandle, we can
> release a few things first, and progressively add features. Rather than
> having to decide which extension to use, users will still have access to
> curl_setopt for things there isn't a nicer interface for yet. We can even
> leave it in place as something like CurlHandle::setRawOption for when use=
rs
> want fine control of the library, or some really obscure setting.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000008caf8c05e1e0e066--