Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125255
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>
In-Reply-To: <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
Date: Mon, 26 Aug 2024 09:40:56 +0200
Message-ID: <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: ignace nyamagana butera <nyamsprod@gmail.com>
Cc: Niels Dossche <dossche.niels@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000007a2cb10620913f3f"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000007a2cb10620913f3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace, Niels,

Sorry for being silent for so long, I was working hard on the
implementation besides some summer activities :) I can say that I had
really good progress in the last month and now I think (hope) that I
managed to address most of the concerns/suggestions people mentioned
in this thread. To summarize the most important changes:

- The uriparser library is now used for parsing URIs based on RFC 3986.
- I renamed the extension to "uri" in favor of "url" in order to
make the name more generic and to express the new use-case.
- There is no Url\UrlParser class anymore. The Uri\Uri class now includes
the relevant factory methods.
- Uri/Uri is now an abstract class which is implemented by 2 concrete
classes: Uri\Rfc3986Uri and Uri\WhatwgUri.
- WhatWG URL parsing now returns the exact error code according to the
specification (although a reference parameter is used for now - but this is
TBD)
- As suggested by Niels, it's now possible to plug an URI parsing
implementation into PHP. A new uri.default_handler INI option is also added=
.
Currently, integration is only implemented for FILTER_VALIDATE_URL though.
The approach also makes it possible to register additional 3rd party
libraries for parsing URIs (like ADA URL).
- It looks like that performance significantly improved according to the
rough benchmarks performed in CI.

Please re-read the RFC as it shares a bit more details than my quick
summary above: https://wiki.php.net/rfc/url_parsing_api

There are some questions I still didn't manage to find an answer for
though. Most importantly, the URI parser libraries used don't support
modification
of the URI. That's why I had to get rid of the "wither" methods for now
which were originally part of the API. I think it's unfortunate, and I'll
try to do my
best to reclaim them.

Additionally, due to technical reasons, extending the Uri\Uri class in
userland is only possible if all the methods are overridden by the child.
It's because
I had to use "computed" properties in the implementation (roughly, they are
stored in an internal C struct unlike regular properties). That's why it
may be
better if userland code could use (and possibly implement) an Uri\Uri
interface instead.

In one of my previous emails, I had some concerns that RFC 3986 and WhatWg
spec can really share the same interface (they do in my current
implementation
despite that they are different classes). I still share this concern
because WhatWg specifies the "user" and "password" URL components, while
RFC 3986
only specifies the notion of "userinfo" (which is usually just
user:password, but it's not necessarily the case as far as I understood).
The RFC implementation
of the RFC 3986 parser currently splits the 'userinfo' component at the ":"
character, but doing so doesn't seem very spec compliant.

Arnaud suggested that it would be better if the query parameters could be
retrieved both escaped and unescaped after parsing. I haven't had time to
investigate
the possibilities, but my gut feeling is that it's only possible to achieve
with some custom code. Arnaud also had questions regarding canonization.
Currently,
it's not performed when calling the __toString() method, because only
uriparser library supports this feature, and I didn't want to diverge the
two implementations.
I'm not even sure that it's a good idea to always do it so I'm thinking
about the possibility to selectively enable this feature (i.e. adding a
separate "toCanonizedString"
method).

Regards,
M=C3=A1t=C3=A9

--0000000000007a2cb10620913f3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ignace, Niels,</div><div dir=3D"ltr"><=
br></div><div>Sorry for being silent for so long, I was working hard on the=
 implementation besides some summer activities :) I can say that I had</div=
><div>really good progress in the last month and now I think (hope) that I =
managed to address most of the concerns/suggestions people mentioned</div><=
div>in this thread.=C2=A0<span style=3D"color:rgb(191,191,191)">To summariz=
e the most important changes:</span></div><div><span style=3D"color:rgb(191=
,191,191)"><br></span></div><div><span style=3D"color:rgb(191,191,191)">- T=
he uriparser library is now used for parsing URIs based on RFC 3986.</span>=
<span style=3D"color:rgb(191,191,191)"><br></span></div><div><span style=3D=
"color:rgb(191,191,191)">- I renamed=C2=A0the extension to &quot;uri&quot; =
in favor of &quot;url&quot; in order to make=C2=A0the=C2=A0name more generi=
c and to express the new use-case.</span></div><div>- There is no Url\UrlPa=
rser class anymore. The Uri\Uri class now includes the relevant factory met=
hods.</div><div>- Uri/Uri is now an abstract class which is implemented by =
2 concrete classes: Uri\Rfc3986Uri=C2=A0and=C2=A0Uri\WhatwgUri.</div><div>-=
 WhatWG URL parsing now returns the exact error code according to the speci=
