Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118106
MIME-Version: 1.0
References: <CAOfKkdTjPiZHnSHuag_+fmFK-1Advh2-vfDgbJBXEmK=72NB0g@mail.gmail.com>
 <CABdc3WryiOY=3cMTdi+gVxbE+twi8ixJGtG9Gfa+4RfJQT5DhQ@mail.gmail.com>
In-Reply-To: <CABdc3WryiOY=3cMTdi+gVxbE+twi8ixJGtG9Gfa+4RfJQT5DhQ@mail.gmail.com>
Date: Mon, 27 Jun 2022 09:10:06 -0400
Message-ID: <CAOfKkdRv7OgCDt4Str3sP3Nsfqc3+F1r3OS80s+DDFFnidxy0A@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002fc02705e26da42d"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
From: pierrick@php.net (Pierrick Charron)

--0000000000002fc02705e26da42d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Micha=C5=82,

Thanks for your comments. You made me realise that the RFC missed
information on a crucial part which is the new CURLOPT_CURLU option that
tells curl to use the CurlUrl object instead of the "standard" CURLOPT_URL
option. I just added some information on it in the RFC.

The purpose of the CurlUrl class is to be able to build/see/modify an URL
as it is seen by libcurl before/after passing it to your CurlHandle. It is
not meant to be used alone as a representation of an URL.

For example, you may want to do some checks to make sure that the URL you
gave to your CurlHandle is well formatted and that the host or any other
parts are what you want them to be, and that it was not something else
because of some differences on how the URL was parsed. Or you may want to
add/delete/overwrite some parts to sanitize your URL. That's why you have
those setters/getters. This class is definitively not there to replace
PSR-7 UriInterface. I can imagine some Guzzle or other implementation to
build a CurlUrl handle from a UriInterface before giving it to curl.

So this RFC is really targeted to users of curl_* functions.

Le lun. 27 juin 2022, =C3=A0 02 h 29, Micha=C5=82 Marcin Brzuchalski <
michal.brzuchalski@gmail.com> a =C3=A9crit :

> Hi Pierrick
>
> =C5=9Br., 22 cze 2022 o 06:38 Pierrick Charron <pierrick@php.net> napisa=
=C5=82(a):
>
>> Hi,
>>
>> Following our discussions we had on the subject of the new Curl URL API,
>> and other curl improvements. I decided to only focus on adding the new
>> Curl
>> URL API and put aside all other improvements. Here is the RFC that
>> reflects
>> our current conversations.
>>
>> https://wiki.php.net/rfc/curl-url-api
>
>
> TBH I have a problem with the proposed Curl* classes.
> IMO they present a mix of responsibilities that I don't like.
>
> CurlUrl is for me is a mix of Url/Uri object properties well known from
> other userland implementations like the PSR one
> with Uri specific like the host, scheme, port, path, query, fragment, etc=
.
> but on the other hand, we have flags and options which
> purpose is to pass Curl specific things but in IMO wrong place instead
> (for instance Guzzle use separate argument in all methods for options and
> flags.
> Secondly, it has some default logic like `setScheme` allows to put a
> scheme but requires the supported one, with an exception that you can
> ignore support checking by a flag - IMO this logic belongs to its consume=
r
> logic and is not part of URL class logic and the `setPort` like above.
> Next thing is that it again has all the getters and setters and is not
> immutable. Why can't it be a simple constructor with read-only properties=
,
> no getters, no setters? Maybe I miss some discussion about why here.
>
>
> The same goes for CurlException which looks like is an exception for
> handling some encoding of Url and not exactly to the Url properties itsel=
f.
>
> But with all that said, if the target audience is only a user of low leve=
r
> `curl_*` functions rather than users of higher abstraction libraries like
> Guzzle or Httplug then, I guess I don't care that much.
> I'm only afraid that such a mix of responsibilities can lead to bad habit=
s
> when it gets to the separation of concerns by developers who get used to =
it
> and won' see the problem as I do.
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski
>

--0000000000002fc02705e26da42d--