Everything

php

PHP6 cleanup: Request Variable handling for variables with spaces

php.internals

Christopher Kunz

19 years ago

Hi all,

I think I posted about this quite some time ago, but the issue is (as of PHP
5.2.0) still there:

- Request variables that have leading whitespace are trimmed before being
imported into the respective superglobal array.
- Request variables that have trailing whitespace have all whitespace converted
to _ before being imported into the respective superglobal array.

I presume this is still from the good old day of register_globals where men
where men and variables were autoglobal. Having a request variable with a space
wasn't desirable back then ("$ foo - huh?!"), but since r_g is going to go in
PHP6 anyway, wouldn't this be a good moment to change this behavior to what (at
least AFAICT) other languages do?

The impact of this change for actual scripts is probably quite low - you would
have to rely on this for any request variables (i.e. $_GPC keys) to happen in a
register_globals free environment. The upside for this is that it's a central
breaking point for modules like mod_security that take a variable blacklist
approach. Plus, the current behavior is somewhat inconsistent anyway.

Any comments?

--ck

--
http://www.de-punkt.de   [ chris@de-punkt.de ]    http://www.stormix.de
PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich
"PHP-Sicherheit" direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Ilia A.

19 years ago

On 15-Nov-06, at 5:12 AM, Christopher Kunz wrote:

> Hi all,
>
> I think I posted about this quite some time ago, but the issue is
> (as of PHP
> 5.2.0) still there:
>
> - Request variables that have leading whitespace are trimmed before
> being
> imported into the respective superglobal array.
> - Request variables that have trailing whitespace have all
> whitespace converted
> to _ before being imported into the respective superglobal array.
>
> I presume this is still from the good old day of register_globals
> where men
> where men and variables were autoglobal. Having a request variable
> with a space
> wasn't desirable back then ("$ foo - huh?!"), but since r_g is
> going to go in
> PHP6 anyway, wouldn't this be a good moment to change this behavior
> to what (at
> least AFAICT) other languages do?

While I agree that the impact maybe low, there are people who depend
on this behavior. Just because filtering modules/extension life would
be much easier if spaces were left as is, does not seem like a
particularly compelling reason to drop the behavior imho.

Ilia Alshanetsky

Richard Lynch

19 years ago

On Wed, November 15, 2006 4:12 am, Christopher Kunz wrote:

> - Request variables that have leading whitespace are trimmed before
> being
> imported into the respective superglobal array.
> - Request variables that have trailing whitespace have all whitespace
> converted
> to _ before being imported into the respective superglobal array.
>
> I presume this is still from the good old day of register_globals
> where men
> where men and variables were autoglobal. Having a request variable
> with a space
> wasn't desirable back then ("$ foo - huh?!"), but since r_g is going
> to go in
> PHP6 anyway, wouldn't this be a good moment to change this behavior to
> what (at
> least AFAICT) other languages do?

-0.5

If you are going to change that, then you might as well fix all those
INPUT TYPE="IMAGE" NAME="foo" that convert "foo.x" into "foo_x", and
similarly for 'y'

This '.' => '_' was also done for the same historical reason: $foo.x
is not a valid variable name in PHP, so the $_POST/$_GET keys convert
as well, which is confusing to one not familiar with the language
history.

Changing that will break a zillion scripts.

That said:  If this does need to ever change, then 6.0 is the right
time to do it, with register_globals going away.

You *could* consider yet another php.ini setting, with all the baggage
and issues that brings, to provide a transition from 5.x to 6.x to 7.x

Something like:
5.x (as-is, no matter how big .x version goes)
6.x default php.ini to BC ' foo.x ' => 'foo_x' as keys with php.ini
setting to make ' foo.x ' => ' foo.x ' for those that want to migrate
early
7.x default php.ini is ' foo.x ' => ' foo.x ' with flag to keep old
behaviour for the late-adopters
8.x ' foo.x ' => ' foo.x ' is your only option

E_DEPRECATED would be issued in 6.x and 7.x if the setting was BC "on"

I believe that any time-scale less than that, for the number of
scripts that needs to change with INPUT IMAGE, would be a nightmare
for users, imho.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?