Request for Comments: PHP 6 should maintain non-variable-name characters in GET/POST/COOKIE keys

• Version: 1.0
• Date: 2010-01-30
• Author: Richard Lynch lynch@php.net
• Status: Under Discussion

This is an attempt to summarize a thread on the php-internals mailing list. Apologies for any lost content. And for my failure to do wiki markup well.

Historically, PHP replaced '.' and other characters not fitting the pattern ^[a-z][a-z_]+$ using '_' instead in requests, in order to be able to import variables with register_globals.

To be consistent $HTTP_GET_VARS and friends also replaced these characters with '_'

Later $_GET and friends also replaced these characters with '_'

In PHP 6, there will be no register_globals, and no real reason to change 'a.b' into 'a_b'

For example, ?a.b=2 could now safely turn into $_GET['a.b'] = '2'; rather than $_GET['a_b'] = '2';

Given that PHP 6 is a major release, do we need BC, perhaps populating *both* 'a.b' and 'a_b'?

Are there any apps that detect 'a_b' and then blindly assume 'a.b' was the original, when it could just as well be 'a^b' or 'a|b' or ...

And, if they do, are they not likely to be using the “original” character, whatever it is, and thus probably not break?

It seems likely that few apps would be broken by simply dropping the changes.

Currently, extract simply ignores 'a.b' or other invalid variable names found in keys. This should then cause no issues/problems.

Are there any characters valid in a URL that can NOT be used as keys in a hash?

These characters would still need to be addressed if they exist.

PHP 6 should use the exact input from GET/POST/COOKIE as the key in $_GET/$_POST/$_COOKIE and not alter it to fit a variable name, since the cause of that behaviour is no longer extant.