Skip to content
This repository has been archived by the owner on May 25, 2023. It is now read-only.

Streamed upload not working in Safari on OS/X #700

Closed
mperrando opened this issue Oct 12, 2011 · 3 comments
Closed

Streamed upload not working in Safari on OS/X #700

mperrando opened this issue Oct 12, 2011 · 3 comments

Comments

@mperrando
Copy link

When using the option multipart: false

the content of the request is 15 bytes long and contains only the string

[object Object]

I hope to find time to look further in to it.

Here follow the details of the user agent.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50

@blueimp
Copy link
Owner

blueimp commented Oct 12, 2011

Confirmed.
Thanks for posting the User Agent string with a detailed bug report.

The issue is that Safari 5.1 doesn't properly handle File or Blob objects anymore when given as argument to the XHR send method.
Previous Safari versions (e.g. Safari 5.0.5) didn't have this problem.

When searching for additional information on this issue I found a thread referring to the same problem with the Plupload plugin: moxiecode/plupload#320

Seems like Safari 5.1 also doesn't support the FileReader interface anymore, so non-multipart file uploads are simply not possible anymore with this browser version.

Until there is a better way to detect if the browser supports non-multipart XHR file uploads, you can set the multipart option with the exclusion of Safari 5.1 like this (thanks mperrando for the FileReader hint):

$('#fileupload').fileupload({
    multipart: !window.FileReader
});

@mperrando
Copy link
Author

I am using this condition

$('#fileupload').fileupload({
    multipart: !window.FileReader
});

On Safari it sets multipart to true, while on other browsers (Chrome, Firefox) sets it to false.

Could this solution have problems?

Actually I check also the Blob support in order to put multipart to false.

@blueimp
Copy link
Owner

blueimp commented Oct 13, 2011

That's actually a better way to check.
I've updated my comment above.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants