Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129492
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
In-Reply-To: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
Date: Mon, 1 Dec 2025 23:14:01 +0100
Message-ID: <CAOV5rgZ+NQnmFmWtTqXmN0fmDjgrGxWO=z_o_fpO6P4GXk+HUQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008fbcfb0644eb4c31"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--0000000000008fbcfb0644eb4c31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi M=C3=A1t=C3=A9,
Once again thanks for this follow up RFC. While there are a lot to digest I
wanted to point out your reservation around implementing the
IteratorAggregate interface for Query Manipulation,

The UriQueryParams and UrlQueryParams classes could implement the
> IteratorAggregate interface in theory. However, it's not possible to do s=
o
> due to query components that share the same name, e.g.:
> param=3Dfoo&param=3Dbar&param=3Dbaz. In this case, the same key (param) w=
ould be
> repeated 3 times - and it's actually not possible to support with iterato=
rs.
>
>
When building the Query component in league URI I was able to use the
Countable and IteratorAggregate interface using a different representation
of the query pair see
https://uri.thephpleague.com/components/7.0/query/#countable-and-iteratorag=
gregate
TL;DR instead of using your proposed structure

[['name' =3D> 'value'],...]

I used the following

[['name', 'value'], ...]

While both format IMHO can allow implementing the IteratorAggregate
interface, the latter allows for a more predictable API

```php
$uri =3D new Uri('https://example.com?param=3Dfoo&param=3Dbar&param=3Dbaz')=
;
foreach ($uri->getQueryParams() as $key =3D> $pair) {
    //first iteration $pair['param'] =3D 'foo'
    //second iteration $pair['param'] =3D 'bar'
    //third iteration $pair['param'] =3D 'baz'
}
```

The user needs to know beforehand the name of the pair which is counter
intuitive if you do not know the exact position
of the pair. In contrast, using the league URI query syntax you will have
the following:

