Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126762
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>
In-Reply-To: <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
Date: Fri, 14 Mar 2025 20:45:23 +0100
Message-ID: <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: Ignace Nyamagana Butera <nyamsprod@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000922916063052aed5"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000922916063052aed5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace,


>  > All URI components - with the exception of the host - can be
> retrieved in two formats:
>
> I believe you mean - with the excepotion of the Port
>
>
Even though I specifically meant WHATWG's host that is only available in
only
one format, you are right, the port is never available in two formats. So
I've
changed the wording accordingly.


> 0 - It is a unfortunate that there's no IDNA support for RFC3986, I
> understand the reasoning behind that decision but I was wondering if it
> was possible to optin its use when the ext-intl extension is present ?
>

Good question, I think it's probably not the main concern. My specific
concern is that
RFC 3987 has around same length as RFC 3986, in a lot of cases it uses the
exact
wording of the initial RFC but changes URI to IRI, and of course adds the
IDNA specific parts. Maybe it's just me, but it's not easy to find it out
exactly what
has to be implemented above RFC 3986, and also, how it can be best achieved=
?
By extending the class for RFC 3986? Creating a totally separate class that
can
transform itself to an RFC 3986 URI? These and quite some other questions
have
to be answered first, which I would like to postpone.


>
> 1 - Does it means that if/when Rfc3986/Uri get Rfc3987 supports they
> will also get a `Uri::toDisplayString` and `Uri::getHostForDisplay`
> maybe this should be stated in the Futurscope ?
>

It's a question that I also asked from myself. For now, I'd say that
Rfc3986/Uri shouldn't have these methods, since it doesn't support any such
capabilities. But Rfc3986\Iri should likely have these toString methods.


> 4 - For consistency I would use toRawString and toString just like it is
> done for components.
>

I'm fine with this, I also think doing so would reasonably continue the
convention
getters do.


>
> 5 - Can the returned array from __debugInfo be used in a "normal" method
> like `toComponents` naming can be changed/improve to ease migration from
> parse_url or is this left for userland library ?
>

I intend to add the __debugInfo() method purely to help debugging. Without
this
method, even I had a hard time when trying to compare the expected vs actua=
l
URIs in my tests.

But more importantly, sometimes the recomposed string is not enough to have
a
good understanding exactly what value each component has. For example
one can naively assume that the "mailto:kocsismate@php.net" URI has a
user(info) component of "kocsismate" and a hostname of "php.net" (I probabl=
y
also did so before reading the RFCs). The representation provided by
__debugInfo() can quickly highlight that "kocsismate@php.net" is the path
in fact.
One could try to call the individual getters to find the needed component,
but having
such a method like __debugInfo() provides a much more clear picture about
the anatomy of
the URI.

But otherwise I don't know how useful this method would be. Is there anythi=
ng
else
besides helping the migration?

Regards,
M=C3=A1t=C3=A9

--000000000000922916063052aed5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div>Hi I=
gnace,</div><div><span style=3D"color:rgb(191,191,191)">=C2=A0</span></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(77,77,77);padding-left:1ex">=C2=A0&gt; All URI component=
s - with the exception of the host - can be <br>
retrieved in two formats:<br>
<br>
I believe you mean - with the excepotion of the Port<br><br></blockquote><d=
iv><br></div><div>Even though I specifically meant WHATWG&#39;s host that i=
s only available in only</div><div>one format, you are right, the port is n=
ever available in two formats. So I&#39;ve</div><div>changed the wording ac=
cordingly.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(77,77,77);padding-left:=
1ex">
0 - It is a unfortunate that there&#39;s no IDNA support for RFC3986, I <br=
>
understand the reasoning behind that decision but I was wondering if it <br=
>
was possible to optin its use when the ext-intl extension is present ?<br><=
/blockquote><div><br></div><div>Good question, I think it&#39;s probably no=
t the main concern. My specific concern is that</div><div>RFC 3987 has arou=
nd same length as RFC 3986, in a lot of cases it uses the exact</div><div>w=
ording of the initial RFC but changes URI to IRI, and of course adds the</d=
iv><div>IDNA specific parts. Maybe it&#39;s just me, but it&#39;s not easy =
to find it out exactly what</div><div>has to be implemented above RFC 3986,=
 and also, how it can be best achieved?</div><div>By extending the class=C2=