fication (although a reference parameter is used for now - but this is TBD)=
</div><div>- As suggested by Niels, it&#39;s now possible to plug an URI pa=
rsing implementation into PHP. A new uri.default_handler INI option is also=
 added.</div><div><div style=3D"color:rgb(191,191,191)">Currently, integrat=
ion is only implemented for FILTER_VALIDATE_URL though. The approach also m=
akes it possible to register additional 3rd party</div><div style=3D"color:=
rgb(191,191,191)">libraries for=C2=A0parsing URIs (like ADA URL).</div></di=
v><div>- It looks like that performance significantly improved according to=
=C2=A0the rough benchmarks performed in CI.</div><div><br></div><div>Please=
 re-read the RFC as it shares a bit more details than my quick summary abov=
e:=C2=A0<a href=3D"https://wiki.php.net/rfc/url_parsing_api">https://wiki.p=
hp.net/rfc/url_parsing_api</a></div><div><br></div><div>There are some ques=
tions I still didn&#39;t manage to find an answer for though. Most importan=
tly, the URI parser libraries used don&#39;t support modification</div><div=
>of the URI. That&#39;s why I had to get rid of the &quot;wither&quot; meth=
ods for now which were originally part of the API. I think it&#39;s unfortu=
nate, and I&#39;ll try to do my</div><div>best to reclaim them.</div><div><=
br></div><div>Additionally, due to technical reasons, extending the Uri\Uri=
 class in userland is only possible if all the methods are overridden by th=
e child. It&#39;s because</div><div>I had to=C2=A0<span style=3D"color:rgb(=
191,191,191)">use &quot;computed&quot; properties in the implementation (ro=
ughly, they are stored in an internal C struct unlike regular properties). =
That&#39;s why it may be</span></div><div><span style=3D"color:rgb(191,191,=
191)">better if userland code could use (and possibly implement) an Uri\Uri=
 interface instead.</span></div><div><span style=3D"color:rgb(191,191,191)"=
><br></span></div><div><span style=3D"color:rgb(191,191,191)">In one of my =
previous emails, I had some concerns that RFC 3986 and WhatWg spec can real=
ly share the same interface (they do in my current implementation</span></d=
iv><div><span style=3D"color:rgb(191,191,191)">despite that they are differ=
ent classes). I still share this concern because WhatWg specifies the &quot=
;user&quot; and &quot;password&quot; URL components, while RFC 3986</span><=
/div><div><span style=3D"color:rgb(191,191,191)">only specifies the notion =
of &quot;userinfo&quot; (which is usually just user:password, but it&#39;s =
not necessarily the case as far as I understood). The RFC implementation</s=
pan></div><div>of the RFC 3986 parser currently splits the &#39;userinfo=
9; component at the &quot;:&quot; character, but doing so doesn&#39;t seem =
very spec compliant.</div><div><br></div><div>Arnaud suggested that it woul=
d be better if the query parameters could be retrieved both escaped and une=
scaped after parsing. I haven&#39;t had time to investigate</div><div>the p=
ossibilities, but my gut feeling is that it&#39;s only possible to achieve =
with some custom code. Arnaud also had questions regarding canonization. Cu=
rrently,</div><div>it&#39;s not performed when calling the __toString() met=
hod, because only uriparser library supports this feature, and I didn&#39;t=
 want to diverge the two implementations.</div><div>I&#39;m not even sure t=
hat it&#39;s a good idea to always do it so=C2=A0I&#39;m thinking about=C2=
=A0the=C2=A0possibility to selectively enable this feature (i.e. adding a s=
eparate &quot;toCanonizedString&quot;</div><div>method).</div><div><br></di=
v><div>Regards,</div><div>M=C3=A1t=C3=A9</div></div>

--0000000000007a2cb10620913f3f--