Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43979 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17362 invoked from network); 15 May 2009 08:40:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 May 2009 08:40:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=hannes.magnusson@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=hannes.magnusson@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.159 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: hannes.magnusson@gmail.com X-Host-Fingerprint: 72.14.220.159 fg-out-1718.google.com Received: from [72.14.220.159] ([72.14.220.159:56909] helo=fg-out-1718.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A5/7E-27038-49A2D0A4 for ; Fri, 15 May 2009 04:40:53 -0400 Received: by fg-out-1718.google.com with SMTP id 22so60798fge.0 for ; Fri, 15 May 2009 01:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y3K2pYey/yj54iwPgKm5JUQG2E8AmLwcHludUDsapqM=; b=A3+laDhLqmGZxlCnrI5nwjny6ANn777Ccd2YygYznEJlJFNUdbVyAvt0GAFsbRynBq GIi4zkoqHUlpdp4TGHpwct4QLxTfCOHxvwHIp1TtZAJDXCh2U8rWRSbGlL2vZZHTliKU 1X+avYyQXFZOICOQQNNWzN32E76GWZgWkkaaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uXe+eRcLSjl4D/VOBaNZgZk35C/mJoLmlHbBYVIYLT9sX9Gi8AQDbIFPsJJCnyIJZS 3mg7vHL2mAB28LTeVPUepWc97K0Muh+N25ZQcplg7KKMyYZe/kEE/XrzYG/RRhS9G0z6 a8I4mUZpqS9ritF1XHsV1n74o73C8zYof8W4w= MIME-Version: 1.0 Received: by 10.86.91.13 with SMTP id o13mr3471891fgb.7.1242376849706; Fri, 15 May 2009 01:40:49 -0700 (PDT) In-Reply-To: References: <4A0C9516.8060808@gmail.com> <4A0D2648.3050802@lerdorf.com> Date: Fri, 15 May 2009 10:40:49 +0200 Message-ID: <7f3ed2c30905150140s25531b45j1c39c9aec97d60cc@mail.gmail.com> To: Lukas Kahwe Smith Cc: Rasmus Lerdorf , Michael Shadle , Nathan Rixham , PHP Development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Why does $_REQUEST exist? From: hannes.magnusson@gmail.com (Hannes Magnusson) On Fri, May 15, 2009 at 10:32, Lukas Kahwe Smith wrote= : > > On 15.05.2009, at 10:22, Rasmus Lerdorf wrote: > >> Michael Shadle wrote: >>> >>> On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham wrot= e: >>> >>>> bc? all the reasoning in the world won't justify it to 1 million >>>> businesses >>>> running php 4 code which is reliant on $_REQUEST behind the scenes. >>>> >>>> although it would generate a tonne of freelance work :p >>> >>> that code has to change for 5.3 or 6.0 anyway. >>> >>> now is the time to yank out some of the legacy crap. we don't want PHP >>> to be like windows, do we? >> >> The more stuff like this we remove, the harder it becomes for people to >> quickly move to newer, faster and more secure versions of PHP. =A0That >> causes way more frustration for everyone than a few "ugly" legacy >> features. =A0If there is a decent technical reason, performance or >> security, then we need to take a hard look at it. =A0In this case, the >> thing we should be looking at isn't whether we should remove $_REQUEST >> but whether we should remove cookie data from it. =A0Many configurations >> already do that, including all of my own, and there is a strong valid >> security reason for not including cookies in $_REQUEST. =A0Most people u= se >> $_REQUEST to mean GET or POST, not realizing that it could also contain >> cookies and as such bad guys could potentially do some cookie injection >> tricks and break naive applications. > > > Its already fixed in 5.3. There is a new ini option that defines what sho= uld > go into $_REQUEST. See the following blog post for details: And simplified version in the docs http://php.net/request_order -Hannes