Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115639
MIME-Version: 1.0
References: <7DA18959-3463-4AAE-ABE3-B9330FEE83D2@gmail.com>
 <CAGBsUrfoAT4CeiJvbNDczjiqRLLikdvmCfYe2BdUQDZudZ2w4w@mail.gmail.com>
 <A4C46EDC-5D29-4F3C-8F88-25C86D49B4B8@newclarity.net> <0def35e8-f527-3362-2821-2535bc16f8c8@alec.pl>
In-Reply-To: <0def35e8-f527-3362-2821-2535bc16f8c8@alec.pl>
Date: Fri, 6 Aug 2021 14:58:11 +0530
Message-ID: <CANLbj-pwWhR5vviMGT62YP-b+qDC_=C278ot5D5x8oKpW0_Hwg@mail.gmail.com>
To: Aleksander Machniak <alec@alec.pl>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
From: ayesh@php.watch (Ayesh Karunaratne)

> I agree about the _string suffix removal. However, I know we have
> parse_url() already, but parse_query() might be too generic. I would
> suggest adding "http" to the name. And as we already have
> http_build_query() I would rather see http_parse_query().
>

+1 for http_parse_query() as it sounds a lot more natural and consistent.

> 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

Both `http_build_query` and `parse_str` respect the
`arg_separator.input` [INI
setting](https://www.php.net/manual/en/ini.core.php#ini.arg-separator.input).
If we were to go for a `http_parse_query`, I think it makes sense to
support the same behavior and parameters.

Thank you,
Ayesh.