Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115638
MIME-Version: 1.0
References: <CAOV5rgZSeSS89kV8jgt+Deyu9vHF-n5JQ+X9ab+ZVjjUCWeRPQ@mail.gmail.com>
In-Reply-To: <CAOV5rgZSeSS89kV8jgt+Deyu9vHF-n5JQ+X9ab+ZVjjUCWeRPQ@mail.gmail.com>
Date: Fri, 6 Aug 2021 09:28:11 +0100
Message-ID: <CAJvSBVNFet1_HerapBPsCz-Q_MyyWnc84jvfmWGgyPY188OG_Q@mail.gmail.com>
To: ignace nyamagana butera <nyamsprod@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000fb4b605c8dfd370"
Subject: Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
From: phpmailinglists@gmail.com (Peter Bowyer)

--0000000000000fb4b605c8dfd370
Content-Type: text/plain; charset="UTF-8"

On Fri, 6 Aug 2021 at 08:18, ignace nyamagana butera <nyamsprod@gmail.com>
wrote:

> 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:
>

I agree that the first 2 shortcomings ought to be addressed in a
HTTP-focused parse_str alternative. The first has been an annoyance, as
some querystrings use '.' to denote an array, in the way PHP chooses []. So
foo.bar would mean foo[bar] in PHP-speak.

The third I won't comment on as I don't know the Url algorithm.

Peter

--0000000000000fb4b605c8dfd370--