parse_str - replacing dot and space with underscore in keys

[otsch]

Description

I just remembered this behavior when using parse_str(), that dots and spaces in query string keys are replaced with underscore, for the reason that those aren't allowed in PHP variable names. From PHP 8 on the second argument $result is mandatory, so I think it now doesn't create variables in any case, right? So to me, replacing those characters in the resulting array keys, seems like a leftover that could be removed?

Example:

<?php

parse_str('foo.bar =baz', $array);

var_dump($array);

Currently results in:

array(1) {
  ["foo_bar_"]=>
  string(3) "baz"
}

Maybe better?

array(1) {
  ["foo.bar "]=>
  string(3) "baz"
}

PHP Version

PHP 8

Operating System

No response

[iluuu1994]

This would be a significant BC break and I'm not sure this change is worth it overall. Note that we have other functions like parse_url with notable issues that can't be fixed due to BC issues. It might be a good idea to introduce a completely new URL parsing API that is based on a stable library (like https://github.com/nodejs/llhttp or https://www.w3.org/Library/src/HTParse.html) to address these issues along with a better API.

In any case, this change would require an RFC as it is breaking. This is also documented behavior and thus not a bug.

[cmb69]

If we change the behavior of parse_str(), we may consider to change the general behavior of input parameters in this regard. Both would likely need a transition phase (raising some notice that the behavior will change).

[otsch]

I'm aware that it should be considered breaking, I wondered why it wasn't changed with making the second argument mandatory in PHP 8.

I like the idea of a new URL parsing API. I know that also parse_url isn't perfect, which is why I've actually built a url parsing library: https://github.com/crwlrsoft/url where I also implemented a workaround for dots in query string keys.
But I guess a whole new url parsing API would also be a pretty big scope.

In any case I'd suggest to either deprecate the behavior or maybe even the whole function (in case a new url parsing API will be built). If the method remains like this, I guess users will keep falling over this behavior. Yes, it's documented and I agree that it therefore actually isn't really a bug. But I guess you'd agree that it's at least very unintuitive and while it should be considered breaking, I'd guess hardly anybody would have a problem because of this, rather the opposite.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[weitzman]

FWIW, this has bitten me too. I think a BC break may be warranted. A new URL parsing library is nice but bigger scope than suggested here.