PUT request not responding to multipart/form-data #9226

greatwitenorth · 2013-10-06T19:43:31Z

In the recent build of Laravel it seems to not be responding to PUT requests that are encoded with multipart/form-data. It only works with application/x-www-form-urlencoded. I believe the http spec states that it should work no matter what you use.

For example when sending a request using mulitpart/form-data I observe the following:

$d1 = file_get_contents("php://input")); // Contains the correct data
$d2 = Input::all(); // This returns an empty result

I tried to track it back through the code and the issue definitely seems to be the Symfony Request package and not the Laravel framework itself. The data never gets passed to the Input object in Laravel.

The text was updated successfully, but these errors were encountered:

robertblock · 2013-11-26T23:16:21Z

EDIT: This is strange. The below problem resolved itself literally overnight, with no change. Now I get the following result when I POST using Content-Type: multipart/form-data:

{
"request":{
"test":"message"
},
"phpinput":""
}

If anyone knows what may have caused this, please let me know. I used two different clients to test.

OLD POST:

I am experiencing a similar, if not the same issue.

Recently I started getting validation errors when POSTing to my REST interface with Content-Type: multipart/form-data. Content-Type: application/x-www-form-urlencoded is working.

Here is my testing function:

/**
 * @Rest\Route("/testtype")
 */
public function postTypeTestAction()
{
    $request = $this->getRequest()->request->all();
    $phpContents = file_get_contents("php://input");

    return FOSView::create()->setStatusCode(200)->setData(array('request'=>$request, 'phpinput' => $phpContents));
}

When I POST using Content-Type: application/x-www-form-urlencoded:

{
  "request":{
    "test":"message"
   },
  "phpinput":"test=message"
}

When I POST using Content-Type: multipart/form-data:

{
  "request":[
  ],
 "phpinput":"------WebKitFormBoundaryFyQqAxqqfuhWzHUq\r\nContent-Disposition: form-data; name=\"test\"\r\n\r\nmessage\r\n------WebKitFormBoundaryFyQqAxqqfuhWzHUq--\r\n"
}

I'm using Symfony 2.3.7 and FOSRestBundle 1.0.0.

erdemkeren · 2014-02-05T13:20:58Z

Anything new here? This one is a little bit important I think.

robertblock · 2014-02-05T16:33:02Z

I found the following, which leads me to think this is not a Symfony issue.:

php://input does not work with enctype="multipart/form-data"
Different testing tools provided different results. I am now using Postman - REST Client (a Chrome extension) and I'm having no problems.
My issue resolved itself overnight, with no change to code or server. This leads me to believe it was a caching issue. I just don't know where.

My stackoverflow post doesn't offer much more info, but here it is: http://stackoverflow.com/questions/20229915/posting-with-content-type-multipart-form-data-results-in-empty-request-body

I am not a dev on this project but -- out of curiosity -- what are you seeing, specifically.

jakzal · 2014-02-25T23:14:34Z

$this->getRequest()->request stores data sent via POST and it will only contain something if a request was submitted via this method. Since $this->getRequest()->request works as expected, what's the actual issue here?

php://input is not available with enctype="multipart/form-data" (see php docs) - however, you can read it with PUT.

P.S. PUT and POST requests treat multipart/form-data in different ways: https://bugs.php.net/bug.php?id=55815

erdemkeren · 2014-02-27T08:56:12Z

The problem is that; one of the users of symfony, (which is Laravel 4.*) uses resource controllers; which uses put requests to handle update requests.

When the developer is updating an existing post for example, with images (multipart/form-data) and some input information, "Input::get(), Input::all()" returns an empty array or whatever.

As far as I see; php.net won't use php://input with put requests because of the requirement specifications it relies on. And they are doing what they SHOULD do.

That makes us look for a solution and redirects us to here because our update functions are malfunctioning.

I no longer understand which package has the problem. Or if that is not a problem; what is the right way of doing that properly.

