On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds <a...@ajf.me> wrote:
>
> > On 6 Nov 2014, at 01:29, Sherif Ramadan <theanomaly...@gmail.com> wrote:
> >
> > 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’s 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.
>
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.
>
> > 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… I wouldn’t say that PHP really handles REST APIs badly, or that the
> userland approach is error-prone or less obvious. Using JSON isn’t
> difficult, you just do this:
>
> $data = json_decode(file_get_contents(‘php://input')) or die();
>
> This isn’t a hack. It’s a straightforward and obvious way to do this.
>
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.
>
> > 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’m aware it doesn’t. I don’t think that the PUT/DELETE issue really
> justifies your RFC. I don’t think there are any other problems which do,
> either. There are better ways to solve them.
>
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.
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.
>
> > 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’t think that really helps anyone.
>
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.
>
> > 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’d
> also severely hurt performance.
>
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.
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.
So in the case of a JSON payload rather than doing this...
$data = json_decode(file('php://input')) or die;
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?
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?
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.
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
