Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99061
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.128.179 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAPhkiZzzgmWcqsVPKghv89XU3+Ab06wcXbqeBc1MSh401_+etw@mail.gmail.com>
References: <CAPhkiZzzgmWcqsVPKghv89XU3+Ab06wcXbqeBc1MSh401_+etw@mail.gmail.com>
Date: Tue, 16 May 2017 14:28:21 -0500
Message-ID: <CAESVnVqrPuvWvBRL6KdJp=V8uSRSz3s_00P5n_t_VBmmKDTO_Q@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [Discussion] Dots and spaces in GPC variable names
From: pollita@php.net (Sara Golemon)

On Tue, May 2, 2017 at 5:56 AM, Andrey Andreev <narf@devilix.net> wrote:
> With parse_str() usage without a second parameter being deprecated, I
> was looking to possibly drop the behavior where it replaces spaces and
> dots with underscores in the result array, and ... As it often turns
> out - it's not that simple, because it re-uses the code that handles
> GPC vars.
>
> I didn't even know this mangling happened with GPC vars. I can only
> assume that's legacy from the the register_global days, as I certainly
> don't see a reason for it now. Am I missing something?
>
> And more importantly, can we change that? It's a significant BC break,
> yes, but the current behavior is horribly broken IMO.
>
BC breaking the default handling of GPCSE vars aside, I'd be 100% in
favor of either adding a flag param to parse_str() for this.

parse_str($_SERVER['QUERY_STRING'], $_GET, PARSE_STR_NOMANGLE);

-Sara

((Or add a new function which doesn't mangle and returns by value
rather than by ref because *ugh* at that by-ref semantic))