Re: $_PARAMETERS Super Global Object
| From: | Larry Garfield | Date: | Fri, 24 Feb 2012 22:16:59 +0000 |
| Subject: | Re: $_PARAMETERS Super Global Object | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-58035@lists.php.net to get a copy of this message | ||
On 2/24/12 3:28 PM, Richard Lynch wrote:
On Wed, February 22, 2012 9:10 am, Michael Morris wrote: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$_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.