=A0for RFC 3986? Creating a totally separate class that can</div><div>trans=
form itself to an RFC 3986 URI? These and quite some other questions have</=
div><div>to be answered first,=C2=A0<span style=3D"color:rgb(191,191,191)">=
which I would like to postpone.</span></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(77,77,77);padding-left:1ex">
<br>
1 - Does it means that if/when Rfc3986/Uri get Rfc3987 supports they <br>
will also get a `Uri::toDisplayString` and `Uri::getHostForDisplay` <br>
maybe this should be stated in the Futurscope ?<br></blockquote><div><br></=
div><div>It&#39;s a question that I also asked from myself. For now, I&#39;=
d say that</div><div><span style=3D"color:rgb(191,191,191)">Rfc3986/Uri sho=
uldn&#39;t have these methods, since it doesn&#39;t support any such</span>=
</div><div><span style=3D"color:rgb(191,191,191)">capabilities. But Rfc3986=
\Iri should likely have these toString methods.</span></div><div><span styl=
e=3D"color:rgb(191,191,191)"><br></span></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(77,77,77);=
padding-left:1ex">
<br>
4 - For consistency I would use toRawString and toString just like it is <b=
r>
done for components.<br></blockquote><div><br></div><div>I&#39;m fine with =
this, I also think doing so would reasonably=C2=A0continue the convention</=
div><div>getters do.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(77,77,77);pad=
ding-left:1ex">
<br>
5 - Can the returned array from __debugInfo be used in a &quot;normal&quot;=
 method <br>
like `toComponents` naming can be changed/improve to ease migration from <b=
r>
parse_url or is this left for userland library ?<br></blockquote><div><br><=
/div><div>I intend to add the __debugInfo() method purely to help debugging=
. Without this</div><div><span style=3D"color:rgb(191,191,191)">method, eve=
n I had a hard time when=C2=A0trying to compare the expected=C2=A0vs actual=
</span></div><div><span style=3D"color:rgb(191,191,191)">URIs in=C2=A0my te=
sts.</span></div><div><span style=3D"color:rgb(191,191,191)"><br></span></d=
iv><div><span style=3D"color:rgb(191,191,191)">But more importantly, someti=
mes the recomposed string is not enough to have a</span></div><div><span st=
yle=3D"color:rgb(191,191,191)">good understanding exactly what value each c=
omponent has. For example</span></div><div>one can naively assume that the =
&quot;mailto:<a href=3D"mailto:kocsismate@php.net">kocsismate@php.net</a>&q=
uot; URI has a</div><div>user(info)=C2=A0<span style=3D"color:rgb(191,191,1=
91)">component of &quot;kocsismate&quot; and a hostname=C2=A0</span><span s=
tyle=3D"color:rgb(191,191,191)">of &quot;<a href=3D"http://php.net">php.net=
</a>&quot; (I probably</span></div><div><span style=3D"color:rgb(191,191,19=
1)">also did so before reading the RFCs). The representation provided by</s=
pan></div><div><span style=3D"color:rgb(191,191,191)">__debugInfo() can qui=
ckly highlight that &quot;</span><span style=3D"color:rgb(191,191,191)"><a =
href=3D"mailto:kocsismate@php.net">kocsismate@php.net</a></span><span style=
=3D"color:rgb(191,191,191)">&quot; is the path in fact.</span></div><div><s=
pan style=3D"color:rgb(191,191,191)">One could try to call the individual g=
etters to find the needed component, but=C2=A0</span>having</div><div><span=
 style=3D"color:rgb(191,191,191)">such a method like __debugInfo() provides=
 a much more clear picture about the anatomy of</span></div><div><span styl=
e=3D"color:rgb(191,191,191)">the URI.</span></div><div><span style=3D"color=
:rgb(191,191,191)"><br></span></div><div><span style=3D"color:rgb(191,191,1=
91)">But otherwise I don&#39;t know how useful this method would be. Is the=
re=C2=A0</span><span style=3D"color:rgb(191,191,191)">anything else</span><=
/div><div><span style=3D"color:rgb(191,191,191)">besides helping the migrat=
ion?</span></div><div><span style=3D"color:rgb(191,191,191)"><br></span></d=
iv><div>Regards,</div><div>M=C3=A1t=C3=A9</div><div>=C2=A0</div></div></div=
>

--000000000000922916063052aed5--