Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51043
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.173 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=rP+66AAHW4QNKHAPbawD7T1onYBcyMQaSsJos7vON0kurdwNxMaeS65i+RCnlhKuvM
         klsdlSPxdCBTwBWT/BiWfenGXBDJYTzpGr5uw+HORtoajL5E6/I6cyXFvjBP9vFHYanT
         Vz7phG5QapfPXT5Ae8QeUAshVavXwrUewfs7g=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <AANLkTintNBB_NGbxWNyGFDm5sJh1_L+1PqaGty45GJjG@mail.gmail.com>
References: <op.vnb0shjiidpuyk@damnation.dulce.lo.geleia.net>
	<op.vngrk2s3idpuyk@damnation.dulce.lo.geleia.net>
	<AANLkTintNBB_NGbxWNyGFDm5sJh1_L+1PqaGty45GJjG@mail.gmail.com>
Date: Thu, 16 Dec 2010 13:42:08 +0100
Message-ID: <AANLkTi=yk3fkz5Q-8Etw88mg1UDm-oLzB7wz0e65zZRB@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=00163630f5fbca909e049786614c
Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
From: info@tyrael.hu (Ferenc Kovacs)

--00163630f5fbca909e049786614c
Content-Type: text/plain; charset=UTF-8

On Thu, Dec 16, 2010 at 1:32 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> hi,
>
> The more I look at this option the more I think it is confusing. I'm
> not sure the gain is worth this confusion either. However I would
> prefer to bring back a proposal we had a couple of years ago, to
> totally disable post data. When disabled, the POST data will be
> totally ignored, no matter if php://input, raw data or whatever other
> ways we may have to access it. The data given by the server/sapi will
> be ignored.
>
> This option has the benefit to be very simple and solves one known
> attack vector in a very clean way.
>
>
Yeah, but that idea isn't solves the problem which the current one tries to
address.
So while I think that it would be a good security measure to alllow to
disable POST altogether, but that should be discussed/voted in a different
thread.
So currently we didn't talk about security measures, but performance gains:
If somebody wants to write a script, which handles big file uploads, but
only writes it to somewhere (to file, or another stream), then currently you
have to allocate the memory for the post data twice(see the first email),
which is very inefficient if you don't need the $_POST at all.

Tyrael

--00163630f5fbca909e049786614c--