Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106232
MIME-Version: 1.0
References: <c-17aa9-jy55foba-cru125=b8ivs7@2.gethop.com> <CAF+90c9ZRT92UVK5ig_wkkgEzXAWG+fgYdNR6KGj8zKcuKRJ+A@mail.gmail.com>
 <CAEYWF=7+orYkB+K3Rp+tzhPk9bF9e99A8DHVcw++YYFLS6B5sA@mail.gmail.com>
In-Reply-To: <CAEYWF=7+orYkB+K3Rp+tzhPk9bF9e99A8DHVcw++YYFLS6B5sA@mail.gmail.com>
Date: Thu, 18 Jul 2019 12:08:36 +0200
Message-ID: <CADqTB_haS0xVkkQjkKunri_xKX+ixXE7eueZ5-x+ZUG=kzVdEg@mail.gmail.com>
To: bishop@php.net
Cc: Arnold Daniels <arnold.adaniels.nl@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000090b276058df1cb5a"
Subject: Re: [PHP-DEV] Stop replacing dots with underscores in query, post and
 cookie parameters for PHP 8?
From: rasmus@mindplay.dk (Rasmus Schultz)

--00000000000090b276058df1cb5a
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 16, 2019 at 2:34 PM Bishop Bettini <bishop@php.net> wrote:

> On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels <
> > arnold.adaniels.nl@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. This
> > > behavior once made sense because of Register globals. The explanation
> in
> > > the manual also still implies that query and post parameters are
> > converted
> > > to variables (see
> > >
> >
> https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names
> > ).
> > > Register globals has been removed since 5.4.0 and thus this behavior
> > serves
> > > little purpose.
> > >
> > > I think it would be good to remove the conversion in PHP 8, as it's a
> > > general cause of confusion and annoyance for anyone who comes across
> it.
> > >
> > > Is there a good reason to keep this behavior in PHP 8?
> > >
> >
> > This has been discussed a few times already, and I think that everyone
> > agrees that this behavior should go, but not necessarily on the migration
> > path. There is an RFC here:
> > https://wiki.php.net/rfc/on_demand_name_mangling
> > I think that the latest version of that RFC, that basically proposes to
> > drop the behavior and tell people to use a polyfill is fine.
> >
>
> I've readied the proposal for formal discussion. As proposed:
>
>    - PHP 8.0 will no longer mangle variable names in any super-global.
>    - The changelog will recommend auditing super-global access for mangled
>    names, and replacing with the actual variable name.
>    - No INI settings will engage the behavior.
>    - No warnings or notices will be emitted.
>    - A polyfill will be made available to emulate that original behavior.
>    - Applications requiring name mangling shall invoke the polyfill during
>    bootstrap phase.
>
> https://wiki.php.net/rfc/on_demand_name_mangling


What about libraries that need to support both PHP 7 and 8? Many libraries
will likely need to, potentially for a long time.

How will these libraries be able to detect whether the names have been
mangled or not? Libraries that "unmangle" run the risk of "unmangling"
names that aren't actually mangled, and could end up mangling them instead.

This is a particular concern with the proposed polyfill - if there's a
polyfill that mangles the names, you can't just use something like
php_version() to check if it's version 8, since the polyfill could have
been applied.

Maybe consider adding something like $_SERVER["REAL_HEADER_NAMES"] which,
if set, will indicate the names have not been mangled? The polyfill could
then unset() this value - it could even check first if the names are
already non-mangled, whether this is because it's running under PHP 8,
because the polyfill gets bootstrapped twice (which it'll probably need to
check somehow anyway) or because somebody else polyfilled the same change
in some other way.

--00000000000090b276058df1cb5a--