Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124426
Precedence: bulk
MIME-Version: 1.0
References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com>
 <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com> <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
In-Reply-To: <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
Date: Mon, 15 Jul 2024 11:20:02 +0200
Message-ID: <CAH5C8xXtaNy_74n4=w2_PcO7sO_ZeBeFFARctWcCbQGvJA-UQQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: nyamsprod@gmail.com
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000085d774061d45bca2"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--00000000000085d774061d45bca2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Ignace, Nicolas,

Based on your request for adding support for RFC 3986 spec compatible
parsing,
I evaluated another library (https://github.com/uriparser/uriparser/) in
the recent days
in order to add support for the requested functionality. As far as I can
tell, the results
were very promising, so I'm ok to include this into my proposal (I haven't
pushed my
changes yet and haven't updated the RFC yet).

Regarding the reference resolution (
https://uriparser.github.io/doc/api/latest/#resolution)
feature which has also already been asked for, I'm genuinely wondering what
the use-case is?
But in any case, I'm fine with incorporating this as well into the RFC,
since apparently
both Lexbor and uriparser support this (naturally).

What I became puzzled about is the correct object structure and naming. Now
that uriparser
which can deal with URIs came into the picture, while Lexbor can parse
URLs, I don't
know if it's a good idea to have a dedicated URI and a URL class extending
the former one...
If it is, then in my opinion, the logical behavior would be that Lexbor
always instantiates URL
classes, while uriparser would have to decide if the passed-in URI is
actually an URL, and
choose the instantiated class based on this factor... But in this case the
differences between
the RFC 3986 and WHATWG specifications couldn't be spelled out, since URL
objects
could hold URLs parsed based on both specs (and therefore having a unified
interface is required).

Or rather we should have a separate URI and a WhatwgUrl class so that the
former one would
always be created by uriparser, while the latter one by Lexbor? This way we
could have a dedicated
object interface for both standards (e.g. the RFC 3986 related one could
have a getUserInfo() method,
while the WHATWG related one could have both getUser() and getPassword()
methods). But then
the question is how interchangeable these classes should be? I.e. should we
be able to convert them
back and forth, or should there be an interface that is implemented by the
two classes?

I'd appreciate any suggestions regarding these questions.

P.S. due to its bad receptance, I got rid of the UrlParser class as well as
the UrlComponent enum from my
implementation in the meantime.

Regards,
M=C3=A1t=C3=A9

--00000000000085d774061d45bca2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Ignace, Nicolas,<div><br></div><div>Based on your requ=
est for adding support for RFC 3986 spec compatible parsing,</div><div>I ev=
aluated another library (<a href=3D"https://github.com/uriparser/uriparser/=
">https://github.com/uriparser/uriparser/</a>) in the recent days</div><div=
>in order to add support for the requested functionality. As far as I can t=
ell, the results<br></div><div>were very promising, so I&#39;m ok to includ=
e this into my proposal (I haven&#39;t pushed my</div><div>changes yet and =
haven&#39;t updated the RFC yet).</div><div><br></div><div>Regarding the re=
ference resolution (<a href=3D"https://uriparser.github.io/doc/api/latest/#=
resolution">https://uriparser.github.io/doc/api/latest/#resolution</a>)</di=
v><div>feature which has also already been asked for, I&#39;m genuinely=C2=
=A0wondering what the use-case is?</div><div>But in any=C2=A0case, I&#39;m =
fine with incorporating this as well into the RFC, since apparently</div><d=
iv>both Lexbor and uriparser support=C2=A0this (naturally).</div><div><br><=
/div><div>What I became puzzled about is the correct object structure and n=
aming. Now that uriparser</div><div>which can deal with URIs came into the =
picture, while Lexbor can parse URLs, I don&#39;t</div><div>know if it&#39;=
s a good idea to have a dedicated URI and a URL class extending the former =
one...</div><div>If it is, then in my opinion, the logical behavior would b=
e that Lexbor always instantiates URL</div><div>classes, while uriparser wo=
uld have to decide if the passed-in URI is actually an URL, and</div><div>c=
hoose the instantiated class based on this factor... But in this case the d=
ifferences between</div><div>the RFC 3986 and WHATWG specifications couldn&=
#39;t be spelled out, since URL objects</div><div>could hold URLs parsed ba=
sed on both specs (and therefore having a unified interface is required).</=
div><div><br></div><div>Or rather we should have a separate URI and a Whatw=
gUrl class so that the former one would</div><div>always be created by urip=
arser, while the latter one by Lexbor? This way we could=C2=A0have a dedica=
ted</div><div>object interface for both standards (e.g. the RFC 3986 relate=
d one could have a getUserInfo() method,</div><div>while the WHATWG related=
 one could have both getUser() and getPassword() methods). But then</div><d=
iv>the question is how interchangeable these classes should be? I.e. should=
 we be able to convert them</div><div>back and forth, or should there be an=
 interface that is implemented by the two classes?</div><div><br></div><div=
>I&#39;d appreciate any suggestions regarding these questions.</div><div><b=
r></div><div>P.S. due to its bad receptance, I got rid of the UrlParser cla=
ss as well as the UrlComponent enum from my</div><div>implementation in the=
 meantime.</div><div><br></div><div>Regards,</div><div>M=C3=A1t=C3=A9</div>=
</div>

--00000000000085d774061d45bca2--