Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78493
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain fastmail.fm designates 66.111.4.27 as permitted sender)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <95592BAA-862D-4C9A-BA05-9EDAE4EC34EB@ajf.me>
Date: Thu, 30 Oct 2014 16:26:52 -0500
Cc: Sherif Ramadan <theanomaly.is@gmail.com>,
 Florian Margaine <florian@margaine.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A5EBBB7F-3A65-44D4-B642-E6EFBA0723CB@fastmail.fm>
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> <95592BAA-862D-4C9A-BA05-9EDAE4EC34EB@ajf.me>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: willfitch@fastmail.fm (Will Fitch)



> On Oct 30, 2014, at 4:15 PM, Andrea Faulds <ajf@ajf.me> wrote:
>=20
>=20
>> 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 i=
t does not prevent PHP from implementing default behavior. In that PHP would=
 implement its own HttpRequest class, for example, which the user can then e=
xtend to override default behavior or modify it as they see fit for their pa=
rticular use case. This is much like the Session interface, which makes it p=
ossible to change session storage mechanisms in userland, but still have a c=
onfirming method of session handling in PHP.
>=20
> You know, before I keep up this discussion, it=E2=80=99d be nice if you cl=
arified what, exactly, you are proposing. The RFC contains no detail at all.=
 I really haven=E2=80=99t the faintest.
>=20
> Also, removing $_GET and $_POST is a *massive* backwards-compatibility bre=
ak. I would vote against this proposal and I hope everyone else will join me=
 in doing so, for that reason alone.
>=20
> Please, don=E2=80=99t completely break every single PHP site I=E2=80=99ve e=
ver written. :(
>=20
>> So the fix to something like PUT/DELETE requests is to add yet another su=
per global.
>=20
> No, not really. $_PUT and $_DELETE don=E2=80=99t really make sense, why ar=
e 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 d=
o 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.

It's not hard. Again, pecl/http v2 proposal will give core everything it nee=
ds. I honestly don't know why this is being discussed any further when their=
s a solution that gives functionality requested here and contains zero BC br=
eaks.=20

> --
> Andrea Faulds
> http://ajf.me/
>=20
>=20
>=20
>=20
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20