Should we really use [POST]http://example.com/posts/1/update instead of using [PUT]http://example.com/posts/1 ?

greatwitenorth · 2014-02-27T15:15:51Z

Yes, the issue is php does not respond in the same way it does for posts. It should since the HTTP spec points out that PUT is not limited to a specific Content-Type. So this may in fact be a PHP bug (which has now been open since 2011). Here's a SO response with some links detailing the HTTP spec: http://stackoverflow.com/a/6115547/862636

…sts. PHP, and by extension, Symfony does not support multipart/form-data requests when using any request method other than POST. This limits the ability to implement RESTful architectures using Symfony. This is a follow up to Pull Request symfony#849 I made a few, and addresses concerns brought up by Saldaek at the time. I have implemented this functionality by manually decoding the php://input stream when the request type is PUT, DELETE or PATCH and the Content-Type header is mutlipart/form-data. The implementation is based on an example by [netcoder at stackoverflow](http://stackoverflow.com/a/9469615). This is necessary due to an underlying limitation of PHP, as discussed here: https://bugs.php.net/bug.php?id=55815. This fixes symfony#9226. __Security Concerns__ The main concern I had while implementing this feature, was working with PHP's assumptions as to what constituted an uploaded file. Since the files that this commit creates are not done so through PHP's usual uploaded file mechanisms, none of the uploaded file functions (such as is_uploaded_file, move_uploaded_file) will work with them. As such, I had to implement a mechanism for recording the uploaded files as they were created, so that Symfony's UploadedFile class could be sure that it was not moving non-uploaded files. To achieve this, I added a static array to the UploadedFile class called $files. Any uploaded files that are created outside of PHP's normal mechanism can be recorded here. UploadedFile can then check this list to ensure that if is_uploaded_file returns false, that the file being moved is in fact an uploaded file. This results in two changes to UploadedFile: Firstly, the is_uploaded_file check had to be expanded to also check if the file was recorded in UploadedFile::$files. Secondly, the move_uploaded_file needed to be changed to rename. The change of move_uploaded_file to rename might raise a few red flags, but I do not believe this is a problem. Before rename is called, UploadedFile calls isValid, which checks that the file either is_uploaded_file, or is a member of UploadedFile::$files. Therefore the use of move_uploaded_file is an unnecessary double check (even without these changes). Fix symfony#9226.

…sts. PHP, and by extension, Symfony does not support multipart/form-data requests when using any request method other than POST. This limits the ability to implement RESTful architectures using Symfony. This is a follow up to Pull Request symfony#849 I made a few years ago, and addresses concerns brought up by Saldaek at the time. I have implemented this functionality by manually decoding the php://input stream when the request type is PUT, DELETE or PATCH and the Content-Type header is mutlipart/form-data. The implementation is based on an example by [netcoder at stackoverflow](http://stackoverflow.com/a/9469615). This is necessary due to an underlying limitation of PHP, as discussed here: https://bugs.php.net/bug.php?id=55815. This fixes symfony#9226. __Security Concerns__ The main concern I had while implementing this feature, was working with PHP's assumptions as to what constituted an uploaded file. Since the files that this commit creates are not done so through PHP's usual uploaded file mechanisms, none of the uploaded file functions (such as is_uploaded_file, move_uploaded_file) will work with them. As such, I had to implement a mechanism for recording the uploaded files as they were created, so that Symfony's UploadedFile class could be sure that it was not moving non-uploaded files. To achieve this, I added a static array to the UploadedFile class called $files. Any uploaded files that are created outside of PHP's normal mechanism can be recorded here. UploadedFile can then check this list to ensure that if is_uploaded_file returns false, that the file being moved is in fact an uploaded file. This results in two changes to UploadedFile: Firstly, the is_uploaded_file check had to be expanded to also check if the file was recorded in UploadedFile::$files. Secondly, the move_uploaded_file needed to be changed to rename. The change of move_uploaded_file to rename might raise a few red flags, but I do not believe this is a problem. Before rename is called, UploadedFile calls isValid, which checks that the file either is_uploaded_file, or is a member of UploadedFile::$files. Therefore the use of move_uploaded_file is an unnecessary double check (even without these changes). Fix symfony#9226.

