Edit report at https://bugs.php.net/bug.php?id=55815&edit=1
ID: 55815
Comment by: drew at funkhaus dot us
Reported by: catch dot dave at gmail dot com
Summary: PUT request data should be parsed just like POST
Status: Open
Type: Feature/Change Request
Package: Streams related
Operating System: All
PHP Version: 5.4.0beta1
Block user comment: N
Private report: N
New Comment:
Ember Data uses PUT when updating a REST API endpoint. It sends it as form-data.
PHP not working with PUT or DELETE means you can't use Ember Data, and thus big parts of the
Ember framework.
I'd love it if PHP had someway of parsing PUT or the other HTTP methods. Currently I have to
write a bunch of regex, which sucks.
Previous Comments:
------------------------------------------------------------------------
[2015-04-13 16:27:10] mike@php.net
Related To: Bug #61439
------------------------------------------------------------------------
[2015-04-13 16:20:59] mike@php.net
See also https://pecl.php.net/package/apfd
------------------------------------------------------------------------
[2014-10-20 17:41:24] googleguy@php.net
I think I have a better solution that should satisfy everyone involved.
I'm going to propose an RFC for PHP 7 that enables PHP user-land to implement an HttpRequest
interface, which will make it possible to override PHP's normal behavior for handling the
incoming HTTP request in whatever way they deem necessary.
This will mean doing away with GPCS superglobals altogether and have an HttpRequest object that will
handle the entire request process. Superglobal variables like $_GET and $_POST are confusing and
misleading, because they don't actually speak to the HTTP request VERB used in the request. So
the actual request processing should be delegated to a class that implements an HttpRequest
interface instead and the request can be handled directly by that class. To maintain default
behavior we should implement a default HttpRequest class and people will be able to extend that
class to override default behaviors (such as in the case of wanting to handle PUT requests
differently than PHP handles them right now).
Since this breaks backwards compatibility in a major way I think the proposed changes for PHP 7
should be OK.
------------------------------------------------------------------------
[2014-10-20 17:21:05] tad at tad-carlucci dot com
The issue is not constrained to PUT.
The HTTP specifications place no requirements upon the request body for ANY request methods (other
than OPTIONS and CONNECT).
The HTTP **ALLOWS** ANY request method which parses as a 'token'. In fact, it specifically
states that the methods listed (ie., GET, POST, etc.) are neither required nor the exclusive list.
It is quite possible, and fully compliant with the RFCs, for example, for a GET method to present a
request body containing multipart/form, or application/json, or even a request body using a private
MIME type.
Nor, I will admit that adding a request body to GET is unexpected. And, if one were to do so,
support from normal browsers should not be expected. But lack of support by any given client
software does NOT imply non-compliance. So, while it should be obvious, even though not explicitly
specified in the RFCs, an origin server MAY process request bodies presented with GET, but SHOULD
NOT require a request body, and SHOULD present a meaningful response when no request body is
present. For proper cache control, such a server SHOULD include a Vary header in the response so
that clients and proxies will be informed that the response to such a GET might vary depending upon
the content type, etc.
For maximum compliance, and support, of the HTTP RFCs. PHP SHOULD process all superglobals
regardless of request method. Specifically, $_GET, $_POST, $_REQUEST and $_FILES SHOULD be fully
processed, regardless of the actual request method.
------------------------------------------------------------------------
[2013-04-17 01:50:11] joaoh88 at gmail dot com
I really think it would be very useful to expose the API for parsing multipart
data, as restful services are increasing in popularity
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55815
--
Edit this bug report at https://bugs.php.net/bug.php?id=55815&edit=1