I'm using jQuery
file upload plugin.
I don't use the UI
part, only basic one.
When I do the following, I'm having an issue in IE
:
$('input#fileupload').fileupload({
url: '/upload',
done: function (e, data) {
if(data.result != null && $.trim(data.result) != '')
$('a#attachment').html(data.result);
}
//......................
on IE
the data.result
is an Object
(IE9
at least, not sure the others...)
On Chrome
/Firefox
is just the response Text
(simple plain text from the server).
Ideas?
Actually this is what the
jquery.iframe-transport.js
is for (the basic version also include this plugin as additional reference). What you need is to set thedataType
property tojson
and thejquery.iframe-transport
plugin will automatically parse theiframe
result, so you can have the same logic in your done handler.I just ran into the same problem, and I think it is due to the fact that XHR file uploads are not supported in IE (even 9). Here's what I believe is happening, and my solution:
Since Safari 5+, Firefox 4+, and Chrome support XHR file uploads, the fileupload plugin can transfer the files truly asynchronously, allowing for a pure text response from the server. This pure text response is available via
data.result
in thedone
event handler, and can be used easily.In IE, however, the file transfer occurs via a full page refresh in a hidden iframe, causing
data.result
in thedone
handler to be a fulldocument
object, with the response text wrapped deep inside<html><body><iframe><pre>
tags.Not only does this make it a pain to get to the data in IE, it makes the way you get to the data different between browsers.
My solution:
I set the
forceIframeTransport
option to true, which makes all browsers transfer files with a hidden iframe, like IE. It's unfortunate to miss out on XHR file uploads, but this at least gives us the same kind of response in all browsers. Then, in mydone
handler, I extracted the result from thedocument
object like so:In your case, I think the code would look something like this:
Also important to note here is that the Content Type of the response from my server is 'text/plain'. As you may have noticed, IE sometimes prompts the user to save or open a json response.
Here are a couple links that proved useful when resolving the problem: https://github.com/blueimp/jQuery-File-Upload/wiki/Browser-support (see 'XMLHttpRequest' section at bottom) https://github.com/blueimp/jQuery-File-Upload/wiki/Options (see 'forceIframeTransport' about 1/3 of the way down)
Hopefully this helps!
I believe issue can be in server response, you can make sure that server always send correct heading by using following code:
My problem, the reason is: Cross-Domain.
That is to say: in IE8/9, your server url should under the same domain as your js file. For jquery.iframe-transport.js is based on iframe, in which you can not cross-domain. Check hehe
You need not set the forceIframeTransport to true, for jquery.file-upload.js will judge the browser itself.
Your server should return Content-Type: text/html, or maybe text/plain, and your js could use dataType: 'json', no problem. At least, mine is.
When you debug, you could set breakpoint in jquery.iframe-transport.js at about line85, the try/catch block. If it can break there, that means iframe used, and you could get the response. At this time, you could see your json in the DOM(in iframe), but if you cross-domained, you would got response as undefined.
My code. No special:
The answers here were very useful to understand and solve the problem. I ended up with a satisfactory if hacky solution, that allows modern browsers to upload using
XmlHttpRequest
, and IE9 to useiframe
(didn't test with IE7/8) :jquery.iframe-transport.js
, it will take care of extracting the response from the iframe. Just include it in the page, thefileupload
plugin will use it.content-type
set to"text/plain"
, in order to avoid IE prompting the user to open the fileHere is the JS code :
Thanks to @Justin for a great explanation on this. I would avoid making queries for the "pre" element and instead make a simple solution like commented by @EnsignRicky