Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 207.97.245.153 as permitted sender)
To: Mark van der Velden <mark@dynom.nl>
In-Reply-To: <4919F4C0.4050202@dynom.nl>
References: <03.10.53449.C0EC1C74@pb1.pair.com> <4919F4C0.4050202@dynom.nl>
Message-ID: <4543BB1F-E0AF-4032-B50B-F7E8CD4430C1@php.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 11 Nov 2008 17:05:35 -0500
Cc: Sebastian <admin@ifyouwantblood.de>,
 internals@lists.php.net
Subject: Re: [PHP-DEV] register globals -> PHP6 still replaces . in variables from outside
From: davey@php.net (Davey Shafik)


On Nov 11, 2008, at 04:10 PM, Mark van der Velden wrote:

> Sorry for bringing an old thread back to life, but imo this needs some
> more attention.
>
>
> Sebastian wrote:
>> hi,
>>
>> PHP6 still replaces "." with an underscore in variables from  
>> outside. this
>> is an old behavior forced by register globals so i would say its a  
>> bug since
>> "." is valid in array keys.
>>
>> for sample:
>>
>> call a script like http://www.example.com/?my.var=1
>>
>> now $_GET will look like this:
>>
>> Array ( [my_var] => 1)
>>
>> Thanks
>>
>
> It's a valid HTML input name attribute character [1] and imo the
> replacement feature (where ' ' and '.' characters are replaced to '_')
> should be removed in PHP 6, when the register_globals feature is  
> removed.
>
> There will be PHP applications that need changing, but I estimate that
> it will be fixed easily. And since PHP 6 is breaking a lot anyway,  
> what
> other version would be more suitable to change this.
>
>
> [1] - http://www.w3schools.com/TAGS/att_input_name.asp
>
>
> - Mark

Not to be pedantic, and really, it further supports your case, the W3C  
spec
for HTML, specifies that the name attribute is simply CDATA, therefore
anything is valid. It also says it's case-insensitive also, however I  
doubt
that could be handled in any non-impactful way.

- Davey