Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115640
MIME-Version: 1.0
References: <CAOV5rgZSeSS89kV8jgt+Deyu9vHF-n5JQ+X9ab+ZVjjUCWeRPQ@mail.gmail.com>
 <CAJvSBVNFet1_HerapBPsCz-Q_MyyWnc84jvfmWGgyPY188OG_Q@mail.gmail.com>
In-Reply-To: <CAJvSBVNFet1_HerapBPsCz-Q_MyyWnc84jvfmWGgyPY188OG_Q@mail.gmail.com>
Date: Fri, 6 Aug 2021 12:06:23 +0200
Message-ID: <CAJmy8YFC2L1vX=grQhXtS0_sV28-k6rMJT0z96mYgU1J+_Z25g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000439a1905c8e132a0"
Subject: Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
From: divinity76@gmail.com (Hans Henrik Bergan)

--000000000000439a1905c8e132a0
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

On Fri, 6 Aug 2021 at 10:29, Peter Bowyer <phpmailinglists@gmail.com> wrote:

> 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
>

--000000000000439a1905c8e132a0--