[HttpFoundation] Don't reorder nested query string keys #26214
Conversation
8e64fe7 to
2abcf97
Compare
|
I don't understand why some keys should be ordered while others should not. I understand it for the specific use case described, but I fail to see why this should a good thing in general. The goal of this method is to ensure that 2 URLs stay equivalent even if query parameters are reordered or encoding is different. In any case, it looks like a BC break to me. |
2abcf97 to
542dcce
Compare
|
A basic requirement of any normalization process is to not remove any useful information from the original data. |
|
I do understand the changes made here. But this IS a BC break. So, no way we merge this into 2.7. |
|
OK, let's fix this on master |
…malization (nicolas-grekas) This PR was merged into the 4.1-dev branch. Discussion ---------- [HttpFoundation] Use parse_str() for query strings normalization | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Follow up of #26214 and #26202 The current normalization logic is both too loose and too broad: it changes the order of recursive data structures, while not normalizing keys. Since the normalization logic varies by query string parser, I'd like to propose a logic that exactly matches the native PHP one, which is exposed to userland via `parse_str()`. Using this, we accurately remove all useless information, while preserving all the meaningful one. (The change in `overrideGlobals()` is a bug fix to me btw, the current logic breaks the interpretation of legitimate query strings.) Commits ------- 5133536 [HttpFoundation] Use parse_str() for query strings normalization
Normalization shouldn't apply to recursive structures.
Replaces #26202