PHP, and by extension, Symfony does not support multipart/form-data requests when using any request method other than POST. This limits the ability to implement RESTful architectures using Symfony. This is a follow up to Pull Request symfony#849 I made a few years ago, and addresses concerns brought up by Saldaek at the time. I have implemented this functionality by manually decoding the php://input stream when the request type is PUT, DELETE or PATCH and the Content-Type header is mutlipart/form-data. The implementation is based on an example by [netcoder at stackoverflow](http://stackoverflow.com/a/9469615). This is necessary due to an underlying limitation of PHP, as discussed here: https://bugs.php.net/bug.php?id=55815. This fixes symfony#9226. __Security Concerns__ The main concern I had while implementing this feature, was working with PHP's assumptions as to what constituted an uploaded file. Since the files that this commit creates are not done so through PHP's usual uploaded file mechanisms, none of the uploaded file functions (such as is_uploaded_file, move_uploaded_file) will work with them. As such, I had to implement a mechanism for recording the uploaded files as they were created, so that Symfony's UploadedFile class could be sure that it was not moving non-uploaded files. To achieve this, I added a static array to the UploadedFile class called $files. Any uploaded files that are created outside of PHP's normal mechanism can be recorded here. UploadedFile can then check this list to ensure that if is_uploaded_file returns false, that the file being moved is in fact an uploaded file. This results in two changes to UploadedFile: Firstly, the is_uploaded_file check had to be expanded to also check if the file was recorded in UploadedFile::$files. Secondly, the move_uploaded_file needed to be changed to rename. The change of move_uploaded_file to rename might raise a few red flags, but I do not believe this is a problem. Before rename is called, UploadedFile calls isValid, which checks that the file either is_uploaded_file, or is a member of UploadedFile::$files. Therefore the use of move_uploaded_file is an unnecessary double check (even without these changes). Fix symfony#9226.

Chekote · 2014-03-04T16:54:02Z

I have submitted a fix for this. Please take a look at pull #10381 and let me know what you think.

Sorry for the reference spam!

PHP, and by extension, Symfony does not support multipart/form-data requests when using any request method other than POST. This limits the ability to implement RESTful architectures using Symfony. This is a follow up to Pull Request symfony#849 I made a few years ago, and addresses concerns brought up by Saldaek at the time. I have implemented this functionality by manually decoding the php://input stream when the request type is PUT, DELETE or PATCH and the Content-Type header is mutlipart/form-data. The implementation is based on an example by [netcoder at stackoverflow](http://stackoverflow.com/a/9469615). This is necessary due to an underlying limitation of PHP, as discussed here: https://bugs.php.net/bug.php?id=55815. This fixes symfony#9226. __Security Concerns__ The main concern I had while implementing this feature, was working with PHP's assumptions as to what constituted an uploaded file. Since the files that this commit creates are not done so through PHP's usual uploaded file mechanisms, none of the uploaded file functions (such as is_uploaded_file, move_uploaded_file) will work with them. As such, I had to implement a mechanism for recording the uploaded files as they were created, so that Symfony's UploadedFile class could be sure that it was not moving non-uploaded files. To achieve this, I added a static array to the UploadedFile class called $files. Any uploaded files that are created outside of PHP's normal mechanism can be recorded here. UploadedFile can then check this list to ensure that if is_uploaded_file returns false, that the file being moved is in fact an uploaded file. This results in two changes to UploadedFile: Firstly, the is_uploaded_file check had to be expanded to also check if the file was recorded in UploadedFile::$files. Secondly, the move_uploaded_file needed to be changed to rename. The change of move_uploaded_file to rename might raise a few red flags, but I do not believe this is a problem. Before rename is called, UploadedFile calls isValid, which checks that the file either is_uploaded_file, or is a member of UploadedFile::$files. Therefore the use of move_uploaded_file is an unnecessary double check (even without these changes). Fix symfony#9226. Conflicts: src/Symfony/Component/HttpFoundation/Tests/RequestTest.php

