Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58026 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41289 invoked from network); 24 Feb 2012 21:28:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Feb 2012 21:28:46 -0000 Authentication-Results: pb1.pair.com header.from=ceo@l-i-e.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ceo@l-i-e.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender) X-PHP-List-Original-Sender: ceo@l-i-e.com X-Host-Fingerprint: 67.139.134.202 o2.hostbaby.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from [67.139.134.202] ([67.139.134.202:3576] helo=o2.hostbaby.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/FA-17132-C01084F4 for ; Fri, 24 Feb 2012 16:28:45 -0500 Received: (qmail 29564 invoked by uid 98); 24 Feb 2012 21:28:46 -0000 Received: from localhost by o2.hostbaby.com (envelope-from , uid 1013) with qmail-scanner-2.05 ( Clear:RC:1(127.0.0.1):. Processed in 0.041557 secs); 24 Feb 2012 21:28:46 -0000 Received: from localhost (HELO www.l-i-e.com) (127.0.0.1) by localhost with SMTP; 24 Feb 2012 21:28:46 -0000 Received: from webmail (SquirrelMail authenticated user ceo@l-i-e.com) by www.l-i-e.com with HTTP; Fri, 24 Feb 2012 15:28:46 -0600 Message-ID: <88ad33db205558862288b3114ef4c391.squirrel@www.l-i-e.com> In-Reply-To: References: <8D8E9A0839FE464FBBDF2B499DAFA596@gmail.com> Date: Fri, 24 Feb 2012 15:28:46 -0600 To: "PHP Internals List" User-Agent: SquirrelMail/1.4.21 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [PHP-DEV] $_PARAMETERS Super Global Object From: ceo@l-i-e.com ("Richard Lynch") 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