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. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
