[solved] PHP file upload fails with UPLOAD_ERR_PARTIAL on Docker for Windows

Expected behavior

file upload with PHP works fine.

Actual behavior

PHP File upload fails often with error code UPLOAD_ERR_PARTIAL(the meaning of the code is described in http://php.net/manual/en/features.file-upload.errors.php).
It seems if the file size is over 64KB, uploads always fail. the upload of small file succeed.

The same script works fine with Docker Toolbox or Docker for Mac

Information

environment

[11:49:01.623][Program        ][Info   ] 1.12.0-rc4-beta19
[11:49:01.625][Program        ][Info   ] Starting on: 7/15/2016 11:49:01 AM
[11:49:01.626][Program        ][Info   ] Resources: C:\Program Files\Docker\Docker\Resources
[11:49:01.626][Program        ][Info   ] OS: Windows 10 Pro
[11:49:01.627][Program        ][Info   ] Edition: Professional
[11:49:01.627][Program        ][Info   ] Id: 1511
[11:49:01.627][Program        ][Info   ] Build: 10586
[11:49:01.628][Program        ][Info   ] BuildLabName: 10586.420.amd64fre.th2_release_sec.160527-1834
[11:49:01.629][Program        ][Info   ] Mixpanel Id: A1863E54-7EE3-438D-AC8C-CDBA83C34086
[11:49:01.630][Program        ][Info   ] Sha1: c84feba3aa680f426b8fa66f688388611267cd53

PHP script to reproduce this problem

<?php
    if ($_SERVER['REQUEST_METHOD'] == "POST") {
        var_dump($_FILES);
    }
?>
<html>
  <head><title>Test</title></head>
  <body>
  <form action="<?php echo $_SERVER['REQUEST_URI'] ?>" method="post" enctype="multipart/form-data">
      <input name="file" type="file"/>
      <input name="send" type="submit" value="send"/>
  </form>
  </body>
</html>

Steps to reproduce the behavior

  1. save the script above to your local machine with name “test.php”.
  2. run php image.: docker run -d -p 80:80 --name upload_debug php:5.6-apache
  3. copy the script saved at step 1 to the container.: docker cp test.php upload_debug:/var/www/html
  4. open http://localhost/test.php with the browser.
  5. upload some file with size over 64KB.
  6. dump of $_FILES which contains error is shown at the top of browser screen.

Hi
thanks for reporting. I can reproduce it and filed an internal issue tracking it.

I don’t see the UPLOAD_ERR_PARTIAL. Where would I be able to see that?

BTW, using http://docker/test.php seems to work better, but we are moving away from that model of networking.

rolf

Hello there,

I’m getting the same issue on localhost with Node.js and Hapi.js, I’m unable to upload files (multipart/form-data) and I get HPE_INVALID_METHOD errors in the logs. Using docker.local fixes the issue.

Let me know if more detailed logs, details or a repro would help.

Hi

Thanks for your reply.

I don’t see the UPLOAD_ERR_PARTIAL. Where would I be able to see that?
at step 6 of procedure fore reproducing, you see the text shown below at the top of browser screen.

array(1) { ["file"]=> array(5) { ["name"]=> string(8) "test.dat" ["type"]=> string(0) "" ["tmp_name"]=> string(0) "" ["error"]=> int(3) ["size"]=> int(0) } }

this is dump of global variable $_FILES. and UPLOAD_ERR_PARTIAL is indicated at the following part.

["error"]=> int(3)

error value int(3) indicates UPLOAD_ERR_PARTIAL. the correspondance between int value and error constant name is
described in http://php.net/manual/en/features.file-upload.errors.php.

using http://docker/test.php, The problem seems to be solved. Can I use this as a definitive solution ?

I have similar problems when trying to push files into a GIT repository. The Docker log contains the following output:

[20:19:22.764][ProxyProcess   ][Debug  ] com.docker.slirp.exe: tcp:0.0.0.0:10022:tcp:172.20.0.4:22: connected
[20:19:23.120][ProxyProcess   ][Error  ] com.docker.slirp.exe: Hvsock.write: Unix.Unix_error(Unix.ECONNABORTED, "read", "")
[20:19:23.123][ProxyProcess   ][Error  ] com.docker.slirp.exe: Hvsock.write: Unix.Unix_error(Unix.ECONNABORTED, "read", "")
[20:19:23.126][ProxyProcess   ][Error  ] com.docker.slirp.exe: Hvsock.shutdown_write: got Eof
[20:19:23.130][ProxyProcess   ][Error  ] com.docker.slirp.exe: tcp:0.0.0.0:10022:tcp:172.20.0.4:22 proxy failed with flow proxy b: write failed with Eof
[20:19:23.133][ProxyProcess   ][Error  ] com.docker.slirp.exe: Hvsock.write: Unix.Unix_error(Unix.ECONNABORTED, "read", "")

Please do not close this ticket. I’m also affected by this issue.
You found out a big flaw in Docker for Windows, let them fix it properly please.

I’m using the official WordPress docker image and wondered for over 2 days why I couldn’t upload images properly to the media manager. After running some tests, in my setup it would fail for a 28KB upload, but a 26KB worked.

I also tested your suggestion to use http://docker/test.php and it did indeed work.

The issue is I still can’t upload from outside the host (using a public domain name).

I’m curious how long it could take to fix this as I need this to work soon :stuck_out_tongue:

Have a great day all!

We’re using Docker for web development, I think maybe 15 to 20 colleagues are using Windows and they are all affected by this bug.
As workaround they’re using small size images, but they’re not able to test image resizing etc.

I’m not affected since I’m using MacOS but since I created the docker images we’re using I receive all the complaints :stuck_out_tongue:

So I ran some additional tests and through the web, the cutoff size is for a specific server configuration is usually the same. It might be different (original poster said 64KB, my experience was more along the lines of 27KB) might change depending on server configuration but I couldn’t find any setting that would make large uploads work.
OS: Windows 10 Pro Docker Version: 1.12.0-rc4

Thank you

Hi,

I am also affected by this on two different Windows 10 Pro installations and two different projects. I am not bringing any new info on the table but hope I can contribute to rise this topic up as the issue is blocking my productivity at the moment.

Have a good day all!

Just updated my Docker for Windows install to the latest release (which listed a fix for this).

Well it did solve my issue. I can now upload without issues.

According to my configuration, this ticket could be closed.

What about you guys?

Thanks for confirming that the fix worked!

I confirmed the problem is solved. I think this ticket can be closed.

We’ve tested the latest update, and it’s working fine again!