Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51046
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)
MIME-Version: 1.0
Date: Thu, 16 Dec 2010 13:09:57 +0000
To: Pierre Joye <pierre.php@gmail.com>
Cc: Ferenc Kovacs <info@tyrael.hu>, <internals@lists.php.net>
Organization: =?UTF-8?Q?N=C3=BAcleo_de_Engenharia_Biom=C3=A9dica_do_Instituto_Superior_T=C3=A9cnico?=
In-Reply-To: <AANLkTikY7OUZJSfkHXr2jTnA3_c0SaQ6u=d1qhgn6reF@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> <AANLkTi=yk3fkz5Q-8Etw88mg1UDm-oLzB7wz0e65zZRB@mail.gmail.com> <AANLkTikY7OUZJSfkHXr2jTnA3_c0SaQ6u=d1qhgn6reF@mail.gmail.com>
Message-ID: <6b2ba5e56d64910c49bb431ba1e36e17@nebm.ist.utl.pt>
User-Agent: RoundCube Webmail/0.3
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

On Thu, 16 Dec 2010 12:47:43 -0000, Pierre Joye <pierre.php@gmail.com>
wrote:

As I said in IRC, I see no value in having an option that disables
accessing POST data completely (i.e. the behavior of
enable_post_data_reading=Off + disallowing reading it through
php://input).

With enable_post_data_reading=Off, the only way to access the data is
through php://input; if the script uses the wrapper to read the data is
because it presumably needs, or expects, such data. If the script doesn't
need it, it won't read php://input. Activating a putative option that
completely disabled reading POST data would break the first script and
would have no effect on the second. And it's not like there would be
performance benefits from introducing such as option.

More importantly, the enable_post_data_reading is to allow efficient
handling of POST data and access to raw POST data with multipart requests.
Adding an option that disables accessing POST data completely would not
help.

> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs <info@tyrael.hu> wrote:
>
>> 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.
>
> yes, but that's something very confusing right now, the naming and the
> other ways to access POST data. The goal of this idea is a good thing
> to do, but the naming and its implementation are confusing (processing
> vs reading vs used at all).
>

I don't thinks it's that confusing. This new option just prevents PHP from
doing any automatic reading and processing of the POST data, leaving it
entirely on the hands of the programmer to that, if he wishes, through
php://input.

What is confusing is the different behavior of PHP with
$HTTP_RAW_POST_DATA and the influence always_populate_post_data and the
different handling of urlencoded vs multipart vs other content-type POST
requests vs non-POST requests with a request body.

-- 
Gustavo Lopes