Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50899
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Derick Rethans" <derick@php.net>, "internals@lists.php.net"
 <internals@lists.php.net>
References: <op.vnb0shjiidpuyk@damnation.dulce.lo.geleia.net>
 <alpine.DEB.2.00.1012071200180.4592@kossu.derickrethans.nl>
Date: Tue, 07 Dec 2010 13:07:42 -0000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vnche3q4idpuyk@damnation.dulce.lo.geleia.net>
In-Reply-To: <alpine.DEB.2.00.1012071200180.4592@kossu.derickrethans.nl>
User-Agent: Opera Mail/10.63 (Win32)
Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Tue, 07 Dec 2010 12:01:59 -0000, Derick Rethans <derick@php.net> wrote:

> On Tue, 7 Dec 2010, Gustavo Lopes wrote:
>
>> The very simple attached patch adds an option to disable POST data
>> processing, which implies the data can only be read in
>> a stream fashion through php://input.
>
> Does without this patch, reading POST data from php://input work?

Maybe.

In case of a multipart/form-data request, it won't.
For other requests, it will. However, php://input will be reading from  
memory, not from the SAPI, because the entire POST data will be in memory.

The new option makes the behavior for a POST request similar to that of  
e.g. a PUT request, i.e., data can only be read with php://input and it  
will *not* be copied entirely into memory before the user code executes.  
Of course the user can use something like file_get_contents('php://input')  
to do that, but, depending on the application, he may take advantage of  
the low memory usage a stream provides (for the XML payload example, he  
could use a SAX-like parser, for proxying or saving the entire request  
into disk -- possibly filtered -- he could use stream_copy_to_stream,  
etc.).

>
>> This introduces a new ini setting, disable_post_data_processing, but
>> it's a benign one. No incompatibilities between setups will arise
>> because no one will enable it globally (it would be insane),
>
> Because they can, people will do it though... I'm not fan of more ini
> settings.
>

I'm sure someone somewhere will enable it eventually without being aware  
of what it does (despite the obvious name...); my point is that  
programmers don't need to program against it (unlike say, magic quotes)  
because no working PHP setup will have it enabled, as it breaks every  
script that handles POST data.


-- 
Gustavo Lopes