Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51058
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.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
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>
 <AANLkTi=UMr3nK10dg8_2zrcgvnyJ6ES9vdEsFgJgZZaR@mail.gmail.com>
 <EF.71.36789.F9F1A0D4@pb1.pair.com>
 <AANLkTikePQafwzN8gcmtVExYVjO_R2Ht-qFZf3dSAExW@mail.gmail.com>
 <59.E3.36789.3D72A0D4@pb1.pair.com>
Date: Thu, 16 Dec 2010 17:09:22 -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.vntglwqxidpuyk@damnation.dulce.lo.geleia.net>
In-Reply-To: <59.E3.36789.3D72A0D4@pb1.pair.com>
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 Thu, 16 Dec 2010 14:53:08 -0000, Matthew Weier O'Phinney  
<weierophinney@php.net> wrote:

> On 2010-12-16, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>> I never said it should be a php.ini option, or only a php.ini option.
>> But having 300 ways to do the same things, or to change options is
>> bad. You should also keep in mind that even if it is a php.ini option,
>> it should obviously be INI_PER_DIR and not system wild (that's what
>> servers options exist, or better appropriate there if one wants to
>> disable POST permanently and for all requests/URLs).
>
> INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP
> applications.
>
> If you look at most frameworks, CMS solutions, or standalone apps such
> as WordPress, there's a single script acting as the gateway to all
> functionality (basically, a front controller). Making the setting
> INI_PER_DIR means that you have to move any functionality that may
> potentially require access to raw POST/PUT data into separate scripts
> and/or directories -- which splits functionality away from the front
> controller and makes maintenance much more difficult.
>

I know you're responding to Pierre's proposed addition of a way to disable  
POST data handling altogether possibly via an ini option, but since the  
objection also applies to the ini option I've added to trunk, I'd like to  
address it.

Yes, it sucks that the option cannot be changed with ini_set, but that's  
an inevitable technical limitation that I don't see how it can be overcome  
without major changes. By the time control is passed to the script, the  
interesting stuff has already happened.

(By the way, I think it's unfortunate that most frameworks abandoned the  
simplicity of a direct correspondence file <--> url -- whenever practical,  
of course, but that's another matter)

>> All in all, I don't think adding a set of new ini settings for very
>> specific and disputable features is not something good to do. If we
>> need something to process file uploads more efficiently, then let do
>> it in a good way (no, processing php://input manually is not what I
>> can consider as a good way :).

As to multipart requests, we could of course build some mechanism to  
provide, sequentially and in the order they are uploaded, streams for the  
uploaded files; this would be easier than processing php://input manually.  
It's also much more complicated to implement and doesn't cover all the  
cases in which we want a way to handle multipart requests that differs  
 from the default behavior -- think, for instance, proxying requests.

In short, I don't think the possibility of a future implementation of more  
high level mechanisms should preclude the existence of low level ones such  
as the proposed and committed enable_post_data_processing, as the low  
level ones, being less specific, have a larger domain of application,  
despite being more cumbersome.

> I'm not talking about processing file uploads; I'm talking about normal
> handling of raw POST/PUT body content -- something that's very, very
> common when dealing with RESTful or RPC APIs, where the format isn't
> normal URL encoding, but instead something like XML or JSON.
>
> I'm all for better, more efficient processing of file uploads -- but not
> at the expense of being able to build good APIs.
>

I'm not sure what you're proposing instead.

-- 
Gustavo Lopes