Hi
On 7/1/22 12:07, Rowan Tommins wrote:
My concern is rather the opposite: if it is not obvious *to someone writing
PHP code* how the API should be used, there is a higher chance of them
using it incorrectly, and introducing errors.
A good example of this mindset is the password_* functions: t
On Thu, 30 Jun 2022 at 23:21, Levi Morrison via internals <
internals@lists.php.net> wrote:
> On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron
> wrote:
> > One of the goal of this API is to tighten a problematic vulnerable area
> > for applications where the URL parser library would believe one
On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron wrote:
>
> Hi all,
>
>
> > - The new CurlUrl class should probably be immutable from the start. It
> > was my biggest mistake not to do that with DateTime.
> >
> >
> After thinking about it and some discussions, I followed Derick's
> recommendation
Hi all,
> - The new CurlUrl class should probably be immutable from the start. It
> was my biggest mistake not to do that with DateTime.
>
>
After thinking about it and some discussions, I followed Derick's
recommendation and therefore changed the RFC to make the CurlUrl class
immutable. All the
On Mon, 27 Jun 2022 at 22:32, Pierrick Charron wrote:
> That's just an example with an old version of PHP, but let's say you have
> some code that makes requests but only to a specific list of servers, so
> you want to analyze the URL and check if the host is in a whitelist. If the
> provided URL
Hi Rowan
> If I've got a URL, which is already a string, what code would I write to
> "do some checks" on it, outside of a unit test?
>
That's just an example with an old version of PHP, but let's say you have
some code that makes requests but only to a specific list of servers, so
you want to a
On 27/06/2022 14:10, Pierrick Charron wrote:
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
Hi Rowan
>
> Rather than a *representation* of a URL, think of the class as a
> *builder* for URLs. There are multiple methods because you might want to
> build the URL in different orders ("start with this URL but replace the
> port", "start with this domain and I'll add the path later", etc). Al
Hi Michał,
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 t
On 27/06/2022 07:29, Michał Marcin Brzuchalski wrote:
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
Hi Pierrick
śr., 22 cze 2022 o 06:38 Pierrick Charron napisał(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
On Fri, 24 Jun 2022 at 15:05, Jeffrey Dafoe wrote:
> A thin wrapper would be the most flexible. Someone can always write a
> "friendlier" class using your thin wrapper, as you mentioned, but one
> cannot easily go the other direction.
>
I think this argument has some validity when talking about
On Fri, Jun 24, 2022, at 8:49 AM, Pierrick Charron wrote:
> Hi all, and thanks Levi for your feedback,
>
> If you look at the first thread (Discussion about new Curl URL API and
> ext/curl improvements) you'll see that this was my first approach. I even
> proposed to "OOPify" the actual CurlHandle
Please do not add yet another thin wrapper of an underlying C API. PHP is
not a drop-in replacement of C. PHP is a much higher-level language.
Developers should not have to understand how the underlying library works
to be able to use PHP. We need to move away from thin C wrappers as a
language. PH
Hi
On 6/24/22 15:49, Pierrick Charron wrote:
If you look at the first thread (Discussion about new Curl URL API and
ext/curl improvements) you'll see that this was my first approach. I even
proposed to "OOPify" the actual CurlHandle & co objects with "simple"
methods like $ch->setOpt(). Anyone w
9:49 AM
To: Levi Morrison
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
Hi all, and thanks Levi for your feedback,
If you look at the first thread (Discussion about new Curl URL API and ext/curl
improvements) you'll see that this was my first approach.
Hi all, and thanks Levi for your feedback,
If you look at the first thread (Discussion about new Curl URL API and
ext/curl improvements) you'll see that this was my first approach. I even
proposed to "OOPify" the actual CurlHandle & co objects with "simple"
methods like $ch->setOpt(). Anyone who r
On 23 June 2022 17:48:57 BST, Levi Morrison via internals
wrote:
>IMO, this should mirror the low-level curl url API very directly. The
>basis of my opinion is that we do not own libcurl; we are merely
>adapting it for use in PHP. We cannot anticipate changes in their
>design, nor do we have auth
On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron wrote:
>
> 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
HI Hans,
any particular reason CurlUrl::getPort() defaults to 0 rather than one of
> the valid options? (that being CurlUrl::DEFAULT_PORT
> and CurlUrl::NO_DEFAULT_PORT )
>
This is because the default is none of those 2 behaviours, If the port
wasn't set it will return null, but if the port is t
(dammit, mixed sftp:// with ftps:// there, ignore that, i meant sftp:// )
On Wed, 22 Jun 2022 at 16:53, Hans Henrik Bergan
wrote:
> nitpicking but I kind-of doubt the description
> for CurlUrl::NO_DEFAULT_PORT is correct, quote:
> > Instructs the method to return null if the port matches the def
nitpicking but I kind-of doubt the description for CurlUrl::NO_DEFAULT_PORT
is correct, quote:
> Instructs the method to return null if the port matches the default port
for the scheme.
makes it sound like these would return null: http://localhost:80/
https://localhost:443/ ftps://localhost:22/
I
any particular reason CurlUrl::getPort() defaults to 0 rather than one of
the valid options? (that being CurlUrl::DEFAULT_PORT
and CurlUrl::NO_DEFAULT_PORT )
On Wed, 22 Jun 2022 at 16:23, Pierrick Charron wrote:
> Hi Derick,
>
>
> >
> > - The new CurlUrl class should probably be immutable from t
Hi Derick,
>
> - The new CurlUrl class should probably be immutable from the start. It
> was my biggest mistake not to do that with DateTime.
>
>
Thanks for sharing your lessons learned. But I still see some use cases
where mutable objects are easier to use. From the experience you had with
DateT
On 22 June 2022 05:38:13 BST, Pierrick Charron wrote:
>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 curr
On 22 Jun 2022, at 05:38, Pierrick Charron wrote:
> Here is the RFC that reflects our current conversations.
>
> https://wiki.php.net/rfc/curl-url-api
>
> Feel free to give any feedback, concern or support :-)
Thanks Pierrick,
I think this is a good approach to add the URL functionality to PH
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
Fe
27 matches
Mail list logo
