Native support - PUT request, multipart form data

10 years ago by Park Framework — view source

unread

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

10 years ago by Ferenc Kovacs — view source

unread

On Sun, Aug 17, 2014 at 12:41 AM, 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

feel free to create an rfc/implementation, I don't think it would be wise
to introduce it in 5.6.x(there is zero chance to have this in 5.6.0), but
our releaseprocess allows small self-contained features in a micro version,
so you can try targetting 5.6.next with the rfc but there is a chance that
some people will vote no who otherwise would support this in 5.next or 7.0.
I tend to agree that it would be better to move away from the method named
superglobals, but ofc. killing off $_GET/$_POST could only happen in a
major version.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

10 years ago by Park Framework — view source

unread

2014-08-17 12:22 GMT+03:00 Ferenc Kovacs tyra3l@gmail.com:

On Sun, Aug 17, 2014 at 12:41 AM, 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

feel free to create an rfc/implementation, I don't think it would be wise
to introduce it in 5.6.x(there is zero chance to have this in 5.6.0), but
our releaseprocess allows small self-contained features in a micro version,
so you can try targetting 5.6.next with the rfc but there is a chance that
some people will vote no who otherwise would support this in 5.next or 7.0.
I tend to agree that it would be better to move away from the method named
superglobals, but ofc. killing off $_GET/$_POST could only happen in a
major version.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

I have never written RFC, and I'm not a developer in C/C++.
Will correct if the RFC write the author of the patch.
Thank you.

10 years ago by Park Framework — view source

unread

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:

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.

10 years ago by Chris Wright — view source

unread

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.

IMO $_BODY would make more sense, $_DATA is very ambiguous.

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.

For the record, IMHO what is required here is a bundled OO request
abstraction extension, which would expose the underlying parser
routines in such a way that conversions of the input to a data
structure can be done with a single call. but not make any
assumptions about what is being done in the application. It has never
sat well with me that multipart inputs cannot be accessed as a raw
string.

I haven't actually given any though to what this API would look like though...

10 years ago by Andrea Faulds — view source

unread

Variable $_PUT is already a popular name.

$_POST isn’t really POST data nor is $_GET really GET data. We shouldn’t continue this silly naming tradition given both existing names are inaccurate.

We should have a query parameters array and a request body parameters array or blob.

Andrea Faulds
http://ajf.me/

10 years ago by Park Framework — view source

unread

Maybe, select the best API can community.
The main thing that it was not a reason for delaying.

2014-08-17 3:25 GMT+03:00 Andrea Faulds ajf@ajf.me:

Variable $_PUT is already a popular name.

$_POST isn’t really POST data nor is $_GET really GET data. We shouldn’t
continue this silly naming tradition given both existing names are
inaccurate.

We should have a query parameters array and a request body parameters
array or blob.

Andrea Faulds
http://ajf.me/

10 years ago by Thomas Bley — view source

unread

I think it would be great to have json encoded data from input body in $_REQUEST, just like parameters from the request-uri or form-urlencoded data.

Regards,
Thomas

Park Framework wrote on 17.08.2014 02:33:

Maybe, select the best API can community.
The main thing that it was not a reason for delaying.

2014-08-17 3:25 GMT+03:00 Andrea Faulds ajf@ajf.me:

Variable $_PUT is already a popular name.

$_POST isn’t really POST data nor is $_GET really GET data. We shouldn’t
continue this silly naming tradition given both existing names are
inaccurate.

We should have a query parameters array and a request body parameters
array or blob.

Andrea Faulds
http://ajf.me/

10 years ago by Park Framework — view source

unread

As a variant, not to create a new super global variables, can be
modified $_REQUEST to OOP style

class _REQUEST implements ArrayAccess // for backward compatibility
{
....
}

// get as array, from body request
$_REQUEST->body

// get all http request headers
$_REQUEST->headers

// get method request - POST, PUT...
$_REQUEST->method

// get Content-Type: multipart/form-data or application/json or ...
$_REQUEST->type

// get Content-Length request
$_REQUEST->length

It looks nice, but in practice it is more convenient to use an global
array - $_DATA or $_BODY or $_INPUT.

You can also do:

