Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124258
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <f328f0f8-fa07-48dd-ae9d-cb93ac2ddb61@app.fastmail.com>
In-Reply-To: <5b83b423-f95f-4bec-9bc0-ec1f0114426d@gmail.com>
References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com>
 <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com>
 <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
 <CAH5C8xVVHMn3Q4U2Aa9n3sED3tGdnWoabryTSL6Dk0MrenD+3g@mail.gmail.com>
 <5b83b423-f95f-4bec-9bc0-ec1f0114426d@gmail.com>
Date: Sun, 07 Jul 2024 13:10:11 +0200
To: "ignace nyamagana butera" <nyamsprod@gmail.com>, internals@lists.php.net,
 =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Content-Type: multipart/alternative;
 boundary=ba67ad66c48b46ebbd26cfe30cb16bb4
From: rob@bottled.codes ("Rob Landers")

--ba67ad66c48b46ebbd26cfe30cb16bb4
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Jul 7, 2024, at 12:55, ignace nyamagana butera wrote:
> Hi M=C3=A1t=C3=A9,
>=20
> > Supporting IANA registered schemes is a valid request, and is=20
> definitely useful. However, I think this feature is not strictly=20
> required to have in the current RFC.
>=20
> True. Having a WHATWG compliant parser in PHP source code is a big +1=20
> from me I have nothing against that inclusion.
>=20
> > Based on your and others' feedback, it has now become clear for me=20
> that parse_url() is still useful and ext/url needs quite some addition=
al=20
> capabilities until this function really becomes superfluous.
>=20
> `parse_url` can only be deprecated when a RFC3986 compliant parser is=20
> added to php-src, hence why I insist in having that parser being prese=
nt=20
> too.
>=20
> I will also add that everything up to now in PHP uses RFC3986 as basis=20
> for generating or representing URLs (cURL extension, streams, etc...).=20
> Having the first and only OOP representation of an URL in the language=20
> not following that same specification seems odd to me. It opens the do=
or=20
> to inconcistencies that will only be resolved once an equivalent RFC39=
86=20
> URL object made its way into the source code.
>=20
> On the public API side I would recommend the following:
>=20
> - if you are to strictly follow the WHATWG specification no URI=20
> component can be null. They must all be strings. If we have to plan to=20
> use the same object for RFC3986 compliant parser, then all components=20
> should be nullable except for the path component which can never be nu=
ll=20
> as it is always present.

This isn't true. It's just that in the language it is specified in, any =
element can be null (i.e., no nullable types). It specifies what may be =
null here: URL Standard (whatwg.org) <https://url.spec.whatwg.org/#url-r=
epresentation>

=E2=80=94 Rob
--ba67ad66c48b46ebbd26cfe30cb16bb4
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div>=
<div><br></div><div>On Sun, Jul 7, 2024, at 12:55, ignace nyamagana bute=
ra wrote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>H=
i M=C3=A1t=C3=A9,<br></div><div><br></div><div>&gt; Supporting IANA regi=
stered schemes is a valid request, and is&nbsp;<br></div><div>definitely=
 useful. However, I think this feature is not strictly&nbsp;<br></div><d=
iv>required to have in the current RFC.<br></div><div><br></div><div>Tru=
e. Having a WHATWG compliant parser in PHP source code is a big +1&nbsp;=
<br></div><div>from me I have nothing against that inclusion.<br></div><=
div><br></div><div>&gt; Based on your and others' feedback, it has now b=
ecome clear for me&nbsp;<br></div><div>that parse_url() is still useful =
and ext/url needs quite some additional&nbsp;<br></div><div>capabilities=
 until this function really becomes superfluous.<br></div><div><br></div=
><div>`parse_url` can only be deprecated when a RFC3986 compliant parser=
 is&nbsp;<br></div><div>added to php-src, hence why I insist in having t=
hat parser being present&nbsp;<br></div><div>too.<br></div><div><br></di=
v><div>I will also add that everything up to now in PHP uses RFC3986 as =
basis&nbsp;<br></div><div>for generating or representing URLs (cURL exte=
nsion, streams, etc...).&nbsp;<br></div><div>Having the first and only O=
OP representation of an URL in the language&nbsp;<br></div><div>not foll=
owing that same specification seems odd to me. It opens the door&nbsp;<b=
r></div><div>to inconcistencies that will only be resolved once an equiv=
alent RFC3986&nbsp;<br></div><div>URL object made its way into the sourc=
e code.<br></div><div><br></div><div>On the public API side I would reco=
mmend the following:<br></div><div><br></div><div>- if you are to strict=
ly follow the WHATWG specification no URI&nbsp;<br></div><div>component =
can be null. They must all be strings. If we have to plan to&nbsp;<br></=
div><div>use the same object for RFC3986 compliant parser, then all comp=
onents&nbsp;<br></div><div>should be nullable except for the path compon=
ent which can never be null&nbsp;<br></div><div>as it is always present.=
<br></div></blockquote><div><br></div><div>This isn't true. It's just th=
at in the language it is specified in, any element can be null (i.e., no=
 nullable types). It specifies what may be null here:&nbsp;<a href=3D"ht=
tps://url.spec.whatwg.org/#url-representation">URL Standard (whatwg.org)=
</a><br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br><=
/div></body></html>
--ba67ad66c48b46ebbd26cfe30cb16bb4--