Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130722
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
 <CAOV5rgZ1LTVf9PBpfQekahmESo=KXE=RVrpeUXrbqxG4OSDMnQ@mail.gmail.com>
 <d6a46bb627a9545e621f37e83c0441e5@glaive.pro> <CAOV5rgZGKJEo+jV7q-qQFB59CXhfNwadYPDbm70e_F+1v=Fgng@mail.gmail.com>
 <CAH5C8xWwcNC3z=FxQZiN2r1aZ1FgriVNAtdw+YwhaN4S2joyzw@mail.gmail.com>
 <CAOV5rgaLX9s-=WZZgxoTE4wmWEzL9mZUF-d8bzGrN3BQDU7i3w@mail.gmail.com>
 <CAOV5rgY3+PrOk2sH0iZ2ne1wg1WVzW4evh6qwu1nyq68tMH-9A@mail.gmail.com>
 <CAH5C8xUEBtywOxgV4zgHVhdzO0KoFejtp04q0LQ+bEAb9nUAvw@mail.gmail.com>
 <CAOV5rgaGjJ+_Qa10pVaCYD_aozV10+UHvLUuVuNOXTz87xHpXA@mail.gmail.com>
 <CAOV5rgZ5y6YF3hLeDAc8TcaOyxkbbF7S0U7R7JMx8Cwff=3QGA@mail.gmail.com>
 <CAH5C8xXAtUN0ja_thZqbN4u4nndr2Lp_SxqZT3E+WN5ASFqWSA@mail.gmail.com>
 <CAH5C8xVjx1v_CX+5O4sj7CVyJOx4rDASvuqOukWfgupPa=YtGA@mail.gmail.com>
 <CAOV5rgbsDscEffqiv+c7WThN-Aj0xhL0w5eE13ALY_F5Kmcwmg@mail.gmail.com>
 <CAH5C8xXXrY5iPuAcL0XXYDoRPh=Tz0m7xhszspNqXnfVmM_aAQ@mail.gmail.com>
 <1fee2f46-27b7-4eb2-908f-b38f8c78d8c9@bastelstu.be> <CAH5C8xVxMt3n-GbK5ac0E1QjLF_S9-ZhPrnOtcMoh-BQxMBwRQ@mail.gmail.com>
In-Reply-To: <CAH5C8xVxMt3n-GbK5ac0E1QjLF_S9-ZhPrnOtcMoh-BQxMBwRQ@mail.gmail.com>
Date: Thu, 30 Apr 2026 21:19:11 +0200
Message-ID: <CAH5C8xWAUcforsq4UyjbJt_RU3KVqtdjB3gGGHTRxvCevEwigg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: ignace nyamagana butera <nyamsprod@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007eb8d30650b257cf"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000007eb8d30650b257cf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace, Tim et al.,

I've finished updating the RFC once again, after some private discussion
with Tim:

It turned out that the percent-decoding feature as proposed would have led
to confusing behavior
in some cases. In order to avoid this, I ultimately removed the
percent-decoding support from the
proposal. In the same time, I pivoted from the "instance methods on an
enum=E2=80=9D based approach
to a simple namespaced function based solution, because the enums would
only ever have a single
method (even if decoding support is added later, possibly not all the
(Uri|Url)PercentEncoder enum cases
would be applicable for decoding). Let me know if this doesn't work for
you, TBH adding namespaced
functions was my least favorite solution, but I didn't have any
significantly better idea which would have had
the potential to gain traction.