class _INPUT implements ArrayAccess
{

public function get($name, $default = null) {

if(isset($this->data[$name]) {

    return $this->data[$name];

 }
 else {
     return $default;
}

}

public function filter($name, $filter = FILTER_DEFAULT, $options = null) {

   return filter_var($this->data[$name], $filter, $options);

}
}

Examples:

$value = $_INPUT->get('varName1', 'myDefaultValue');
$email = $_INPUT->filter('varName2', FILTER_SANITIZE_EMAIL);

2014-08-17 3:25 GMT+03:00 Andrea Faulds ajf@ajf.me:

Variable $_PUT is already a popular name.

$_POST isn’t really POST data nor is $_GET really GET data. We shouldn’t continue this silly naming tradition given both existing names are inaccurate.

We should have a query parameters array and a request body parameters array or blob.

Andrea Faulds
http://ajf.me/

10 years ago by Thomas Bley — view source

unread

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:

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.

10 years ago by David Zuelke — view source

unread

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

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:

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.

10 years ago by Julien Pauli — view source

unread

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.

I'd say, why not ?
The patch should be trivial after all. $_INPUT ?

However, I'm not +1 to add this into a revision version.

Julien.P

10 years ago by Chris Wright — view source

unread

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.

(warning: nitpicking) actually, neither of these types are part of the
HTTP specification, the protocol specification doesn't deal with how
to handle content, only how to transmit it. RFC 2616 makes no mention
of it, and RFCs 7230-7235 don't either.

$_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.

I completely agree that there should be no special processing in the
case of any content-type that is not already handled by $_POST, but I
don't see the harm in handling those content types for arbitrary
methods.

Personally my ideal option would be to deprecate $_POST and $_GET in
favour of $_BODY and $_QUERY, respectively, which would be populated
the same way regardless of the request method (not just PUT and POST).
Similarly $_FILES would be populated for any multipart/form-data
request entity, regardless of request method.

No other content type could be reasonably handled since there is
ambiguity in how it would be handled (to take the alternate examples
David mentioned, json_decode() has options and there are a million and
one ways to handle XML). One might suggest having these configurable
with ini options or runtime functions, but both of these would largely
defeat the purpose of such automatic handling.

I agree with Julien that this is not the sort of thing that should go
into a point release, and if $_POST/$_GET were to be deprecated then
this would be a change for 7, probably with removal not before 8.

All that said, I personally don't find the requirement for writing 2
additional lines to parse the data such a huge burden. I'm not against
it, but neither will I be particularly upset if it doesn't happen.

10 years ago by Park Framework — view source

unread

2014-08-17 23:55 GMT+03:00 Chris Wright cw@daverandom.com:

Personally my ideal option would be to deprecate $_POST and $_GET in
favour of $_BODY and $_QUERY, respectively, which would be populated
the same way regardless of the request method (not just PUT and POST).
Similarly $_FILES would be populated for any multipart/form-data
request entity, regardless of request method.

Ок, then maybe you write the RFC?

I agree with Julien that this is not the sort of thing that should go
into a point release, and if $_POST/$_GET were to be deprecated then
this would be a change for 7, probably with removal not before 8.

Native support - PUT method, need today for many developers who would
like to find a solution in the near future.

10 years ago by David Zuelke — view source

unread

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.

(warning: nitpicking) actually, neither of these types are part of the
HTTP specification, the protocol specification doesn't deal with how
to handle content, only how to transmit it. RFC 2616 makes no mention
of it, and RFCs 7230-7235 don't either.

Sorry, typo, I meant to write HTML.

10 years ago by Larry Garfield — view source

unread

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.
(warning: nitpicking) actually, neither of these types are part of the
HTTP specification, the protocol specification doesn't deal with how
to handle content, only how to transmit it. RFC 2616 makes no mention
of it, and RFCs 7230-7235 don't either.

$_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.
I completely agree that there should be no special processing in the
case of any content-type that is not already handled by $_POST, but I
don't see the harm in handling those content types for arbitrary
methods.

Personally my ideal option would be to deprecate $_POST and $_GET in
favour of $_BODY and $_QUERY, respectively, which would be populated
the same way regardless of the request method (not just PUT and POST).
Similarly $_FILES would be populated for any multipart/form-data
request entity, regardless of request method.

No other content type could be reasonably handled since there is
ambiguity in how it would be handled (to take the alternate examples
David mentioned, json_decode() has options and there are a million and
one ways to handle XML). One might suggest having these configurable
with ini options or runtime functions, but both of these would largely
defeat the purpose of such automatic handling.

I agree with Julien that this is not the sort of thing that should go
into a point release, and if $_POST/$_GET were to be deprecated then
this would be a change for 7, probably with removal not before 8.

All that said, I personally don't find the requirement for writing 2
additional lines to parse the data such a huge burden. I'm not against
it, but neither will I be particularly upset if it doesn't happen.

Related, PHP-FIG is working on a set of common request/response object
interfaces. The main hold up right now is stream handling for the body,
driven mostly by how developer un-friendly the native PHP stream
handling is. Long-term I do believe that PHP should have support for
such objects natively and deprecate the super-globals, but that is a
non-trivial transition.