Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127069
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <CAH5C8xXVcPM9drj-Ny5Fs_2_wnedES8-gbchaYf7z2bWne2WcQ@mail.gmail.com>
 <8b7044d1-fde1-4701-a914-a63c8ca67099@app.fastmail.com> <CAH5C8xUA8NuWiiE+yiVAdMWFptgFp45z73XdLcgEMV6MR-4mPw@mail.gmail.com>
In-Reply-To: <CAH5C8xUA8NuWiiE+yiVAdMWFptgFp45z73XdLcgEMV6MR-4mPw@mail.gmail.com>
Date: Tue, 8 Apr 2025 00:00:25 +0100
Message-ID: <CAH5C8xWGqesGVQt6T_c_0JKC2YrjJ33u5r=B3cOKJrLzHW1GEg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: Ignace Nyamagana Butera <nyamsprod@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000040488e063238342b"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--00000000000040488e063238342b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Ignace,

(let me answer in the original thread, as apparently the discussion
continued in a separate thread from the main one)

> - I believe during normalization of IPv6 host the letter a-f should be
> lowercase in accordance with the RFC since
>
> RFC3986 follows https://www.rfc-editor.org/rfc/rfc3513 which has been
> replaced by https://www.rfc-editor.org/rfc/rfc4291 which is updated by
> https://www.rfc-editor.org/rfc/rfc5952#section-4.3 which recommends
> lowecasing the letters. (yeah that was quite a digging I know =F0=9F=99=
=82 )
>
That's quite a long chain of RFC updates.... But yes, RFC 3986 explicitly
mentions this here:

Although host is case-insensitive, producers and normalizers should use
> lowercase for registered names and hexadecimal addresses for the sake of
> uniformity, while only using uppercase letters for percent-encodings.


And that's what the current implementation does. :)

> - Since the withers expect well encoded components does it means that it
> is the same for the constructor. What is
>
> the expected result for the following code ?
>
> ```php
>
> $uri =3D new Uri\Rfc3986\Uri("https://example,com/?foo[]=3D1&foo[]=3D2" <=
https://example,com/?foo[]=3D1&foo[]=3D2>);
> ```
>
> Should the above trigger an exception because the query component contain=
 invalid characters or
> is it acceptable ? Asking because currently our dear old parse_url does n=
ot fail on this and
> probably most PHP developers expect this not to fail.
>
> IMHO I am in favor of it failing to get a consistent experience when usin=
g the class because
> otherwse you introduce an inconsistency between the constructor behaviour=
 and the rest of the class
> API.
>
>
Yes, generally, creation or any mutation of Uri\Rfc3986\Uri fails when the
URI is invalid, exactly in order to offer a consistent experience.

Regards,
M=C3=A1t=C3=A9

>

--00000000000040488e063238342b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hey Ignace,</div><div di=
r=3D"ltr"><br></div><div>(let me answer in the original thread, as apparent=
ly the discussion continued in a separate thread from the main one)</div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div><p>- I believe during normalization of IPv6 host the letter a-f should=
 be lowercase in accordance with the RFC since<br></p><p>RFC3986 follows=C2=
=A0<a href=3D"https://www.rfc-editor.org/rfc/rfc3513" target=3D"_blank">htt=
ps://www.rfc-editor.org/rfc/rfc3513</a>=C2=A0which has been replaced by=C2=
=A0<a href=3D"https://www.rfc-editor.org/rfc/rfc4291" target=3D"_blank">htt=
ps://www.rfc-editor.org/rfc/rfc4291</a>=C2=A0which is updated by=C2=A0<a hr=
ef=3D"https://www.rfc-editor.org/rfc/rfc5952#section-4.3" target=3D"_blank"=
>https://www.rfc-editor.org/rfc/rfc5952#section-4.3</a>=C2=A0which recommen=
ds lowecasing the letters. (yeah that was quite a digging I know=C2=A0=F0=
=9F=99=82=C2=A0)</p></div></blockquote><div>That&#39;s quite a long chain o=
f RFC updates.... But yes, RFC 3986 explicitly mentions this here:</div><di=
v><br></div><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">Although=
 host is case-insensitive, producers and normalizers should use lowercase f=
or registered names and hexadecimal addresses for the sake of uniformity, w=
hile only using uppercase letters for percent-encodings.</blockquote><br></=
div><div>And that&#39;s what=C2=A0the current implementation does. :)</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"><div><p></p><p>- Since th=
e withers expect well encoded components does it means that it is the same =
for the constructor. What is</p><p>the expected result for the following co=
de ?<br></p><p>```php</p><div style=3D"color:rgb(8,8,8)"><pre style=3D"font=
-family:&quot;JetBrains Mono&quot;,monospace"><span style=3D"color:rgb(102,=
0,0)">$uri </span>=3D <span style=3D"color:rgb(0,51,179)">new </span><span =
style=3D"color:rgb(0,0,0)">Uri</span>\<span style=3D"color:rgb(0,0,0)">Rfc3=
986</span>\<span style=3D"color:rgb(0,0,0)">Uri</span>(<span style=3D"color=
:rgb(6,125,23)"><a href=3D"https://example,com/?foo[]=3D1&amp;foo[]=3D2" ta=
rget=3D"_blank">&quot;https://example,com/?foo[]=3D1&amp;foo[]=3D2&quot;</a=
></span>);
```

Should the above trigger an exception because the query component contain i=
nvalid characters or
is it acceptable ? Asking because currently our dear old parse_url does not=
 fail on this and
probably most PHP developers expect this not to fail.

IMHO I am in favor of it failing to get a consistent experience when using =
the class because
otherwse you introduce an inconsistency between the constructor behaviour a=
nd the rest of the class
API.</pre></div></div></blockquote><div><br></div><div>Yes, generally, crea=
tion or any mutation of Uri\Rfc3986\Uri fails when the URI is invalid, exac=
tly in order to offer a consistent experience.</div><div>=C2=A0</div><div>R=
egards,</div><div>M=C3=A1t=C3=A9</div></div></div><div class=3D"gmail_quote=
 gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>

--00000000000040488e063238342b--