Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54541
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CABBJUpcU+VdnSFikVJJrC0_5kK2pTyr+XfTX_mr_x19RKjaCaw@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>
	<CABBJUpcU+VdnSFikVJJrC0_5kK2pTyr+XfTX_mr_x19RKjaCaw@mail.gmail.com>
Date: Fri, 12 Aug 2011 22:12:57 +0800
Message-ID: <CABBJUpdNkSMGj46XfxiM3KB-ZZ1cLDTosz0_KUvx79jTw9F_qg@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)

s/goot at/not good at/

sorry

2011/8/12 Laruence <laruence@php.net>:
> Hi:
> =C2=A0I am goot at debate as my poor english,
> =C2=A0I try to make my point clearly,
>
> =C2=A0that is , I think there is one reason to do this change, that is
> "what you saw should be what you get",
>
> =C2=A0this behavior confused any pepole who meet this issue first, and
> need explained by document,
>
> =C2=A0I agree with Tyral:"it would be really awkward keeping this
> workaround much longer for =C2=A0a 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 resu=
lt $_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 remove=
d 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
>>
>
>
>
> --
> Laruence =C2=A0Xinchen Hui
> http://www.laruence.com/
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/