Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69476
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c--kSrsWAPr_p8J7KV=TsStSL4NL1GCKRDeyycdZxDWyg@mail.gmail.com>
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
	<CAF+90c--kSrsWAPr_p8J7KV=TsStSL4NL1GCKRDeyycdZxDWyg@mail.gmail.com>
Date: Thu, 3 Oct 2013 02:18:14 -0700
Message-ID: <CAEZPtU54z0CecKQd-x6vGNy_pwiRuEXW1V+chFRyrOXn8D_ZxA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Michael Wallner <mike@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing
 PUT data)
From: pierre.php@gmail.com (Pierre Joye)

hi!

On Wed, Oct 2, 2013 at 8:15 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner <mike@php.net> wrote:
>
>> Since ever people are confused by _GET and _POST superglobals,
>> because, despite their name, they do not (really) depend on the
>> request method.  Therefor I propose to phase out $_GET and name it
>> $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not
>> 100% confident with the latter yet, though).
>>
>
> I don't think this kind of change is worth it if you just rename two very
> heavily used variables. If something in this direction is changed the
> change should be more thorough (including getting away from superglobals
> and representing the request state by an immutable object).


I totally agree with you here. Unlike the other related changes, the
impact on existing code is much larger here, for little gain. I am in
favor of not touching them, at all.

>> There are already parsers for application/x-www-form-urlencoded and
>> multipart/form-data in the core.  One could think of providing an API
>> to add content type handlers from extensions, ext/json may be an
>> example, like it is hacked into pecl_http-v2.
>>
>
> I would *strongly* recommend against adding additional body parsers that
> are automatically invoked based on the content type.

Again, I totally agree.

> Adding additional
> parsers creates a high security risk. E.g. exposing ext/json as it is now
> would open you to a denial of service attack (if I'm not mistaken). There
> has been a long history of security vulnerabilities (both DOS and RCE)
> related to unnecessary or incorrect exposure of request body parsers. A
> prominent recent example are the RCE vulnerabilities in Rails caused by the
> exposure of YAML and JSON parsers.

However I could imagine some new ways to deal with inputs,
rest/http/services friendlier.  But it is a tricky area, both from an
API design and security points of view.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org