Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126962
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <dd61999c-1ebd-4765-9add-cd8065968965@gmail.com> <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
 <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com> <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be> <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
 <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
 <6430b9ed-638d-4247-9fa9-d1a9148c382b@gmail.com> <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
 <2e95e8fe-7cf0-493f-bd0a-9fff0956baaa@gmail.com>
In-Reply-To: <2e95e8fe-7cf0-493f-bd0a-9fff0956baaa@gmail.com>
Date: Thu, 27 Mar 2025 22:04:27 +0100
Message-ID: <CAH5C8xXuSEBx6y4ds8bhReFFZe0i05DFonvEP+sz+mdkembZtQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: Ignace Nyamagana Butera <nyamsprod@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000488ecc0631594da6"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000488ecc0631594da6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace,

While implementing the polyfill I am finding easier DX wise to make the
> constructor private and use instead named constructors for instantiation.=
 I
> would be in favor of
>
> `Uri::parse` and `Uri::tryParse` like it is done currently with Enum and
> the `from` and `tryfrom` named constructors.
>
> My reasoning is as follow:
>
>  there's no right way or wrong way to instantiate an URI there are only
> contexts. While the parse method is all about parsing a string, one could
> legitimately use other named constructors like `Uri::fromComponents` whic=
h
> would take for instance the result of parse_url to build a new URI. This
> can become handy in the case of RFC3986 URI if you need to create an new
> URI not related to the http scheme and that do not use all the components
> like the email, data or FTP schemes.
>
>  By allowing creating URI based on their respective components value you
> make it easier for dev to use the class. Also this means that if we want =
to
> have a balance API then a `toComponents` method should come hand in hand
> with the named constructor.
>
> I would understand if that idea to add both components related methods is
> rejected, they could be implemented on userland, but the main point was t=
o
> prove that from the VO or the developer POV in absence of a clearly defin=
ed
> instantiation process, having a traditional constructor fails to convey a=
ll
> the different way to create an URI.
>

There are a few things which came to my mind:
- Currently, the underlying C libraries don't support a `fromComponents`
feature. How I could naively imagine this to work is that the components
are recomposed to a URI string based on the relevant algorithm (for RFC
3986: https://datatracker.ietf.org/doc/html/rfc3986#section-5.3), and then
this string is parsed and validated. Unfortunately, I recently realized
that this approach may leave room for some kind of parsing confusion
attack, namely when the scheme is for example "https", the authority is
empty, and the path is "example.com". This will result in a
https://example.com URI. I believe a similar bug is not possible with the
rest of the components because they have their delimiters. So possibly some
other solution will be needed, or maybe adding some additional validation
(?).

- Nicolas raised my awareness that if URIs didn't have a proper
constructor, then one wouldn't be able to use URI objects as parameter
default values, like below:
function (Uri $foo =3D new Uri('blah'))
I think this omission would cause some usability regression. For this
reason, it may make sense to have a distinguished way of instantiating an
Uri.

- I have a similar feeling for a toComponents() method as for another named
constructor instead of __construct(): I am not completely against it, but
I'm not totally convinced about it.

M=C3=A1t=C3=A9

--000000000000488ecc0631594da6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ignace,</div><div dir=3D"ltr"><br></di=
v><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div>
    <p>While implementing the polyfill I am finding easier DX wise to
      make the constructor private and use instead named constructors
      for instantiation. I would be in favor of=C2=A0</p>
    <p>`Uri::parse` and `Uri::tryParse` like it is done currently with
      Enum and the `from` and `tryfrom` named constructors.<br>
    </p>
    <p>My reasoning is as follow:</p>
    <p>=C2=A0there&#39;s no right way or wrong way to instantiate an URI th=
ere
      are only contexts. While the parse method is all about parsing a
      string, one could legitimately use other named constructors like
      `Uri::fromComponents` which would take for instance the result of
      parse_url to build a new URI. This can become handy in the case of
      RFC3986 URI if you need to create an new URI not related to the
      http scheme and that do not use all the components like the email,
      data or FTP schemes.</p>
    <p>=C2=A0By allowing creating URI based on their respective components
      value you make it easier for dev to use the class. Also this means
      that if we want to have a balance API then a `toComponents` method
      should come hand in hand with the named constructor.</p>
    <p>I would understand if that idea to add both components related
      methods is rejected, they could be implemented on userland, but
      the main point was to prove that from the VO or the developer POV
      in absence of a clearly defined instantiation process, having a
      traditional constructor fails to convey all the different way to
      create an URI.</p></div></blockquote><div>=C2=A0</div><div>There are =
a few things which came to=C2=A0my mind:</div><div>- Currently, the underly=
ing C libraries don&#39;t support a `fromComponents` feature. How I could n=
aively imagine this to work is that the components are recomposed to a URI =
string based=C2=A0on the relevant algorithm (for RFC 3986: <a href=3D"https=
://datatracker.ietf.org/doc/html/rfc3986#section-5.3">https://datatracker.i=
etf.org/doc/html/rfc3986#section-5.3</a>), and then this string is parsed a=
nd validated. Unfortunately, I recently realized that this approach may lea=
ve room for some kind of parsing confusion attack, namely when the scheme i=
s for example &quot;https&quot;, the authority is empty, and the path is &q=
uot;<a href=3D"http://example.com">example.com</a>&quot;. This will result =
in a <a href=3D"https://example.com">https://example.com</a> URI. I believe=
 a similar bug is not possible with the rest of the components because they=
 have their delimiters. So possibly some other solution will be needed, or =
maybe adding some additional validation (?).</div><div><br></div><div>- Nic=
olas raised my awareness that if URIs didn&#39;t have a proper constructor,=
 then one wouldn&#39;t be able to use URI objects as parameter default valu=
es, like below:</div><div>function (Uri $foo =3D new Uri(&#39;blah&#39;))</=
div><div>I think this omission would cause some usability regression. For t=
his reason, it may make sense to have a distinguished way of instantiating =
an Uri.</div><div><br></div><div>- I have a similar feeling=C2=A0for a toCo=
mponents() method as for another named constructor instead of __construct()=
: I am not completely against it, but I&#39;m not totally convinced about i=
t.</div><div><br></div><div>M=C3=A1t=C3=A9</div><div><br></div></div></div>

--000000000000488ecc0631594da6--