Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127118
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> <CAH5C8xW_auVf+ig7odhTK8dVWwmXTg4ZVZN-0Fhh4SUBzrWxVw@mail.gmail.com>
 <8df04e01-deac-404b-beb7-cd982423db63@bastelstu.be> <CAH5C8xU0JcnmC2Hdd=Hj0CQUaL0-LN=1X8+5-eUbFH3ZMxCvBA@mail.gmail.com>
 <33427cd03035ef084245c44290b56a55@bastelstu.be>
In-Reply-To: <33427cd03035ef084245c44290b56a55@bastelstu.be>
Date: Tue, 15 Apr 2025 23:55:25 +0200
Message-ID: <CAH5C8xXwDO6Ui8pLmqoxEguURh97fAaL4CfLK-oitqC85N7+8w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000087647c0632d83a80"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--00000000000087647c0632d83a80
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,


> Perhaps the correct solution would be to offer only the non-raw methods
> for WHATWG URL and to not attempt any additional percent-decoding there?
> My reasoning is that the WHATWG URL is a living standard anyways, so
> trying to add additional semantics on top will result in sadness. My
> understanding is also that it is primarily intended for interaction with
> web browsers or to embed these URLs into HTML. For access control, e.g.
> in your framework the RFC3986 URI should be used. It's what HTTP uses
> internally and it supports well-defined normalization.
>
> What do you think?
>

This was one of my (unspoken) ideas as well. I used to think there must
have been a correct logic
for percent-decoding of WHATWG components, but if none of us can come up
with a sensible
idea, then it's best not to try it, I agree.

Unintuive probably is not the best word. But I expect users to primarily
> interact with the path component of an URL (e.g. within their
> framework=E2=80=99s router). So I think it makes sense to be extra explic=
it with
> examples there. As an example, I recently learned that Symfony's router
> does not support (encoded) slashes within a component:
>
>      #[Route('/test/{message}', name: 'test')]
>
> will work for http://localhost:8000/test/foo, but not for
> http://localhost:8000/test/foo%2fbar, resulting in:
>
>      No route found for "GET http://localhost:8000/test/foo%2fbar"
>
> So if you would just extend the: =E2=80=9CLet's have a look at some other=
 tricky
> example with Uri\Rfc3986\Uri:=E2=80=9D to my suggestion, I would be happy=
 :-)
>

Alright, I'll add it. It won't hurt for sure!

Note: I believe there is a small mistake in the example when you last
> modified it. It says:
>
>      echo $uri->getHost();                           //
> [2001:0db8:0001:0000:0000:0ab9:C0a8:0102]
>
> Should the 'C' in 'C0a8' also be lowercased?


Yes, nice catch! I swear I double checked it multiple times if there was
any uppercase letters that should
be lowercased...


> So it indeed seems to be a limitation of the WHATWG specification and
> your PHP implementation is consistent with node.js. That is a good thing
> and when a user stumbles upon this, we can point them towards node.js /
> the spec. Not great, but this is workable!
>

Thank you for the test! To be honest, I pretty much don't like how WHATWG
setters are specified, they seem to behave very "ad hoc" based on what I
saw so far. :(

Regards,
M=C3=A1t=C3=A9

--00000000000087647c0632d83a80
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><div class=3D"gmail_quote gm=
ail_quote_container"><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
Perhaps the correct solution would be to offer only the non-raw methods <br=
>
for WHATWG URL and to not attempt any additional percent-decoding there? <b=
r>
My reasoning is that the WHATWG URL is a living standard anyways, so <br>
trying to add additional semantics on top will result in sadness. My <br>
understanding is also that it is primarily intended for interaction with <b=
r>
web browsers or to embed these URLs into HTML. For access control, e.g. <br=
>
in your framework the RFC3986 URI should be used. It&#39;s what HTTP uses <=
br>
internally and it supports well-defined normalization.<br>
<br>
What do you think?<br></blockquote><div><br></div><div>This was one of my (=
unspoken) ideas as well. I used to think there must have been a correct log=
ic</div><div>for percent-decoding of WHATWG components, but if none of us c=
an come=C2=A0up with a sensible</div><div>idea, then it&#39;s best not to t=
ry it, I agree.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
Unintuive probably is not the best word. But I expect users to primarily <b=
r>
interact with the path component of an URL (e.g. within their <br>
framework=E2=80=99s router). So I think it makes sense to be extra explicit=
 with <br>
examples there. As an example, I recently learned that Symfony&#39;s router=
 <br>
does not support (encoded) slashes within a component:<br>
<br>
=C2=A0 =C2=A0 =C2=A0#[Route(&#39;/test/{message}&#39;, name: &#39;test&#39;=
)]<br>
<br>
will work for <a href=3D"http://localhost:8000/test/foo" rel=3D"noreferrer"=
 target=3D"_blank">http://localhost:8000/test/foo</a>, but not for <br>
<a href=3D"http://localhost:8000/test/foo%2fbar" rel=3D"noreferrer" target=
=3D"_blank">http://localhost:8000/test/foo%2fbar</a>, resulting in:<br>
<br>
=C2=A0 =C2=A0 =C2=A0No route found for &quot;GET <a href=3D"http://localhos=
t:8000/test/foo%2fbar" rel=3D"noreferrer" target=3D"_blank">http://localhos=
t:8000/test/foo%2fbar</a>&quot;<br>
<br>
So if you would just extend the: =E2=80=9CLet&#39;s have a look at some oth=
er tricky <br>
example with Uri\Rfc3986\Uri:=E2=80=9D to my suggestion, I would be happy :=
-)<br></blockquote><div><br></div><div>Alright, I&#39;ll add it. It won&#39=
;t hurt for=C2=A0sure!</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
Note: I believe there is a small mistake in the example when you last <br>
modified it. It says:<br>
<br>
=C2=A0 =C2=A0 =C2=A0echo $uri-&gt;getHost();=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// <br>
[2001:0db8:0001:0000:0000:0ab9:C0a8:0102]<br>
<br>
Should the &#39;C&#39; in &#39;C0a8&#39; also be lowercased?</blockquote><d=
iv>=C2=A0</div><div>Yes, nice catch! I swear I double checked it multiple t=
imes if there was any uppercase letters that should</div><div>be lowercased=
...</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>
So it indeed seems to be a limitation of the WHATWG specification and <br>
your PHP implementation is consistent with node.js. That is a good thing <b=
r>
and when a user stumbles upon this, we can point them towards node.js / <br=
>
the spec. Not great, but this is workable!<br></blockquote><div><br></div><=
div>Thank you for the test! To be honest, I pretty much don&#39;t like how =
WHATWG</div><div>setters are specified, they seem to behave very &quot;ad h=
oc&quot; based on what I saw so=C2=A0far. :(</div><div><br>
</div><div>Regards,</div><div>M=C3=A1t=C3=A9</div></div></div>

--00000000000087647c0632d83a80--