Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78492
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAL+t6cHE8Ye+r4uJsO-UdtHTEGP7=kwvEzrnp8_Q4rmEn-p0MA@mail.gmail.com>
Date: Thu, 30 Oct 2014 21:15:41 +0000
Cc: Florian Margaine <florian@margaine.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <95592BAA-862D-4C9A-BA05-9EDAE4EC34EB@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <CABRjmp9p=+zGiqn_nuVJcDAK0po98FnDhb7wTmG66tob4u0GOw@mail.gmail.com> <CAL+t6cFh77D0FufKGy_OeLO7O0=ky46Zv8S=oTLFP8VnZRtCvw@mail.gmail.com> <36B5E957-01C0-40F2-B4CE-5B02D11ACA14@ajf.me> <CAL+t6cGERpWQDSmqfHVYgb4hzKOtFaKWPKt2Lvm44FNyoE-ebg@mail.gmail.com> <DCF8CAF9-2A97-455C-8564-6534DCFB3035@ajf.me> <CAL+t6cHE8Ye+r4uJsO-UdtHTEGP7=kwvEzrnp8_Q4rmEn-p0MA@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: ajf@ajf.me (Andrea Faulds)


> On 30 Oct 2014, at 20:49, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> No, the interface makes it possible to implement your own behavior, =
but it does not prevent PHP from implementing default behavior. In that =
PHP would implement its own HttpRequest class, for example, which the =
user can then extend to override default behavior or modify it as they =
see fit for their particular use case. This is much like the Session =
interface, which makes it possible to change session storage mechanisms =
in userland, but still have a confirming method of session handling in =
PHP.

You know, before I keep up this discussion, it=E2=80=99d be nice if you =
clarified what, exactly, you are proposing. The RFC contains no detail =
at all. I really haven=E2=80=99t the faintest.

Also, removing $_GET and $_POST is a *massive* backwards-compatibility =
break. I would vote against this proposal and I hope everyone else will =
join me in doing so, for that reason alone.

Please, don=E2=80=99t completely break every single PHP site I=E2=80=99ve =
ever written. :(

> So the fix to something like PUT/DELETE requests is to add yet another =
super global.

No, not really. $_PUT and $_DELETE don=E2=80=99t really make sense, why =
are you sending form data to PUT or DELETE? Populating $_POST also makes =
sense, it=E2=80=99s not a POST request. The answer is just to add a =
function to do multipart parsing, to expose PHP=E2=80=99s current =
parser, which satisfies the obscure use case of needing form data =
parsing for PUT and DELETE. I don=E2=80=99t think this would be too hard =
to do.
--
Andrea Faulds
http://ajf.me/