Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51052
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=GkDFOg59VwNmuGll9aK0MBl4X81QILrEJiYqyYOqf6wyXLHUvQWzlAwIuvlI7S2Efu
         AYev03I+nFYQMQF3N2bkdZMy0cTevoTmOMe+ITEzvtFCMUYnejTCWD/DuM1kfndd39wp
         T+UxvSJViu5SoDAwxFp/5lfsWir7Hg7a0yfbQ=
MIME-Version: 1.0
In-Reply-To: <EF.71.36789.F9F1A0D4@pb1.pair.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>
	<6b2ba5e56d64910c49bb431ba1e36e17@nebm.ist.utl.pt>
	<AANLkTi=UMr3nK10dg8_2zrcgvnyJ6ES9vdEsFgJgZZaR@mail.gmail.com>
	<EF.71.36789.F9F1A0D4@pb1.pair.com>
Date: Thu, 16 Dec 2010 15:25:11 +0100
Message-ID: <AANLkTikePQafwzN8gcmtVExYVjO_R2Ht-qFZf3dSAExW@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: 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)

On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
<weierophinney@php.net> wrote:
> On 2010-12-16, Pierre Joye <pierre.php@gmail.com> wrote:
>> 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.
>
> Seriously, disabling POST via a php.ini setting is considered a
> "sensible" option? Has nobody ever developed a RESTful application?

No comment.

> The only way I can see such an action being "sensible" is if it's also
> runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton
> of issues between security-paranoid sysadmins and developers when code
> is pushed to production and simply stops working...
>
> I understand the rationale behind Pierre's assertion, but it's
> incredibly short-sighted when you consider a full application, where
> some actions need to accept raw POST/PUT data (man, would I love a $_PUT
> superglobal...), others need to accept file uploads, and most others
> need neither.

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).

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 :).

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org