Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58035
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
Message-ID: <4F480C5B.30606@garfieldtech.com>
Date: Fri, 24 Feb 2012 16:16:59 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGovj_PbjoB78kXvZcaSkx3qQziMXX7ezVmzYSPHQbJL7uu7VA@mail.gmail.com>    <8D8E9A0839FE464FBBDF2B499DAFA596@gmail.com>    <CAGovj_OA29qv0MvpFwaT6EF4h_+CYuirNY8nLBaqGurkdO3Afw@mail.gmail.com> <88ad33db205558862288b3114ef4c391.squirrel@www.l-i-e.com>
In-Reply-To: <88ad33db205558862288b3114ef4c391.squirrel@www.l-i-e.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] $_PARAMETERS Super Global Object
From: larry@garfieldtech.com (Larry Garfield)

On 2/24/12 3:28 PM, Richard Lynch wrote:
> On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
>> $_REQUEST does nothing of the sort, and it's use is dangerous in
>> RESTful architecture.  $_REQUEST is a smash together of $_GET, $_POST
>> and $_COOKIE, in that order but the php.ini directive can change it.
>> Hence there's no way of knowing if $_REQUEST['password'] came from
>> $_COOKIE, $_POST, or $_GET, and worse, if two values in those source
>> arrays have the same key $_REQUEST will overwrite them.  $_REQUEST to
>> be honest, is a lame shortcut and bad idea almost on par with
>> register_globals.
>
> Given that all three of $_GET $_POST and $_COOKIE are equally suspect
> from a security POV, and you shouldn't really *care* which way the
> client delivered the value, or at least not rely on it for anything
> useful, I've never understood the resistance to using $_REQUEST.
>
> Yes, GET should be idempotent, but there are many APIs and functions
> in a large app that are idempotent by nature, and having a REST that
> just doesn't care how the data comes in allows the consumer of the
> service to use whatever they prefer.
>
> If your entire REST service is read-only, such as an RSS feed, why not
> allow GET or POST (or, silly as it may be COOKIE) and just use
> $_REQUEST.

Because GET and POST are not even remotely the same thing and treating 
them as completely interchangeable is a bug in the first place.  It is 
in fact legal to have both in the same request.  Then what do you do?

The idea of having a real request object in PHP is a good one; however, 
a superglobal is not it.  Making it a superglobal eliminates the value 
of a real request object, namely that you can encapsulate it, override 
it locally, pass it around, mock it for testing, etc. in a safe fashion. 
  A superglobal request object is a complete waste of time.

There are a number of existing request object libraries out there 
already.  PECL HTTP in C, both Zend and Symfony2 have their versions, 
etc.  Drupal is in the process of moving to Symfony's.  Any PHP-core 
request object (which in general I will agree is a good thing, and 
something sorely missing in the language today) should be based on one 
of those, where there's already existing work done to work out the 
kinks.  Simply throwing $_GET onto a property of a superglobal object 
does not accomplish anything useful.

--Larry Garfield