Owncloud 10 - IE 11 destroys files during upload

[jimk85]

When I use the Internet Explorer 11 upload a file (docx, zip) and then download it again, I can not open this file because it's destroyed.
With other browsers (Mozilla, Edge) it works, but unfortunately not with the IE11.

Does anybody have the same Problem?
Unfortunately, no errors can be found in Owncloud Log.

I have installed the Owncloud Server 10.0.0.12.

[michaelstingl]

Couldn't reproduce (tested with 150 MB *.ZIP file on demo.owncloud.com with IE11 on Win 8.1, 32-bit)

[jimk85]

Hi Michael,

Thank you for testing. I think I'll try again tomorrow with a new installation of Owncloud 10. Perhaps something went wrong with the upgrade from 9.1.5 to 10.

[jimk85]

I've just seen that the demo.owncloud.com is running in version 9.1.5. With this version I had no problems with the IE 11.

But when I upload a file in IE 11 to my OC server with version 10.0.0.12, these files are broken.

[ghost]

https://demo.owncloud.org/ might be another possibility to test, this has 10.0.0 RC5 (10.0.0.11).

[michaelstingl]

@jimk85 Good point 🤔 - I first checked version of https://demo.owncloud.org/status.php and then used https://demo.owncloud.com/ for the test.

[michaelstingl]

Now checked with owncloud.org:

@PVince81 We have a problem. /cc @CaptionF

[PVince81]

Looks like something is mangling the output headers ? Maybe something added two newlines there which made the browser believe that it's the start of the body.

But why only IE11 ? Does it need a special massage ?

[PVince81]

Can you test with the exact same file on 9.1.5 with release tarballs and 10.0.0 with release tarballs, no encryption ? And the exact same IE11 browser.

Please post the exact IE11 version.

Does it happen with any ZIP file ? Only ZIP file ? Is it with files over a certain size ?

I assume we're talking about real files, not "select multiple files and click download"

[PVince81]

once we get results to the above questions, here is maybe something to look into: https://connect.microsoft.com/IE/feedback/details/820435/ie-11-does-not-support-decoding-the-filename-parameter-of-content-disposition-http-header-when-using-mime-encoded-word-syntax-generated-by-an-asp-net-handler

[PVince81]

and... does it work with IE11 from Win7 ? (the original report was for Win8.1).

So far I suspect IE11 quirks that need to be worked around...

[jimk85]

Hi PVince81,

I hope I can help something.
I use the Internet Explorer Version 11.1066.14393.0 with Windows 10 Version 1607.

The encryption is deactivated and the destruction of the files seems to occur when uploading, because I can download and open old data with the IE.
JEPG, ZIP, DOCX are broken after the upload, but PDF works. The file size does not matter.

[PVince81]

@jimk85 can you check directly inside the "data" folder of your ownCloud instance whether the file is correct there or already broken ?

[jimk85]

The files uploaded with IE are already broken in the data folder.

I tried it again with the Firefox 52.0.2. These data are correct.

[PVince81]

Okay thanks. I wonder if it's a FileReader API thing that maybe IE11 doesn't do correctly.

[michaelstingl]

This is the version I used for testing:

It comes with the Win 8.1, 32-bit VM from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ .

[michaelstingl]

I applied all available updates, but the new IE11 version has the same problem.

[PVince81]

@VicDeo please debug this, apparently this is reproducible, thanks

[PVince81]

assigning to 10.0.1 as this is data loss material

cc @felixboehm @pmaier1

[VicDeo]

@PVince81 #21237 ? ;)

[VicDeo]

I observe the following headers sent by IE:
"Content-Type":"multipart/form-data; boundary=---------------------------7e1104130040",

while Chrome sends the file as
"Content-Type":"application/x-zip-compressed"

Does our dav implementation support multipart requests?

This is a multipart heading and tailing:

[PVince81]

Sabre DAV might support multipart but is maybe not expecting it here when using PUT.
Sad thing that IE11 still doesn't behave like other browsers.

But it could also be the blueimp jquery.fileupload that decides to use multipart for whatever reason.

Hmm looks like IE11 doesn't support FileReader API fully: http://caniuse.com/#search=filereader

[PVince81]

I did test with IE11 back then #21237 (comment) and it seemed to work. But maybe I didn't download the file when testing...

[PVince81]

Nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
...
ooooooooooooooooooooooooooo
...
ooooooooooooo

Not iframe transport 😢

IE11 what have you done ?

[PVince81]

@VicDeo did you delete your comment about iframe transport ? makes my comment above less dramatic

Back then we had some special Sabre plugin for iframe transport, which can only use POST, but removed it because it seemed it wasn't needed any more for IE10. So I'd find it strange that IE11 needs it back.

[VicDeo]

@PVince81 i'm not 100% sure in my previous comment.

1. https://github.com/owncloud/core/pull/21237/files#diff-9112ab761e9b96bef644fc2c1f6e35c1R189
   hints that sabre is not good with multipart

2. the issue seems to be pure scope-related. For some reasons $.support.xhrFileUpload is false at this point:
   https://github.com/owncloud/core/blob/master/apps/files/js/jquery.fileupload.js#L400
   when I change

multipart = options.multipart || !$.support.xhrFileUpload,

to

multipart = options.multipart,

everything works properly....

[VicDeo]

Looooool!
blueimp/jQuery-File-Upload@41d5054#diff-39a834a672a00c7e950ff109bc4342d6

blueimp committed on Oct 18, 2013

[PVince81]

PR merged. IE11 lovers rejoice! (if applicable)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.