Edit report at https://bugs.php.net/bug.php?id=55815&edit=1
ID: 55815 User updated by: catch dot dave at gmail 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: 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). Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2012-06-27 00:57:48] phazei at gmail dot com Has this been reconsidered at all? Any update? ------------------------------------------------------------------------ [2012-04-16 19:15:43] catch dot dave at gmail dot com Hi theanomaly, I'd like to address your points. 1. As per my original request the manual page of "http://php.net/manual/en/features.file-upload.put- method.php" *does not* solve the problem, as it does not handle multipart form requests. 2. Implementing the parsing of multipart form data in PHP seems to be re- inventing the wheel when the code to correctly parse this already exists in PHP itself (to parse POST data). 3. Perhaps I am misunderstanding, but reading through both your quote and the rest of the 2616 spec, I fail to see how the spec precludes handling form-data in a PUT method, The section you quoted is saying that: * PUT must operate on the URI provided and not another one; and * that the difference between PUT and POST, is that POST URI defines the resource that operates on an entity, whereas a PUT request's URI identifies the entity itself. It is common to use the PUT verb to operate on existing entities in restful APIs (e.g. modifying the title of an existing book, you would send the new title as data, and not in the URI itself), which does not seem to violate this point either. The multipart form data is part of the original user request and should therefore be parseable--the user is sending the data (in multipart form) to operate on the URI using the PUT method. I don't think the spec is saying that you are not allowed to use/consider the data sent along with it-- as opposed to your interpretation which suggests the RFC is saying that all data other than the URI itself (whether multipart form encoded or not) should be ignored. 4. I had originally had some code that does exactly what you described, but it was nowhere near as robust as the existing code in PHP, which lead to me writing this request (re- invent the wheel). Furthermore, other languages (e.g. Ruby) do parse multipart data in PUT (not that that should be the primary reason). ------------------------------------------------------------------------ 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
