Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115641
MIME-Version: 1.0
References: <CAOV5rgZSeSS89kV8jgt+Deyu9vHF-n5JQ+X9ab+ZVjjUCWeRPQ@mail.gmail.com>
 <CAJvSBVNFet1_HerapBPsCz-Q_MyyWnc84jvfmWGgyPY188OG_Q@mail.gmail.com> <CAJmy8YFC2L1vX=grQhXtS0_sV28-k6rMJT0z96mYgU1J+_Z25g@mail.gmail.com>
In-Reply-To: <CAJmy8YFC2L1vX=grQhXtS0_sV28-k6rMJT0z96mYgU1J+_Z25g@mail.gmail.com>
Date: Fri, 6 Aug 2021 12:12:58 +0100
Message-ID: <CAGBsUrej70Hu-+1q7A_ZsUci4JmcPO-=7f_QVeQN=d5in4_rGQ@mail.gmail.com>
To: Hans Henrik Bergan <divinity76@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c0346505c8e21e27"
Subject: Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
From: tekiela246@gmail.com (Kamil Tekiela)

--000000000000c0346505c8e21e27
Content-Type: text/plain; charset="UTF-8"

btw why isn't foo.bar=123 decoded to array("foo.bar"=>123);  ?
> this looks pretty bad to me https://3v4l.org/6Wa23


Hi Hans,

This is because variables in PHP that contain the concatenation operator or
space are much more difficult to access. See https://3v4l.org/vUBWK
As the primary purpose of parse_str was to register globals from a query
string, it follows the same logic as your normal POST/GET/COOKIE parsing.
See https://stackoverflow.com/a/68742/1839439
Perhaps, instead of adjusting this behaviour only for the new function, we
could remove this behaviour as a whole, given that it is a remainder of the
long-forgotten register globals? I don't see any use for it anymore, as all
parsed input is only available in the form of an associative array. People
who extract $_POST can suffer the consequences of their own actions...

Regards,
Kamil

--000000000000c0346505c8e21e27--