Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54540
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CAH-PCH6=hx-combseW9MxNTHRX7UvdLgCA-0Y8rOAx7zd-vyYA@mail.gmail.com>
References: <CABBJUpcb0=_EjCuwprYP-47gio2FXDu14b-_hk2gEBd9VFX3Fg@mail.gmail.com>
	<alpine.DEB.2.02.1108121418540.4043@whisky>
	<CAH-PCH6=hx-combseW9MxNTHRX7UvdLgCA-0Y8rOAx7zd-vyYA@mail.gmail.com>
Date: Fri, 12 Aug 2011 22:12:09 +0800
Message-ID: <CABBJUpcU+VdnSFikVJJrC0_5kK2pTyr+XfTX_mr_x19RKjaCaw@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Derick Rethans <derick@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] behavior of translating dot in the query variable name
 into underscore character
From: laruence@php.net (Laruence)

Hi:
  I am goot at debate as my poor english,
  I try to make my point clearly,

  that is , I think there is one reason to do this change, that is
"what you saw should be what you get",

  this behavior confused any pepole who meet this issue first, and
need explained by document,

  I agree with Tyral:"it would be really awkward keeping this
workaround much longer for  a design problem which isn't there
anymore."

thanks

2011/8/12 Ferenc Kovacs <tyra3l@gmail.com>:
> On Fri, Aug 12, 2011 at 3:20 PM, Derick Rethans <derick@php.net> wrote:
>> On Fri, 12 Aug 2011, Laruence wrote:
>>
>>> =C2=A0 =C2=A0 =C2=A0a request uri : http://***/a.b=3D2 =C2=A0will resul=
t $_GET["a_b"] =3D 2 (
>>> the dot was translated into underscore char);
>>>
>>> =C2=A0 =C2=A0 =C2=A0my point is , since register_globals has be removed=
 already( in
>>> my opinion this behavior only make sence when register_globals on),
>>> should we remove this translating behavior too?
>>
>> No. No reason to change anything that isn't broken. Chanhing this will
>> mean a BC break, even for people that don't use register_globals.
>>
>
> it is broken, we just sucked it up.
> if we would both provide the foo_bar and foo.bar:
>
> - if your code expects foo.bar to be foo_bar, it's there.
> - if you expect foo.bar, it's also fine.
> - if you did a workaround in the past (parse the query string
> manually), that would also work, in the worst case, you would
> overwrite the foo.bar with the same value.
>
> so it's not much userland BC (not until we remove the foo_bar syntax),
> except maybe if you do some really strict input validation (abort if
> there is an request variable not specified in the whitelist).
> I don't mind if this only ships with the next minor or major version,
> but it would be really awkward keeping this workaround much longer for
> a design problem which isn't there anymore.
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/