Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.196 as permitted sender)
Date: Wed, 2 Oct 2013 10:58:06 +0100 (BST)
Reply-To: Andrea Faulds <ajf@ajf.me>
To: PHP Internals <internals@lists.php.net>
Message-ID: <1463242957.26490.1380707886136.open-xchange@oxwebmail.registrar-servers.com>
In-Reply-To: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Medium
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was:
 Parsing PUT data)
From: ajf@ajf.me (Andrea Faulds)

> Le 2 octobre 2013 =C3=A0 07:59, Michael Wallner <mike@php.net> a =C3=A9cr=
it :
>
> Since ever people are confused by _GET and _POST superglobals,
> because, despite their name, they do not (really) depend on the
> request method.=C2=A0 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).
>
Backwards compatibility matters, so we should keep $_GET and $_POST but add
these as better aliases for them.
=C2=A0
While we're at it, can we remove the quirk that existed due to register_glo=
bals
where periods and such are replaced with underscores? Such that for
/test.php?php.pecl=3D3&php_pecl=3D4 we'd still only have $_GET['php_pecl'] =
=3D=3D=3D 4 but
there would also be $_QUERY['php.pecl'] =3D=3D=3D 3 and $_QUERY['php_pecl']=
 =3D=3D=3D 4, if
you get where I'm coming from.
> Further, I propose to remove the POST method restriction for handling
> request bodies and solely rely on the content type to trigger the
> parser(s). (*)
+1 to this, current behaviour is nonsensical.
> There are already parsers for application/x-www-form-urlencoded and
> multipart/form-data in the core.=C2=A0 One could think of providing an AP=
I
> to add content type handlers from extensions, ext/json may be an
> example, like it is hacked into pecl_http-v2.
+1 Handling JSON would be pretty neat. Maybe we could even support it by de=
fault
(after all, there is the json ext), so long as getting the unparsed request=
 body
isn't impeded by that.
--
Andrea Faulds
http://ajf.me/