Edit report at https://bugs.php.net/bug.php?id=55815&edit=1
ID: 55815
Comment by: tad at tad-carlucci dot com
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:
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.
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2012-10-31 16:38:11] catch dot dave at gmail dot com
Whilst evert's example of providing access to the API might solve my original
issue, I would still lean
towards creating a new superglobal called _PUT.
1. PHP already has too many inconsistencies, let's not introduce another one.
POST, GET exist, adding PUT
is an obvious and consistant addition. Unless you wanted to deprecate existing
superglobals over time, I
would strongly suggest against providing a new way to do the same thing.
2. Whilst there are other HTTP methods, very few of them require/support parsing
multi-form data like POST
and PUT do (think of PATCH, DELETE, HEAD, etc).
------------------------------------------------------------------------
[2012-10-31 15:09:47] evert at rooftopsolutions dot nl
I just wanted to chime in this one..
I personally think that while having a _POST superglobal is convenient (and needed, for BC)
it's not necessarily a great design pattern. Especially in the case where you actually want
access to php://input, but PHP pre-emptively decided to parse it, and I'm left with an empty
stream.
So instead of extending this pattern to other HTTP methods (and don't kid yourself,
there's a bunch more than just PUT [1]), I feel a much better alternative would be to expose
the API that can actually parse multipart/form-data and takes a stream as input.
I feel this would solve the OP's use-case, is more flexible, and avoids the creation of
additional evil super-globals.
[1] http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-10
------------------------------------------------------------------------
[2012-10-22 05:23:06] tylerromeo at gmail dot com
The http/1.1 RFC does not specify any data type for the request body of any
request type, nor does the RFC for multipart/form-data specify the request type
it must be used with in HTTP. And as has been demonstrated by previous comments,
there exist legitimate cases where multipart/form-data would be useful in a PUT
request.
Let me first say that putting PUT data into $_POST is a bad idea. Hopefully that
is obvious enough. If this were to be implemented, it should use $_PUT (and
$_FILES, if necessary, along with it).
The real question that needs to be asked is whether it's worth implementing.
Technically, POST requests do not have any restriction on data types either. So
really we could just tell all web developers to parse their POST requests from
stdin like is suggested here for PUT. The reason PHP doesn't do that is because
POST data is so often encoded in a standard data format and used as such that it
helps developers tremendously to not force them to do such transformations
themselves.
So the issue is whether enough users will be using multipart/form-data in PUT
requests to warrant developers implementing a feature for it. Personally, I'm a
fan of uniformity, and I believe that if we're parsing the request body for a
POST request, then a PUT request should be treated no differently unless the
spec has a restriction (which it doesn't).
------------------------------------------------------------------------
[2012-07-08 18:38:30] johnston dot joshua at gmail dot com
Hi,
in regards to RFC 2616 and the comment:
"What this means is the HTTP RFC does not allow us to identify multipart/form-
data in a PUT request."
This section addresses the meaning of the request URI and NOT the request body.
In a POST request, the request URI should point to an entity that HANDLES the
request body in whichever way it sees fit. This COULD be by appending the
enclosed entity as an annotation to the given request URI, or appending a new
entity to a collection, etc.
In a PUT request, the enclosed entity should BE STORED AT or REPLACE the entity
that exists at the given request URI.
There is no reason why the Entity in question cannot be a multipart entity.
Here is a real-world example to illustrate this point using a messageboard as an
example.
A User creates a new topic:
(minimal headers shown for brevity)
POST /topics HTTP/1.1
Content-Type: multipart/form-data; boundary=--------------------------
-11401160922046879112964562566
Content-Length: ???
-----------------------------11401160922046879112964562566
Content-Disposition: form-data; name="comment"
This is a comment here
-----------------------------11401160922046879112964562566
Content-Disposition: form-data; name="attachment"; filename="attachment.png"
Content-Type: image/png
[binary image data here]
-----------------------------11401160922046879112964562566--
HTTP/1.1 201 Created
Location: /topics/1
Now we have a new topic referenced by /topics/1. Lets say the original user wants
to change his topic. HTTP says that you can use a PUT request to a given request
URI to replace an entity. If I wanted to replace the entity containing an image
and the comment I would issue
PUT /topics/1 HTTP/1.1
Content-Type: multipart/form-data; boundary=--------------------------
-11401160922046879112964562566
Content-Length: ???
-----------------------------11401160922046879112964562566
Content-Disposition: form-data; name="comment"
This is a comment here
-----------------------------11401160922046879112964562566
Content-Disposition: form-data; name="attachment"; filename="attachment.png"
Content-Type: image/png
[binary image data here]
-----------------------------11401160922046879112964562566--
As you can see here, the multipart/form-data request body is 100% valid.
------------------------------------------------------------------------
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