$uri =3D new Uri('https://example.com?param=3Dfoo&param=3Dbar&param=3Dbaz')=
;
Query::fromUri($uri);
foreach (Query::fromUri($uri) as $key =3D> $pair) {
    //first iteration $pair[0] =3D 'param'; $pair[1] =3D 'foo'
    //second iteration $pair[0] =3D 'param'; $pair[1] =3D 'baz'
    //third iteration $pair[0] =3D 'param'; $pair[1] =3D 'bar'
}
```

The user will always get the parameter name using $pair[0] and the value
using $pair[1] regardless of their content and value.

What do you think ? This IMHO would solve your issue but it is indeed a
stronger departure to how query strings are parsed in PHP currently.

Best regards.

On Mon, Dec 1, 2025 at 9:53=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis <kocsismate90@=
gmail.com> wrote:

> Hi Everyone,
>
> I'd like to introduce my latest RFC that I've been working on for a while
> now: https://wiki.php.net/rfc/uri_followup.
>
> It proposes 5 followup improvements for ext/uri in the following areas:
> - URI Building
> - Query Parameter Manipulation
> - Accessing Path Segments as an Array
> - Host Type Detection
> - URI Type Detection
> - Percent-Encoding and Decoding Support
>
> I did my best to write an RFC that was at least as extensive as
> https://wiki.php.net/rfc/url_parsing_api had become by the end. Despite
> my efforts,
> there are still a couple things which need a final decision, or which
> need to be polished/improved. Some examples:
>
> - How to support array/object values for constructing query strings? (
> https://wiki.php.net/rfc/uri_followup#type_support)
> - How to make the UriQueryParams and UrlQueryParams classes more
> interoperable with the query string component (mainly with respect to
> percent-encoding)? (
> https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding)
> - Exactly how the advanced percent-decoding capabilities should work? Doe=
s
> it make sense to support all the possible modes (UriPercentEncodingMode)
> for percent-decoding as well (
> https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_suppo=
rt
> )
> - etc.
>
> Regards,
> M=C3=A1t=C3=A9
>

--0000000000008fbcfb0644eb4c31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi=C2=A0M=C3=A1t=C3=A9,<div>Once again thanks for this fol=
low up RFC. While there are a lot to digest I wanted to point out your rese=
rvation around implementing the IteratorAggregate interface for Query Manip=
ulation,=C2=A0</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">The UriQueryParams and UrlQueryParams classes could implement th=
e IteratorAggregate interface in theory. However, it&#39;s not possible to =
do so due to query components that share the same name, e.g.: param=3Dfoo&a=
mp;param=3Dbar&amp;param=3Dbaz. In this case, the same key (param) would be=
 repeated 3 times - and it&#39;s actually not possible to support with iter=
ators.<br><br></blockquote><div>=C2=A0</div><div>When building the Query co=
mponent in league=C2=A0URI I was able to use the Countable and IteratorAggr=
egate interface using a different representation of the query pair see=C2=
=A0<a href=3D"https://uri.thephpleague.com/components/7.0/query/#countable-=
and-iteratoraggregate">https://uri.thephpleague.com/components/7.0/query/#c=
ountable-and-iteratoraggregate</a></div><div>TL;DR instead of using your pr=
oposed structure=C2=A0</div><div><br></div><div>[[&#39;name&#39; =3D&gt; &#=
39;value&#39;],...]</div><div><br></div><div>I used the following</div><div=
><br></div><div>[[&#39;name&#39;, &#39;value&#39;], ...]</div><div><br></di=
v><div>While both format IMHO can allow implementing the IteratorAggregate =
interface, the latter allows for a more predictable=C2=A0API</div><div><br>=
</div><div>```php</div>$uri =3D new Uri(&#39;<a href=3D"https://example.com=
?param=3Dfoo&amp;param=3Dbar&amp;param=3Dbaz&#39;">https://example.com?para=
m=3Dfoo&amp;param=3Dbar&amp;param=3Dbaz&#39;</a>);<br>foreach ($uri-&gt;get=
QueryParams() as $key =3D&gt; $pair) {<br>=C2=A0 =C2=A0 //first iteration $=
pair[&#39;param&#39;] =3D &#39;foo&#39;<br>=C2=A0 =C2=A0 //second iteration=
 $pair[&#39;param&#39;] =3D &#39;bar&#39;<br>=C2=A0 =C2=A0 //third iteratio=
n $pair[&#39;param&#39;] =3D &#39;baz&#39;<br>}<br>```<div><br>The user nee=
ds to know beforehand the name of the pair which is counter intuitive if yo=
u do not know the exact position<div>of the pair. In contrast, using the le=
ague URI query syntax you will have the following:</div><div><br>$uri =3D n=
ew Uri(&#39;<a href=3D"https://example.com?param=3Dfoo&amp;param=3Dbar&amp;=
param=3Dbaz&#39;">https://example.com?param=3Dfoo&amp;param=3Dbar&amp;param=
=3Dbaz&#39;</a>);<br>Query::fromUri($uri);<br>foreach (Query::fromUri($uri)=
 as $key =3D&gt; $pair) {<br>=C2=A0 =C2=A0 //first iteration $pair[0] =3D &=
#39;param&#39;; $pair[1] =3D &#39;foo&#39;<br>=C2=A0 =C2=A0 //second iterat=
ion $pair[0] =3D &#39;param&#39;; $pair[1] =3D &#39;baz&#39;<br>=C2=A0 =C2=
=A0 //third iteration $pair[0] =3D &#39;param&#39;; $pair[1] =3D &#39;bar&#=
39;<br><div>}</div><div>```</div><div><br></div><div>The user will always g=
et the parameter name using $pair[0] and the value using $pair[1] regardles=
s of their content and value.</div><div><br></div><div>What do you think ? =
This IMHO would solve your issue but it is indeed a stronger departure to h=
ow query strings are parsed in PHP currently.</div><div><br></div><div>Best=
 regards.</div></div></div></div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 1, 2025 at 9:5=
3=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis &lt;<a href=3D"mailto:kocsismate90@gmail=
.com">kocsismate90@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Everyone,<div><br></div><di=
v>I&#39;d like to introduce my latest RFC that I&#39;ve been working on for=
 a while now: <a href=3D"https://wiki.php.net/rfc/uri_followup" target=3D"_=
blank">https://wiki.php.net/rfc/uri_followup</a>.</div><div><br></div><div>=
It proposes 5=C2=A0followup=C2=A0improvements for ext/uri in the following =
areas:</div><div>- URI Building<br>- Query Parameter Manipulation<br>- Acce=
ssing Path Segments as an Array<br>- Host Type Detection<br>- URI Type Dete=
ction<br>- Percent-Encoding and Decoding Support</div><div><br></div><div>I=
 did my best to write an RFC that was at least as extensive as=C2=A0<a href=
=3D"https://wiki.php.net/rfc/url_parsing_api" target=3D"_blank">https://wik=
i.php.net/rfc/url_parsing_api</a> had become by the end. Despite my efforts=
,</div><div>there are still a couple things which need=C2=A0a final decisio=
n, or which need=C2=A0to be polished/improved. Some examples:</div><div><br=
></div><div>- How to support array/object values for constructing query str=
ings? (<a href=3D"https://wiki.php.net/rfc/uri_followup#type_support" targe=
t=3D"_blank">https://wiki.php.net/rfc/uri_followup#type_support</a>)</div><=
div>- How to make the UriQueryParams and=C2=A0UrlQueryParams classes more i=
nteroperable with the query string component (mainly with respect to percen=
t-encoding)? (<a href=3D"https://wiki.php.net/rfc/uri_followup#percent-enco=
ding_and_decoding" target=3D"_blank">https://wiki.php.net/rfc/uri_followup#=
percent-encoding_and_decoding</a>)</div><div>- Exactly how the advanced per=
cent-decoding capabilities should work? Does it make sense to support all t=
he possible modes (UriPercentEncodingMode) for percent-decoding as well (<a=
 href=3D"https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decodin=
g_support" target=3D"_blank">https://wiki.php.net/rfc/uri_followup#percent-=
encoding_and_decoding_support</a>)</div><div>- etc.</div><div><br></div><di=
v>Regards,</div><div>M=C3=A1t=C3=A9</div></div>
</blockquote></div>

--0000000000008fbcfb0644eb4c31--