Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129523
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
 <9873b03e-1260-44b3-8285-af9511d8766e@app.fastmail.com> <CAOV5rgYLush5cqYCct6yKqtQ-qXBGH8Lb5z5cZS4emw_kuuT=g@mail.gmail.com>
 <0081d8ac-6520-4a32-8ea5-5e10086e34e3@app.fastmail.com>
In-Reply-To: <0081d8ac-6520-4a32-8ea5-5e10086e34e3@app.fastmail.com>
Date: Wed, 3 Dec 2025 09:33:44 +0100
Message-ID: <CAOV5rgb3VM_bqNwG05Qafos3H890bx6V7QyryVL3QdELo-hD_g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: Larry Garfield <larry@garfieldtech.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a8c73306450812c5"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--000000000000a8c73306450812c5
Content-Type: text/plain; charset="UTF-8"

>  - Url::isSpecial() Could we come up with a better name here?
I would go with Url::isStandardBrowserUrl() or something similar. The
*special* in the WHATWG spec represents a list of specific URI schemes. It
currently contains http(s), ws(s) and file. But since it is a living
standard, if I remember correctly, at some point, the gopher scheme for
instance was also listed there and in contrast the data or the blob URI
scheme have never been listed there. So finding the right name which does
not get outdated depending on what it represents is ... special

> - So the interface doesn't cover build().  Problem solved.
And it does not cover (set)userInfo, (set)username, (set)password ...
modifiers too and depending on if validation is taken into account you may
also remove (set)host from your interface

> - Then the RFC needs to explain why we need to have both for the query
params, and how they differ.
The RFC3986 URI exposes the `raw` non normalized URI component as well as
the normalized one. The only distinction from the Query component
perspective in RFC3986 is that encoded characters need to be uppercased. So
if you want to work with the raw input untouched you will need the
getRawQuery and thus the getRawQueryParams. As I said this is already
covered in the previous RFC. Where I do agree with you
is, if after creating the UriQueryParams the result is identical, then we
may not need the getRawQueryParams method at all.

Best regards,
Ignace

--000000000000a8c73306450812c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">&gt;=C2=A0 - Url::isSpec=
ial() Could we come up with a better name here?<div>I would go with Url::is=
StandardBrowserUrl() or something similar. The <b>special</b> in the WHATWG=
 spec represents a list of specific URI schemes. It currently contains http=
(s), ws(s) and=C2=A0file. But since it is a living standard, if I remember =
correctly, at some point, the gopher scheme for instance was also listed th=
ere and in contrast the data or the blob URI scheme have never been listed =
there. So finding the right name which does not get outdated depending on w=
hat it represents is ... special</div><div><br></div><div>&gt; - So the int=
erface doesn&#39;t cover build().=C2=A0 Problem solved.</div><div>And it do=
es not cover=C2=A0(set)userInfo, (set)username, (set)password ... modifiers=
 too and depending on if validation is taken into=C2=A0account you may also=
 remove (set)host from your interface</div><div><br></div><div>&gt; - Then =
the RFC needs to explain why we need to have both for the query params, and=
 how they differ.</div><div>The RFC3986 URI exposes the `raw` non normalize=
d URI component as well as the normalized one. The only distinction from th=
e Query component perspective in RFC3986 is that encoded characters need to=
 be uppercased. So if you want to work with the raw input untouched you wil=
l need the getRawQuery and thus the getRawQueryParams. As I said this is al=
ready covered=C2=A0in the previous RFC. Where I do agree with you</div><div=
>is, if after creating the UriQueryParams the result is identical, then we =
may not need the getRawQueryParams method at all.</div><div><br></div><div>=
Best regards,</div><div>Ignace</div><div><br></div></div></div>
</div>

--000000000000a8c73306450812c5--