From my POV this looks like a feature but not a BC break. At least I can't imagine how this can break sth. 🤷🏼‍♂️😅

@OskarStark I kinda agree but BC can be a touchy/tough subject so better to bring up the question early.

💐 -- very personal and opiniated message here -- 💐

To me it can be seen as a major BC break... as values would be changed here.

A query string is a map of key => value,... so the order of keys has no meaning. And reordering them has no impact on the data.

But the suggested change would modify the values, and i think this is something that would be really hard to justify.

Wether someone consider nested values as an hash, a map, a string, should not be guessed by the framework.

And as those values are not consider Identical in PHP, i do think this change is hard to justify.

$foo1 = ['key' => ['a' => 'A', 'b' => 'B']];
$foo2 = ['key' =>  ['b' => 'B', 'a' => 'A']];

var_dump($foo1 === $foo2); // FALSE
var_dump($foo1 == $foo2); // true

$foo2 = ['key' =>  ['b' => 'B', 'a' => 'A']]; // true
$foo3 = ['key' => ['b' => 'B', 'a' => 'A']]; // true

var_dump($foo2 === $foo3);
var_dump($foo2 == $foo3);

But i understand clearly the expected usage here, and can imagine how it would ease DX in several cases...

So... what about some "getNormalizedQuery" method

(or any better name, but you got the idea), that would avoid any BC ?

@smnandre Thanks for the input. I understand your point about hashes, however I don't really get this:

But the suggested change would modify the values, and i think this is something that would be really hard to justify.

We're not changing any values, unless you consider the specific order of K/V pairs in an array to be a "value." I suppose there could be some discussion around whether the ordering of multiple values such as a[]=1&a[]=2 should carry meaning from the client side in their order... but that's very brittle.

You provide an example of comparing two arrays for strict equivalence, but I don't believe that example really carries much water when we're talking about query string parameters. Because their order may be determined by the client, server implementations shouldn't depend on such comparisons but rather look at the values overall or doing something more like in_array($request->query->all('a')).

a[]=1&a[]=2 should carry meaning from the client side in their order...

I was thinking the same about ordering: your proposal would reorder things like a[foo]=1&a[bar]=2, and I'm very confident that there are UIs out there that do use Symfony and that do rely on the ordering (eg when providing a UI to order rows in a table). I don't think that's brittle - it just works and has no reason to be unpredictable.

This means I'm on the 👎 side of this proposal, it might be acceptable in Drupal, but in the more generic case of Symfony, I don't think so.

What about

- public static function normalizeQueryString(?string $qs): string
+ public static function normalizeQueryString(?string $qs, bool $recursive = false): string

to prevent BC

@nicolas-grekas Yeah, that's fair and why I anticipated some discussion on this point. The proposal for a recursive option to ::normalizeQueryString() is what I had first thought of, and perhaps that's still in play.

Making this optional would work for me. Inorder to not break BC, the argument should be added using @param only and be accessed using func_get_arg

Closing as there is no more activity and the current patch cannot be merged as is.
Feel free to reopen if that still makes sense.