Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri

[ignace nyamagana butera]

Hi Máté,
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 so
> due to query components that share the same name, e.g.:
> param=foo&param=bar&param=baz. In this case, the same key (param) would be
> repeated 3 times - and it's actually not possible to support with iterators.
>
>
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-iteratoraggregate
TL;DR instead of using your proposed structure

[['name' => '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 = new Uri('https://example.com?param=foo&param=bar&param=baz');
foreach ($uri->getQueryParams() as $key => $pair) {
    //first iteration $pair['param'] = 'foo'
    //second iteration $pair['param'] = 'bar'
    //third iteration $pair['param'] = '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 = new Uri('https://example.com?param=foo&param=bar&param=baz');
Query::fromUri($uri);
foreach (Query::fromUri($uri) as $key => $pair) {
    //first iteration $pair[0] = 'param'; $pair[1] = 'foo'
    //second iteration $pair[0] = 'param'; $pair[1] = 'baz'
    //third iteration $pair[0] = 'param'; $pair[1] = '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 PM Máté Kocsis <kocsismat...@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? Does
> 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_support
> )
> - etc.
>
> Regards,
> Máté
>