Re: Native support - PUT request, multipart form data

That does not make any sense; applications could accept XML, CSV or whatever else just as well. The original proposal is not very useful. $_GET contains parsed query string info, $_POST contains parsed HTTP request body information if the media type is application/x-www-urlencoded or multipart/form-data. Deserializing that makes sense as the rules for it are in the HTTP spec. $_PUT/$_BODY/$_DATA would then have to contain the raw body contents, at least if the media type isn't one of the above, for consistency. That'd saves the file_get_contents() call, and given how a request handler uses at most once, I'm not sure such a change is worth it. David On 17 Aug 2014, at 04:18, Thomas Bley <mails@thomasbley.de> wrote: > Since we get JSON data, I would also consider $_JSON. > > Regards > Thomas > > > Park Framework wrote on 17.08.2014 01:47: > >> Variable $_PUT is already a popular name. >> Many for yourself already so it was called, at the bottom link. >> http://stackoverflow.com/search?q=PHP+%24_PUT >> >> But I like the name $_DATA - it is universal for any request method. >> For frontend developers, this name is very clear: >> $.ajax({ >> type: "PUT", >> contentType: "application/json", >> data: {"name": "value"} >> }); >> >> Except multipart form data, needed and native support for application/json. >> >> In many languages (Java, Python, ASP), it has long been there. >> It is a pity that the PHP in 2014, it has not yet implemented. >> >> >> >> 2014-08-17 2:14 GMT+03:00 Chris Wright <cw@daverandom.com>: >> >>> On 16 August 2014 23:41, Park Framework <park.framework@gmail.com> wrote: >>>> This is necessary for convenient use RESTful API. >>>> >>>> file_get_contents('php://input') - Very inconvenient >>>> >>>> I would like to finally get native support for PHP, preferably version >>> 5.6 >>> >>> The window for getting new features into 5.6 has passed, quite a long time >>> ago. >>> >>> Also, there is no $_PUT superglobal (and personally I do not think >>> there should be one), and it would not make sense to put this data >>> into $_POST (or any existing superglobal). Please explain the API you >>> envisage to get this working. >>> >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >