Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69439
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain apfelbox.net from 37.139.17.48 cause and error)
Date: Wed, 2 Oct 2013 09:25:32 +0200
To: Alexey Zakhlestin <indeyets@gmail.com>
Cc: Michael Wallner <mike@php.net>, PHP Internals
 <internals@lists.php.net>
Message-ID: <74407D015BE040FAA3D23C244D8FE16C@apfelbox.net>
In-Reply-To: <79A5CEBE-1E12-4842-9F7E-3A1F4925B6BD@gmail.com>
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>
 <79A5CEBE-1E12-4842-9F7E-3A1F4925B6BD@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="524bca6c_721da317_7a2f"
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was:
 Parsing PUT data)
From: hello@apfelbox.net (Jannik Zschiesche)

--524bca6c_721da317_7a2f
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

wouldn=E2=80=99t =24=5FBODY be better - since it is the request body=3F
=24=5F=46ORM is imho not very clear, since you can send data to =24=5FPOS=
T without using a form.


-- =20
Cheers
Jannik


Am Mittwoch, 2. Oktober 2013 um 09:17 schrieb Alexey Zakhlestin:

> =20
> On 02.10.2013, at 10:59, Michael Wallner <mike=40php.net (mailto:mike=40=
php.net)> wrote:
> =20
> > Since ever people are confused by =5FGET and =5FPOST superglobals,
> > because, despite their name, they do not (really) depend on the
> > request method. Therefor I propose to phase out =24=5FGET and name it=

> > =24=5FQUERY and I propose to phase out =24=5FPOST and name it =24=5F=46=
ORM (I'm not
> > 100% confident with the latter yet, though).
> > =20
> > =46urther, I propose to remove the POST method restriction for handli=
ng
> > request bodies and solely rely on the content type to trigger the
> > parser(s). (*)
> > =20
> > 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=5Fhttp-v2.
> > =20
> > Thoughts, objections, insults=3F
> > =20
> > (*) We'd probably have to revisit all *post* INI variables, though.
> =20
> So, that is not one, but three proposals:
> =20
> 1. =5FGET -> =5FQUERY, =5FPOST -> =5F=46ORM
> =20
> I don't think this is really necessary. Names are there historically an=
d changing them will break a lot of stuff.
> +0 on aliasing, and soft-deprecation (via documentation) though
> =20
> 2. ignore request-method, trigger body-processing solely on Content-typ=
e
> =20
> +1. makes sense
> =20
> 3. expose body-parsers via php-level API
> =20
> +1. Hell, yes=21 Something like +1000, actually ;)
> =20
> =20
> =20
> -- =20
> Alexey Zakhlestin
> CTO at Grids.by/you
> https://github.com/indeyets
> PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
> =20
> =20



--524bca6c_721da317_7a2f--