register globals -> PHP6 still replaces . in variables from outside

17 years ago by Sebastian — view source

unread

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

17 years ago by Scott MacVicar — view source

unread

The old behaviour would have to remain as well as anything new as it
isn't easy to simply change your script. You'd need to track down all
your input and change any references of x.y to x_y to ensure you don't
break anything.

Scott

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

16 years ago by Mark van der Velden — view source

unread

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

16 years ago by Davey Shafik — view source

unread

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

16 years ago by Kalle Sommer Nielsen — view source

unread

Hi Mark

2008/11/11 Mark van der Velden mark@dynom.nl:

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.

I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.

[1] - http://www.w3schools.com/TAGS/att_input_name.asp

Mark

--

--
Kalle Sommer Nielsen

16 years ago by Stan Vassilev | FM — view source

unread

I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.

There was never a need for the replacement to occur for the GPC
superglobals.

If import_request_variables() needs it, it can do it there only for that
import. I.e.

$_GET['foo.bar'] is just fine, and importing 'foo.bar' with the above
function could still produce $foo_bar only for that specific edge case.

It's just a premature replacement too early the stack.

Regards, Stan Vassilev.

16 years ago by Hannes Magnusson — view source

unread

I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.

There was never a need for the replacement to occur for the GPC
superglobals.

Isn't that fixed already?
I could have sworn seeing a commit from Ilia that allowed dots in the
superglobals (duplicating the key, one with dot and one with
underscore) some months ago...?

-Hannes

16 years ago by Mark van der Velden — view source

unread

Hannes Magnusson wrote:

I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.

There was never a need for the replacement to occur for the GPC
superglobals.

Isn't that fixed already?
I could have sworn seeing a commit from Ilia that allowed dots in the
superglobals (duplicating the key, one with dot and one with
underscore) some months ago...?

I do did read some code related to that, but I got the feeling that was
purely for unicode related matters and I still see replacements. But
perhaps I'm reading it wrong.

If it has been changed, that would be excellent and it would be great if
the documentation got an update also ( http://php.net/register_globals )

<offtopic> I was working on a patch, but I can't get PHP 6 compiled atm (tokenizer.c 'yycINITIAL' re2c v 0.13.5) </offtopic>

-Hannes

Mark

16 years ago by Stan Vassilev | FM — view source

unread

On Wed, Nov 12, 2008 at 03:57, Stan Vassilev | FM sv_forums@fmethod.com
wrote:

I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.

There was never a need for the replacement to occur for the GPC
superglobals.

Isn't that fixed already?
I could have sworn seeing a commit from Ilia that allowed dots in the
superglobals (duplicating the key, one with dot and one with
underscore) some months ago...?

-Hannes

It's not fixed, if it was, it was not checked in. In the 5.3 nightly,
foo.php?a.b.c = 10 shows up as $_GET['a_b_c'] in PHP

Regards, Stan Vassilev