Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129668
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
 <83238ad3-c844-4457-dfb3-11321787e022@php.net> <CAH5C8xUOEkfQ6u8AxuV8UGjWU0h7goDsvWa9QQmANhNdU=Dwhw@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>
In-Reply-To: <CAOV5rgY3+PrOk2sH0iZ2ne1wg1WVzW4evh6qwu1nyq68tMH-9A@mail.gmail.com>
Date: Sun, 21 Dec 2025 13:13:46 +0100
Message-ID: <CAH5C8xUEBtywOxgV4zgHVhdzO0KoFejtp04q0LQ+bEAb9nUAvw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: ignace nyamagana butera <nyamsprod@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000badae40646753e38"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000badae40646753e38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace,


> When I talk about data mangling I am talking about this


> parse_str('foo.bar=3Dbaz', $params);
> var_dump($params); //returns ['foo_bar' =3D> 'baz']


Sure! I just wanted to point it out that name mangling will still be
present due to arrays, and this will have some disadvantages,
namely that adding params and retrieving them won't be symmetric:

$params =3D new Uri\Rfc3986\UriQueryParams()
    ->append("foo", [2 =3D> "bar", 4 =3D> "baz"]);

var_dump($params->getFirst("foo"));                   // NULL

One cannot be sure if a parameter that was added can really be retrieved
later via a get*() method.

Another edge cases:

$params =3D new Uri\Rfc3986\UriQueryParams()
    ->append("foo", ["bar", "baz"])                          // Value is a
list, so "foo" is added without brackets
    ->append("foo", [2 =3D> "qux", 4 =3D> "quux"]);      // Value is an arr=
ay,
so "foo" is added with brackets

var_dump($params->toRfc3986String());            //
foo=3Dbar&foo=3Dbaz&foo%5B2%5D=3Dqux&foo%5B4%5D=3Dquux

var_dump($params->getLast("foo"))                   // Should it be "baz"
or "quux"?
var_dump($params->getAll("foo"))                     // Should it only
include the params with name "foo", or also "foo[]"?

And of course this behavior also makes the implementation incompatible with
the WHATWG URL specification: although I do think this part of
the specification is way too underspecified and vague, so URLSearchParams
doesn't seem well-usable in practice...

So an idea that I'm now pondering about is to keep the append() and set()
methods compatible with WHATWG: and they would only support
scalar values, therefore the param name wasn't mangled. And an extra
appendArray() and setArray() method could be added that would possible
mangle the param names, and they would only support passing arrays. This
solution would hopefully result in a slightly less surprising
behavior: one could immediately know if a previously added parameter is
really retrievable (when append() or set() was used), or extra
checks may be needed (when using appendArray() or setArray()).


> This to me should yield the same result as ->append('foo', null);  as the
> array construct is only indicative of a repeating parameter name
> if there is no repeat then it means no data is attached to the name.


Alright, that seems the least problematic solution indeed, and
http_build_query() also represents empty arrays just like null values
(omitting them).

So in your implementation it would mean:
>
> allowed type: null, int, float, string, boolean, and Backed Enum (to mini=
c
> json_encode and PHP8.4+ behaviour)
> arrays with values containing valid allowed type or array. are also
> supported to allow complex type support.
>
> Any other type (object, resource, Pure Enum)  are disallowed they should
> throw a TypeError
>

+1


> Maybe in the future scope of this RFC or in this RFC depending on how you
> scope the RFC you may introduce an Interface which will allow serializing
> objects using a representation that
> follows the described rules above. Similar to what the
> JsonSerializable interface is for json_encode.
>

Hm, good idea! I'm not particularly interested in this feature, but I agree
it's a good way to add support for objects.

Last but not Last, all this SHOULD not affect how http_buid_query works.
> The function should never have been modified IMHO so it should be left
> untouched by all this except if we allow it
> to opt-in the behaviour once the interface is approved and added to PHP.
>

+1

Regards,
M=C3=A1t=C3=A9

--000000000000badae40646753e38
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>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">When I talk about data mangling I am talking about this</blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><br>parse_str(&#39;foo.bar=
=3Dbaz&#39;, $params);<br>var_dump($params); //returns [&#39;foo_bar&#39; =
=3D&gt; &#39;baz&#39;]</blockquote><div><br></div><div>Sure! I just wanted =
to point it out that name mangling will still be present due to arrays, and=
 this will have some disadvantages,</div><div>namely that adding params and=
 retrieving them won&#39;t be symmetric:</div><div><br></div><div><div>$par=
