PHP is not able to read multipart/form-data with anything else than POST (PATCH, PUT, anyone?)
Best
Open comment sort options
Best
Top
New
Controversial
Old
Q&A
It makes more sense to access the input stream anyways.
file_get_contents('php://input');It's the only way to pass true JSON objects back and forth, instead of using formurlencoded nonsense.
The issue was specifically for multipart/form-data, not application/json
Yeah, reading php://input is the proper way to handle JSON request bodies, but you can't do a file upload with JSON. What if you need to PUT an image to replace an entity on the server, with clientside provided metadata?
The issue is completely valid.
I mean modern browser with the
FileReaderAPI can totally do that without using multipart/form-data. In some ways I would find this preferable, but I also wouldn't use PHP and I'd probably want to support multipart/form-data on my backend server (so it's easier to use the API withcurland whatnot)I don't see how the
FileReaderAPI changes the way the file is sent to the server. Does it imply that the files are sent as something different than "multipart/form-data"?You use the FileReader API to read file contents via JS and then send that (JSON-encoded if you like) to the server with a normal XHR or Fetch request.
no FileReader lets javascript read the binary file in as a ByteArray, (or text or a data url, etc) then you can do whatever you want with it (like upload via AJAX). It doesn't do any uploading on it's own.
That seems like it would massively increase the complexity of what you're doing, as well as making it impossible to use without JS and needlessly difficult to integrate with other tooling.
Which would be sent form-encoded most of the time.
Unless you are manually crafting some JSON with the file embedded as binary or Base64, or doing some other trick.
And that bug has been opened since 2011. I'm baffled. Worse thing is, they seem to be hiding behind some kind of excuse instead of fixing the issue.
mumbles that RFC 2616 is obsolete now
okay, it wasn't in 2012.
Damn, I had no idea! Thank you for pointing it out! For the uninitiated.
Opened: 2011
Status: open
total PHP
Is there any major project that doesn't have years old bugs still open? Well, I guess those that auto-close them with a comment "if this bug still exists, please report it again"…
What are you gonna do about it?
Laugh at it.
How mean-spirited. You should donate your time to fix one issue in a tool you dislike and has countless other quirks.
Well, that is quite the leap. No, an URI identifying a particular resource does not imply that multipart forms are not allowed. IMHO. All it means is that all changes should only be applied to that one particular resource.
Besides, the HTTP protocol does not have any clue about multiplart forms, or any other type of data encoding. All it knows is URIs, request methods, headers, and message bodies.
That's a misleading title. The linked bug report is about the $_POST super-global only working with POST requests. As beardedlinuxgeek points out, it is possible to read the multipart/form-data from PHP.
It is indeed possible to read it. It just isn't possible to parse it. At least not natively.
$postData = array(); $postDataString = file_get_contents('php://input'); if(mb_strlen($postDataString) > 0) { $postDataStrings = explode('&', $postDataString); foreach($postDataStrings as $postDataFieldString) { list($key, $value) = explode('=', $postDataFieldString, 2); $postData[urldecode($key)] = urldecode($value); } } print_r($postData);Do you actually suggest using urldecode to parse binary data?
I ran into this issue recently updating an object that had images attached to it using a restful api. Thank god for laravel method spoofing or I have no idea what mess I'd of had to make to fix the issue.
About the usage of something like this, if you are using the PUT method, should you not be parsing/processing the request body before saving, but saving it directly? Of course parsing it should be helpful to validate, for example.