I have called out one example in the RFC (
https://wiki.php.net/rfc/uri_followup#percent-encoding_support) which
would be problematic if we had a Uri\Rfc3986\uri_percent_decode() function,
so let me copy-paste it here for reference:

$uri =3D new Uri\Rfc3986\Uri("https://example.com/?a=3Db%26c");  // The que=
ry
is the percent-encoded form of "a=3Db&c=3Dd"

echo Uri\Rfc3986\uri_percent_decode(
    $uri->getQuery(),
    Uri\Rfc3986\UriPercentEncodingMode::Query
);
                         // a=3Db&c

The result is probably not what we expected, because percent-decoding
changed the meaning of the query component:
- Originally, the query contained a parameter =E2=80=9Ca=E2=80=9D with valu=
e =E2=80=9Cb%26c=E2=80=9D (=E2=80=9Cb&c=E2=80=9D)
- Now, there is a parameter =E2=80=9Ca=E2=80=9D with value =E2=80=9Cb=E2=80=
=9D, as well as a parameter =E2=80=9Cc=E2=80=9D
without value

And I'm now attempting once again to announce my intention to start the
vote:
If no significant issue comes up this time, then I'll start the vote next
Tuesday evening (according to UTC).

Regards,
M=C3=A1t=C3=A9

--0000000000007eb8d30650b257cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ignace, Tim et al.,<div><br></div><div=
>I&#39;ve finished updating the RFC once again, after some private discussi=
on with Tim:</div><div><br></div><div>It turned out that the percent-decodi=
ng feature as proposed would have led to confusing behavior</div><div>in so=
me cases. In order to avoid this, I ultimately removed the percent-decoding=
 support from the</div><div>proposal. In the same time, I pivoted from the =
&quot;instance methods on an enum=E2=80=9D based approach</div><div>to a si=
mple namespaced function based solution, because the enums would only ever =
have a single</div><div>method (even if decoding support is added later, po=
ssibly not all the (Uri|Url)PercentEncoder enum cases</div><div>would be ap=
plicable for decoding). Let me know if this doesn&#39;t work for you, TBH a=
dding namespaced</div><div>functions was my least favorite solution, but I =
didn&#39;t have any significantly better idea which would have had</div><di=
v>the potential to gain traction.</div><div><br></div><div>I have called ou=
t one example in the RFC (<a href=3D"https://wiki.php.net/rfc/uri_followup#=
percent-encoding_support" target=3D"_blank">https://wiki.php.net/rfc/uri_fo=
llowup#percent-encoding_support</a>) which</div><div>would be problematic i=
f we had a Uri\Rfc3986\uri_percent_decode() function, so let me copy-paste =
it here for reference:</div><div><br></div><div>$uri =3D new Uri\Rfc3986\Ur=
i(&quot;<a href=3D"https://example.com/?a=3Db%26c">https://example.com/?a=
=3Db%26c</a>&quot;); =C2=A0// The query is the percent-encoded form of &quo=
t;a=3Db&amp;c=3Dd&quot;<br><br>echo Uri\Rfc3986\uri_percent_decode(<br>=C2=
=A0 =C2=A0 $uri-&gt;getQuery(),<br>=C2=A0 =C2=A0 Uri\Rfc3986\UriPercentEnco=
dingMode::Query<br>);=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 =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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0// a=3Db&amp;c</div><div><br></div><div>The result is probably not what =
we expected, because percent-decoding changed the meaning of the query comp=
onent:<br>- Originally, the query contained a parameter =E2=80=9Ca=E2=80=9D=
 with value =E2=80=9Cb%26c=E2=80=9D (=E2=80=9Cb&amp;c=E2=80=9D)<br>- Now, t=
here is a parameter =E2=80=9Ca=E2=80=9D with value =E2=80=9Cb=E2=80=9D, as =
well as a parameter =E2=80=9Cc=E2=80=9D without value</div><div><br></div><=
div>And I&#39;m now attempting once again to announce=C2=A0my intention=C2=
=A0to start the vote:</div><div>If no significant issue comes up this time,=
 then I&#39;ll start the vote next Tuesday evening (according to UTC).</div=
><div><br></div><div>Regards,</div><div>M=C3=A1t=C3=A9</div><div><br></div>=
</div><div 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-le=
ft:1ex">
</blockquote></div>
</div>

--0000000000007eb8d30650b257cf--