Chekote · 2014-03-05T13:21:43Z

This is currently being shot down by all commenters. If you guys want/need this, you need to weigh in.

PHP, and by extension, Symfony does not support multipart/form-data requests when using any request method other than POST. This limits the ability to implement RESTful architectures using Symfony. This is a follow up to Pull Request symfony#849 I made a few years ago, and addresses concerns brought up by Saldaek at the time. I have implemented this functionality by manually decoding the php://input stream when the request type is PUT, DELETE or PATCH and the Content-Type header is mutlipart/form-data. The implementation is based on an example by [netcoder at stackoverflow](http://stackoverflow.com/a/9469615). This is necessary due to an underlying limitation of PHP, as discussed here: https://bugs.php.net/bug.php?id=55815. This fixes symfony#9226. __Security Concerns__ The main concern I had while implementing this feature, was working with PHP's assumptions as to what constituted an uploaded file. Since the files that this commit creates are not done so through PHP's usual uploaded file mechanisms, none of the uploaded file functions (such as is_uploaded_file, move_uploaded_file) will work with them. As such, I had to implement a mechanism for recording the uploaded files as they were created, so that Symfony's UploadedFile class could be sure that it was not moving non-uploaded files. To achieve this, I added a static array to the UploadedFile class called $files. Any uploaded files that are created outside of PHP's normal mechanism can be recorded here. UploadedFile can then check this list to ensure that if is_uploaded_file returns false, that the file being moved is in fact an uploaded file. This results in two changes to UploadedFile: Firstly, the is_uploaded_file check had to be expanded to also check if the file was recorded in UploadedFile::$files. Secondly, the move_uploaded_file needed to be changed to rename. The change of move_uploaded_file to rename might raise a few red flags, but I do not believe this is a problem. Before rename is called, UploadedFile calls isValid, which checks that the file either is_uploaded_file, or is a member of UploadedFile::$files. Therefore the use of move_uploaded_file is an unnecessary double check (even without these changes). Fix symfony#9226. Conflicts: src/Symfony/Component/HttpFoundation/Tests/RequestTest.php

fabpot · 2014-12-24T09:52:39Z

Closing as the corresponding PR was closed a while ago.

symfony/symfony#9226

symfony/symfony#9226 (reverted from commit 806f37a)

shyandsy · 2017-05-29T18:06:24Z

@fabpot
the bug still there

lmasforne · 2018-02-22T12:45:26Z

@shyandsy can you confirm to me this bug still exist on Symfony 4 ?

edwardselby · 2018-03-08T15:10:17Z

We still can't read PUT using multipart/form-data in Symfony 4. x-www encoding works.

Simperfit · 2019-01-17T10:27:57Z

@fabpot I can confirm that this PR does not fix the PUT bug :/.

Chekote · 2019-01-17T15:29:48Z

@Simperfit The PR was closed because it was rejected. It was never merged.

Arkemlar · 2019-01-18T03:00:28Z

@lmasforne

@shyandsy can you confirm to me this bug still exist on Symfony 4 ?

Yes it is.

Arkemlar · 2019-01-18T03:01:19Z

We still can't read PUT using multipart/form-data in Symfony 4. x-www encoding works.

For me it is not an option since I need to post files combined with other data. The only workaround is using _method=PUT parameter but it is so ugly when you develop an API.

Nek- · 2019-01-18T15:57:19Z

Hello guys. I really think this will never be done directly in Symfony considering it's based on a PHP behavior that differs in case of PUT multipart/form-data. Supporting this would add a huge set of classes (I think of streaming file transfert and complete form data decoding support, which is are both not trivial) to make it work just like POST does. For a very edgy case.

