Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69454
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
Date: Wed, 2 Oct 2013 17:15:18 +0200
Message-ID: <CAF+90c--kSrsWAPr_p8J7KV=TsStSL4NL1GCKRDeyycdZxDWyg@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2c1ea89ded104e7c3891e
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing
 PUT data)
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c2c1ea89ded104e7c3891e
Content-Type: text/plain; charset=ISO-8859-1

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).


> 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.

Nikita

--001a11c2c1ea89ded104e7c3891e--