Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69462
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
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: Wed, 2 Oct 2013 20:02:51 +0200
Message-ID: <CALJZF3iFW95tw7JDk+G_-2FbgY6gTpUTWQvVy87EdtOmA7t0iA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing
 PUT data)
From: mike@php.net (Michael Wallner)

On 2 October 2013 17:15, 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).

Well, what I want and what is in core may diverge.
May I suggest you take a look at pecl_http-v2, I'd greatly appreciate
any feedback.

>
>>
>> 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. 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.

Pointers, references, evidences?

-- 
Regards,
Mike