Please consider implementing your own solution. This ticket should be close IMO as it is out of the scope of Symfony.

Chekote · 2019-01-18T18:38:08Z

@Nek- I agree that this should be fixed in PHP and not Symfony. But implementing support for form data decoding is not a huge amount of work. I already implemented it in #10381, but it was rejected by @fabpot because he (correctly) believes it should be fixed in PHP instead of having Symfony take on the responsibility of manually decoding form data.

Chekote · 2019-01-18T18:38:55Z

Here is the issue in PHP's bug tracker. It's 8 years old now. If you want it you should vote and weigh in here: https://bugs.php.net/bug.php?id=55815

nicolas-grekas · 2019-02-25T10:48:11Z

Closing as there is nothing to keep track of in the Symfony repo. See php bug above.

nicolas-grekas · 2019-02-25T10:49:14Z

ping @jpauli or @pmmaga maybe if you want to have a look at the PHP bug?

DazDotOne · 2020-06-25T13:36:00Z

I've been trying to figure out how to work with this issue without having to break RESTful convention and boy howdie, what a rabbit hole, let me tell you.

I'm adding this anywhere I can find in the hope that it will help somebody out in the future.

I've just lost a day of development firstly figuring out that this was an issue, then figuring out where the issue lay.

As mentioned, this isn't a symfony (or laravel, or any other framework) issue, it's a limitation of PHP.

After trawling through a good few RFCs for php core, the core development team seem somewhat resistant to implementing anything to do with modernising the handling of HTTP requests. The issue was first reported in 2011, it doesn't look any closer to having a native solution.

That said, I managed to find this PECL extension. I'm not really very familiar with pecl, and couldn't seem to get it working using pear. but I'm using CentOS and Remi PHP which has a yum package.

I ran yum install php-pecl-apfd and it literally fixed the issue straight away (well I had to restart my docker containers but that was a given).

I believe there are other packages in various flavours of linux and I'm sure anybody with more knowledge of pear/pecl/general php extensions could get it running on windows or mac with no issue.

rrenteria-dev · 2021-09-01T00:27:12Z

Also lost a day of development like @DazDotOne
Had to change the request to POST, breaking REST convention.

DazDotOne · 2021-09-01T08:46:06Z

@rrenteria-dev What OS are you using?

Nek- · 2021-09-01T09:30:03Z

@rrenteria-dev you can use ?_method=PATCH at the end of the URL to change the method. Learn more here

But I also time to time lose a lot of time on this... I'm sure the PHP team would accept a fix 😬 .

alireaza · 2022-12-10T10:42:46Z

You can use this package:
https://github.com/alireaza/php-form-data

And this is a Laravel Service Provider for above package:
https://github.com/alireaza/laravel-form-data

Nayte91 · 2023-02-22T21:39:28Z

ping @jpauli or @pmmaga maybe if you want to have a look at the PHP bug?

