Re: [RFC] Add parse_query_string as an alternative to parse_str

From: Date: Fri, 06 Aug 2021 10:06:23 +0000
Subject: Re: [RFC] Add parse_query_string as an alternative to parse_str
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-115640@lists.php.net to get a copy of this message
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 >

« previous php.internals (#115640) next »