Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78764
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 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+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com>
Date: Thu, 6 Nov 2014 01:38:02 +0000
Cc: Patrick ALLAERT <patrickallaert@php.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <468730E8-4C38-49A3-A61A-59E107313D79@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com> <CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com> <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me> <CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@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 6 Nov 2014, at 01:29, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> So you're actually describing two semi-different problems here. One is =
that PHP doesn't actually inform you of the HTTP request VERB strictly =
through the naming of the super global variables $_POST and $_GET. =
However, $_POST being populated, right now, in PHP, strictly means the =
request verb was POST and that the content-type header received was =
multipart form data. Which means that sending something like a JSON =
payload (Content-type application/x-json or whatever) in the body of a =
POST request still doesn't populate the $_POST super global variable =
even though the HTTP request VERB was indeed POST.

That=E2=80=99s not actually my complaint. The thing is that, until now, =
you could assume what was in $_POST was from a POST request. To allow =
data from PUT and DELETE requests to go there by default is probably not =
a good idea, because POST has quite a different meaning from PUT and =
DELETE.

> The other problem is that the semantics of REST itself are quite =
different from how PHP currently deals with the request data. In that =
PHP only cares about form data. However, this is quite antiquated with =
todays' modern use of HTTP growing in API-specific functionality. For =
example, companies like Twitter and Tumblr, demonstrate a vast majority =
of their traffic currently coming in at the API-level where things are =
usually handled in a RESTful manner. So for the PHP power houses today, =
PHP doesn't quite lend itself well to dealing with these problems =
first-hand. Instead we have to hack our way around them in userland, =
which can be more error-prone and less obvious.

Er=E2=80=A6 I wouldn=E2=80=99t say that PHP really handles REST APIs =
badly, or that the userland approach is error-prone or less obvious. =
Using JSON isn=E2=80=99t difficult, you just do this:

    $data =3D json_decode(file_get_contents(=E2=80=98php://input')) or =
die();

This isn=E2=80=99t a hack. It=E2=80=99s a straightforward and obvious =
way to do this.=20

> While that solution solves one specific problem (dealing with =
multipart form data of request types other than POST), it doesn't quite =
tackle some of the broader issues of dealing with incoming HTTP request =
in PHP that I would like to tackle.

Yes, I=E2=80=99m aware it doesn=E2=80=99t. I don=E2=80=99t think that =
the PUT/DELETE issue really justifies your RFC. I don=E2=80=99t think =
there are any other problems which do, either. There are better ways to =
solve them.

> I also think you're diminishing scope of this problem and the number =
of people affected by it. You not only have to think of the number of =
programmers dealing with the code, but the number of end-users =
indirectly affected by the problem as well. PHP is primarily a =
web-oriented language, and I think as such it should deal with these =
kinds of issues more readily. If you take a good look at the number of =
web-based APIs out there and how certain PHP client libraries try to =
deal with these kinds of problems the solutions are sometimes very =
poorly implemented or just outright wrong.

Your solution is to put even more stuff in userland so web developers =
can produce even less functional applications which have buggy request =
parsing. I don=E2=80=99t think that really helps anyone.

> We solved password hashing dilemmas with password_hash for a similar =
reason in PHP. In that people were just doing it wrong and didn't know =
any better. So I think making a more robust, and simpler interface to =
deal with these kinds of issues will encourage people to get it right in =
the future.

Sure, a nicer response/request interface, like the PSR proposals, would =
be great. Your mechanism for parsing raw request data does not solve =
this problem, in fact I suspect it would make it worse. Aside from that, =
it=E2=80=99d also severely hurt performance.
--
Andrea Faulds
http://ajf.me/