As this issue begin to grind my gears, I would like to propose a RFC.
@nicolas-grekas or @dunglas do you have, in few seconds (I don't want to bother you), resources about the whole topic? I ofc have the old RFC, and also the HTTP/1.1 RFC and its update. Anything else should be known to begin? What on the PHP side?

nicolas-grekas · 2023-02-22T21:54:54Z

Please open a new issue if you want to discuss any idea, or send a PR if you have code of course.
My point here is that a comment on a closed issue is going to be lost.

dimadeush · 2023-08-01T14:34:51Z

@nicolas-grekas So it seems that currently we have only one way to change PUT request to the POST if we need, f.e., upload files, right?
Thanks in Advance

derrabus · 2023-08-01T14:49:01Z

Yes.

derrabus · 2023-08-01T14:52:19Z

I'm locking this issue to prevent further support questions.

Please read the PHP bug to learn why things are this way, use GitHub discussions if you need support or open a new issue if you have new ideas on how to tackle the problem.

Chekote mentioned this issue Mar 4, 2014

[HttpFoundation] added multipart/form-data for PUT, DELETE and PATCH #10381

Closed

andheiberg mentioned this issue Apr 4, 2014

[Proposal] Form Data for PUT, Patch and DELETE requests laravel/framework#4043

Closed

fabpot closed this as completed Dec 24, 2014

LouisTrezzini pushed a commit to KIClubinfo/upont that referenced this issue Dec 31, 2015

Fix erreur 400 sur les patch d'event

806f37a

symfony/symfony#9226

LouisTrezzini pushed a commit to KIClubinfo/upont that referenced this issue Dec 31, 2015

Fix erreur 400 sur les patch d'event

24f23a0

symfony/symfony#9226 (reverted from commit 806f37a)

teohhanhui mentioned this issue Jul 20, 2017

How to make file upload easier? api-platform/core#1242

Closed

devcircus mentioned this issue Nov 2, 2017

Input from PUT requests sent as multipart/form-data is unavailable laravel/framework#13457

Closed

mathieutu mentioned this issue Feb 26, 2018

[BUG] Request is not handled by php when sending file by PUT method. spatie/form-backend-validation#48

Closed

fabpot reopened this Jan 17, 2019

xabbuh added the Bug label Jan 17, 2019

carsonbot added the Status: Needs Review label Jan 17, 2019

nicolas-grekas closed this as completed Feb 25, 2019

malantb mentioned this issue Mar 28, 2020

Problem with send multipart form data in method PUT #36146

Closed

xabbuh mentioned this issue Apr 1, 2020

PUT Request empty FileBag #36307

Closed

Nayte91 mentioned this issue Feb 22, 2023

PHP RFC for multipart/form-data handling on all verbs #49503

Closed

symfony locked and limited conversation to collaborators Aug 1, 2023

Uh oh!

PUT request not responding to multipart/form-data #9226

PUT request not responding to multipart/form-data #9226

Comments

greatwitenorth commented Oct 6, 2013

robertblock commented Nov 26, 2013

Uh oh!

erdemkeren commented Feb 5, 2014

Uh oh!

robertblock commented Feb 5, 2014

Uh oh!

jakzal commented Feb 25, 2014

Uh oh!

erdemkeren commented Feb 27, 2014

Uh oh!

greatwitenorth commented Feb 27, 2014

Uh oh!

Chekote commented Mar 4, 2014

Uh oh!

Chekote commented Mar 5, 2014

Uh oh!

fabpot commented Dec 24, 2014

Uh oh!

shyandsy commented May 29, 2017

Uh oh!

lmasforne commented Feb 22, 2018

Uh oh!

edwardselby commented Mar 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Simperfit commented Jan 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Chekote commented Jan 17, 2019

Uh oh!

Arkemlar commented Jan 18, 2019

Uh oh!

Arkemlar commented Jan 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nek- commented Jan 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Chekote commented Jan 18, 2019

Uh oh!

Chekote commented Jan 18, 2019

Uh oh!

nicolas-grekas commented Feb 25, 2019

Uh oh!

nicolas-grekas commented Feb 25, 2019

Uh oh!

DazDotOne commented Jun 25, 2020

Uh oh!

rrenteria-dev commented Sep 1, 2021

Uh oh!

DazDotOne commented Sep 1, 2021

Uh oh!

Nek- commented Sep 1, 2021

Uh oh!

alireaza commented Dec 10, 2022

Uh oh!

Nayte91 commented Feb 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nicolas-grekas commented Feb 22, 2023

Uh oh!

dimadeush commented Aug 1, 2023

Uh oh!

derrabus commented Aug 1, 2023

Uh oh!

derrabus commented Aug 1, 2023

Uh oh!

edwardselby commented Mar 8, 2018 •

edited

Loading

Simperfit commented Jan 17, 2019 •

edited

Loading

Arkemlar commented Jan 18, 2019 •

edited

Loading

Nek- commented Jan 18, 2019 •

edited

Loading

Nayte91 commented Feb 22, 2023 •

edited

Loading