ams =3D new Uri\Rfc3986\UriQueryParams()<br>=C2=A0 =C2=A0 -&gt;append(&quot=
;foo&quot;, [2 =3D&gt; &quot;bar&quot;, 4 =3D&gt; &quot;baz&quot;]);<br></d=
iv><div><br></div><div>var_dump($params-&gt;getFirst(&quot;foo&quot;));=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// NULL</=
div></div><div><br></div><div>One cannot be sure if a parameter that was ad=
ded can really be retrieved later via a get*() method.</div><div><br></div>=
<div>Another edge cases:</div><div><br></div><div><div>$params =3D new Uri\=
Rfc3986\UriQueryParams()<br>=C2=A0 =C2=A0 -&gt;append(&quot;foo&quot;, [&qu=
ot;bar&quot;, &quot;baz&quot;])=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 // Value is a list, so &qu=
ot;foo&quot; is added without brackets</div><div>=C2=A0 =C2=A0 -&gt;append(=
&quot;foo&quot;, [2 =3D&gt; &quot;qux&quot;, 4 =3D&gt; &quot;quux&quot;]);=
=C2=A0 =C2=A0 =C2=A0 // Value is an array, so &quot;foo&quot; is added with=
 brackets<br></div><div><br></div><div>var_dump($params-&gt;toRfc3986String=
());=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // foo=3Dbar&amp;foo=3Dbaz&am=
p;foo%5B2%5D=3Dqux&amp;foo%5B4%5D=3Dquux</div></div><div><br></div><div>var=
_dump($params-&gt;getLast(&quot;foo&quot;))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Should it be &quot;baz&quot; or &q=
uot;quux&quot;?</div><div>var_dump($params-&gt;getAll(&quot;foo&quot;))=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//=
 Should it only include the params with name &quot;foo&quot;, or also &quot=
;foo[]&quot;?</div><div><br></div><div>And of course this behavior also mak=
es the implementation incompatible with the WHATWG URL specification: altho=
ugh I do think this part of</div><div>the specification is way too underspe=
cified and vague, so URLSearchParams doesn&#39;t seem well-usable in practi=
ce...</div><div><br></div><div>So an idea that I&#39;m now pondering about =
is to keep the append() and set() methods compatible with WHATWG: and they =
would only support</div><div>scalar values, therefore the param name wasn&#=
39;t mangled. And an extra appendArray() and setArray() method could be add=
ed that would possible</div><div>mangle the param names, and they would onl=
y support passing arrays. This solution would hopefully result in a slightl=
y=C2=A0less surprising</div><div>behavior: one could immediately know if a =
previously added parameter is really retrievable (when append() or set() wa=
s used), or extra</div><div>checks may be needed (when using appendArray() =
or setArray()).</div><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">This to me should yield the same result as -&gt;append(&#39;fo=
o&#39;, null); =C2=A0as the array construct is only indicative of a repeati=
ng parameter name<br>if there is no repeat then it means no data is attache=
d to the name. </blockquote><div><br></div><div>Alright, that seems the lea=
st problematic solution indeed, and http_build_query() also represents empt=
y arrays just like null values (omitting them).</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><div>So in your implementation it would mean:</div><div><br></d=
iv><div>allowed type: null, int, float, string, boolean, and Backed Enum (t=
o minic json_encode and PHP8.4+ behaviour)</div><div>arrays with values con=
taining valid allowed type or array. are also supported to allow complex ty=
pe support.</div><div><br></div><div>Any other type (object, resource, Pure=
 Enum)=C2=A0=C2=A0are disallowed they should throw a TypeError</div></div><=
/div></blockquote><div><br></div><div>+1<br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_quote"><div>Maybe in the future scope of this RFC or in this RFC depend=
ing on how you scope the RFC you may introduce=C2=A0an Interface which will=
 allow serializing objects using a representation that</div><div>follows th=
e described rules above. Similar to what the JsonSerializable=C2=A0interfac=
e is for json_encode.<br></div></div></div></blockquote><div><br></div><div=
>Hm, good idea! I&#39;m not particularly interested in this feature, but I =
agree it&#39;s a good way to add support for objects.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_quote"><div>Last but not Last, all this SHOULD not affect how ht=
tp_buid_query works. The function should never have been modified IMHO so i=
t should be left untouched by all this except if we allow it</div><div>to o=
pt-in the behaviour once the interface is approved and added to PHP.</div><=
/div></div></blockquote><div><br></div><div>+1</div><div>=C2=A0</div><div>R=
egards,</div><div>M=C3=A1t=C3=A9</div><div><br></div></div></div>

--000000000000badae40646753e38--