On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds <a...@ajf.me> wrote: > > > On 5 Nov 2014, at 22:29, Sherif Ramadan <theanomaly...@gmail.com> wrote: > > > > From all the people I've spoken with that have a problem with handling > PUT > > requests in PHP, it seems that they'd rather have PHP populate > > $_FILES/$_POST automatically in this case. Which would be relatively easy > > to do by modifying the default post reader function in the SAPI > > http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however, > that > > is itself a small BC break. > > > > Does anyone have any recommendations on what they think the best approach > > is? I'd appreciate any feedback/suggestions/constructive-criticism. > Thanks! > > I don’t think auto-populating for PUT/DELETE etc. is a good idea, they’re > quite different semantically. If I send a DELETE request to code expecting > a POST, and PHP pretends it’s a POST request, that’s bad. >
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. 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. > > However, I think the solution is simple: Add a function to do > multipart/form-data parsing. Not a suite of functions, not a class, just > one simple function. That way, for the few people that need it, they can do > $_POST = multipart_form_data_parse(file_get_contents(‘php://input')); and > their problem’s solved. > If we can’t expose the parser, we could also just add a function to force > population (force_parse_post_data() or something?). Again, this allows the > few that need this to do so explicitly, but doesn’t make $_POST allow it > for everyone else. > 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. 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. 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. > -- > Andrea Faulds > http://ajf.me/ > > > > >
