Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51047
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.45 as permitted sender)
DomainKey-Status: bad
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;
        b=ctjodHYSQIyPa/f4ytag5PToq/2+YtjsK4+IEH40WO2ZOQvusdEWUNeTkRAkfVx1xF
         +h0vf3WgnQyDP/TJB2PosPIPsiVbP/QASIvgEZ2sYSZ6gR4hsNNZXmpPRK8NqlcXH/fO
         ZMWsb4nJX1jSNSuAcd5KXVGT5AOGfteAw2WiA=
MIME-Version: 1.0
In-Reply-To: <6b2ba5e56d64910c49bb431ba1e36e17@nebm.ist.utl.pt>
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>
	<6b2ba5e56d64910c49bb431ba1e36e17@nebm.ist.utl.pt>
Date: Thu, 16 Dec 2010 14:16:34 +0100
Message-ID: <AANLkTi=UMr3nK10dg8_2zrcgvnyJ6ES9vdEsFgJgZZaR@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: Ferenc Kovacs <info@tyrael.hu>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
From: pierre.php@gmail.com (Pierre Joye)

There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes sense.

There are different existing modes and one or two new modes (to be
introduced, like disabling POST). Having a clean way to choose which
mode should be used for a request makes sense and will improve the
user experience. Right now and as shown the confusing discussions on
IRC (or partially here) shows that the current situation is a mess.

Again, I'm not saying that the idea behind this patch is bad, only
that there is a better way to do it while being less confusing and
making the whole thing cleaner to define.

2010/12/16 Gustavo Lopes <glopes@nebm.ist.utl.pt>:
> 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
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org