Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 66.111.4.25 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+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com>
Date: Wed, 5 Nov 2014 21:36:15 -0500
Cc: Andrea Faulds <ajf@ajf.me>,
 Patrick ALLAERT <patrickallaert@php.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CC2E198C-1B05-4329-B13D-47787EBE9FFC@php.net>
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> <468730E8-4C38-49A3-A61A-59E107313D79@ajf.me> <CAL+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: willfitch@php.net (Will Fitch)


> On Nov 5, 2014, at 9:23 PM, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds <ajf@ajf.me> wrote:
>=20
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>=20
> Sure, $_POST has become synonymous with form data. I get that. I have =
no
> idea why you think populating it with data from other request types,
> however, would necessarily be a bad idea. If the request verb changes =
but
> the request contains a multipart mime, I see no reason not to populate =
it
> other than its name becoming more alluding. The meaning of PUT or =
DELETE is
> irrelevant here because all we're discussing is parsing the form data =
part
> of the multipart request (regardless of it's HTTP request VERB). So =
the
> meaning of the request verb isn't a justification for what to name the
> super global variable that gets populated either. The super global was
> intended for form data and I'm not changing that intention when =
allowing it
> to get populated by additional request verbs.

Easy - you have no idea what the input type is from PUT without checking =
the incoming type.  With POST, you know exactly what it is. PUT input =
code be JSON, multipart mime, a file or a whatever the dev wants.

>=20
>=20
>>=20
>>> 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.
>>=20
>> 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=99=
t
>> difficult, you just do this:
>>=20
>>    $data =3D json_decode(file_get_contents(=E2=80=98php://input')) or =
die();
>>=20
>> This isn=E2=80=99t a hack. It=E2=80=99s a straightforward and obvious =
way to do this.
>>=20
>=20
>=20
> Again, I think you're oversimplifying the problem. For one, you don't =
know
> that the payload is JSON unless you check the Content-type header =
yourself,
> and you really shouldn't have to since PHP could easily do this for =
you.
> Further more, you ignore all the other aspects of parsing the request =
body
> like when the PUT payload is a multipart mime, with both form data and =
a
> base64 encoded binary part or several of them. Again, PHP could just =
as
> easily take care of this in the same way it does now with POST and =
populate
> $_FILES and other form data accordingly.

You=E2=80=99re suggesting we change the fundamental approach of PHP in =
terms of what these superglobals represent.  I think from the feedback =
on this list, the approach you=E2=80=99re suggesting is far from =
welcome. Perhaps this is something you should stop arguing and start =
looking at improving your RFC with something that=E2=80=99s different =
and potentially acceptable.

>=20
>=20
>=20
>>=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.
>>=20
>> 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.
>>=20
>=20
> Well, the RFC is intended to tackle the current issues of dealing with =
the
> HTTP request where PHP now fails. Everything outside of form data and
> multipart requests specifically using POST fall under that umbrella. =
So I'm
> not sure why you think this RFC isn't justified.
>=20
> What are these better ways? Please, do elaborate. I'm more than open =
to a
> better solution even if that entails heading down a different path. I =
just
> don't think that a response of "this RFC doesn't help because there's
> something better", without stating what that is or why this RFC is =
less
> than acceptable is a very constructive response. In that it only aims =
to
> shutter the discussion and turn people away from it rather than help =
it
> evolve into something better.
>=20
>=20
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>=20
> That's not my solution. I actually posed the two options to contrast
> between their trade offs. I think that handling this stuff in PHP is =
likely
> to prove more efficient. What I hope to gain from this discussion is =
the
> optimal path to that implementation and what it would look like. =
Because
> the parts that really matter are just taking advantage of the existing =
PHP
> source code that handles things like parsing multipart data in the =
payload
> and perhaps refining it to also deal with a wider array of request =
types
> like PUT.
>=20
>=20
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>=20
> So as it stands, this RFC is still a draft, and I will admit I did a =
very
> poor job of constructing a reasonable proposal. Right now, yes, the =
idea of
> an interface that allows userland to do the parsing may likely prove =
more
> problematic.
>=20
> However, taking a closer look at the problem, perhaps the solution
> shouldn't be to attempt to tackle this problem entirely in userland =
after
> all. I've since realized that a simpler approach might solve this =
problem a
> lot better. For example, rather than exposing all of the underlying
> mechanisms that go in parsing the request data, why not just expose =
those
> that make things like handling a multipart form data request under =
HTTP
> verbs other than POST possible? There's very little added to =
accomplish
> this other than modifying the post hanlder in the SAPI to accept =
things
> like PUT and to alter the way content-type header is interpreted to =
decode
> the form data.
>=20
> So in the case of a JSON payload rather than doing this...
>=20
> $data =3D json_decode(file('php://input')) or die;
>=20
> it may prove helpful to know what the Content-type header was in the =
coming
> request and just let PHP decode the payload through json_decode =
itself,
> rather than urldecode?
>=20
> In the case of multipart form data from a PUT request it may also =
prove
> helpful to populate $_FILES accordingly so that the user doesn't have =
to?
>=20
> I'm pretty sure these are reasonable solutions and it's already what =
people
> are expecting. The only real question was whether or not we should =
create
> another superglobal for something like $_PUT or not. Which I'm =
personally
> not a fan of and hope we can find a better alternative, because then =
people
> might start expecting more super global variables for other request =
types
> in the future and it only lends itself to increasing the ambiguity =
about
> how to handle each request.
>=20
>=20
>=20
>=20
>=20
>> --
>> Andrea Faulds
>> http://ajf.me/
>>=20
>>=20
>>=20
>>=20
>>=20