Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115634
MIME-Version: 1.0
Date: Fri, 6 Aug 2021 09:17:44 +0200
Message-ID: <CAOV5rgZSeSS89kV8jgt+Deyu9vHF-n5JQ+X9ab+ZVjjUCWeRPQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000098d60e05c8ded523"
Subject: [RFC] Add parse_query_string as an alternative to parse_str
From: nyamsprod@gmail.com (ignace nyamagana butera)

--00000000000098d60e05c8ded523
Content-Type: text/plain; charset="UTF-8"

Hi Kamil Tekiela,

I read your RFC and I understand the intent in improving the current
parse_str function behaviour by introducing a new function to
avoid possible breakage,
However I feel that we are missing a chance to also improve how parse_str
algorithm is currently used, we could or should (?) use this opportunity
to fix some long shortcomings around parse_str.

In no particular order:

parse_str mangled data while it was acceptable before when it could
directly inject PHP variables into the current scope, this
feature is no longer needed and prevents interoperability with other query
parsing algorithms used in other languages. Also since this mangled data
is not well known it comes as a surprise to average PHP developer as the
behaviour feels unexpected see https://3v4l.org/KIJ9V

parse_str assumes that the query separator is always a "&" which reduces
its usage to only parsing query using that particular character. Again this
might be seen as an edge case but no RFC prevents using any other
character. If you where to use another character you are bound to use some
userland code workaround to then feed the "normalized" string to parse_str

parse_str parse the query string using PHP algorithm while there are now
some established parsing algorithm that are languages independant like
https://url.spec.whatwg.org/#interface-urlsearchparams that defines how a
query string should be parsed.

If we were to introduce your function as is, I feel that we will have to
submit yet another RFC and have a language with at least two ways to parse
a string. So maybe instead of a new function what we need is an object with
a better public API ?  thoughts

--00000000000098d60e05c8ded523--