Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57972
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
Received-SPF: pass (google.com: domain of wgpdeepak1989@gmail.com designates 10.68.218.161 as permitted sender) client-ip=10.68.218.161;
MIME-Version: 1.0
In-Reply-To: <4F45618F.4000204@gmail.com>
References: <CAGovj_PbjoB78kXvZcaSkx3qQziMXX7ezVmzYSPHQbJL7uu7VA@mail.gmail.com>
	<4F45618F.4000204@gmail.com>
Date: Thu, 23 Feb 2012 11:29:52 +0530
Message-ID: <CACOkViAQAn8mm1K3gW-EFbMQsQ2W03r+bF=g-vpyuz-GNOj7Ew@mail.gmail.com>
To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8ff2488342c29f04b99b5aaa
Subject: Re: [PHP-DEV] $_PARAMETERS Super Global Object
From: wgpdeepak1989@gmail.com (Deepak Balani)

--e89a8ff2488342c29f04b99b5aaa
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, I'm agree with Will Fitch.

Handling this problem with PHP is a good idea and beneficial to programmer.



2012/2/23 =C1ngel Gonz=E1lez <keisial@gmail.com>

> On 22/02/12 15:57, Michael Morris wrote:
> > Before writing up a full RFC I want to put out a feeler on something.
> > Currently we have several input parameter objects, chief among them
> > $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers).  All
> > of them are arrays and legacy code sometimes writes to them.  Locking
> > them as read only objects would cause a major BC break.
>
> Why would you want to set them read-only?
> I agree that they should represent the input parameters, but there are
> times
> where modificating them is very useful.
> For instance, a framework code could be modifying $_GET on index.php to
> strip magic quotes before passing it down to  another module.
> Even better, that code would work even for modules written before
> supporting
> that configuration.
> If the module had used directly such $_PARAMETERS, it would get wrong
> results.
>
> I guess we will start seeing the opposite behavior with 5.4, though:
> Code doing
> addslashes() on input parameters before running code which expected magic
> quotes (maybe at auto_prepend_file, even). But still, it's good to have
> such
> ability even if it's something to be avoided.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--e89a8ff2488342c29f04b99b5aaa--