Hi All,

I am using Kendoui upload control (Async mode) in my asp.net application.I am able to successfully upload file using Google chrome,Firefox and IE10 but in IE9 file uploads successfully but success event of kendo upload does not fire and it always goes to error event.

kendo upload make ajax call to asp.net apiController where I have written sub which does not return.

so I get response with no content as mentioned in documentation to have empty response for success but still success event does not fire in IE9.

Please help me to fix this issue.

Regards
Imran

Hi Imran,

Please inspect the following demo, which works as expected, and compare the implementation and the server-side response (e.g. with Fiddler) with the ones in your application.

http://demos.kendoui.com/web/upload/events.html

Let me know if you need more information.

Greetings,
Dimo
the Telerik team

Hi,

I had this exact problem - Async upload works fine in IE10, Firefox, Chrome, etc., but not in IE9 or earlier.

It turned out that my problem was caused by a HTTP header we routinely add to our applications : X-FRAME-OPTIONS with a value of DENY. This prevents (or at least tries) to prevent ClickJacking attacks. In order to pass our security audits, we are required to add this header to all of our pages. The problem is that in IE9 and earlier, this header cause the Kendo Upload control (Async) to report an error. The file is uploaded successfully, but the Kendo control reports an error - even after following all the advice from Telerik in terms of result codes, empty strings, MIME types, etc. Once I removed the X-FRAME-OPTIONS HTTP header, the problem is gone - uploads reports success.

So, while my problem is fixed (kind of), I now have to explain to the security team why I cannot protect against ClickJacking attacks on some of our most important forms.

Could someone from Telerik/Kendo please advise if a future release of the Upload control would change this behaviour/problem in IE9 and earlier browsers?

Many thanks,

-Louis de Klerk

Hi Louis,

The described problem is pretty much outside our abilities to fix, because we cannot detect this HTTP header client-side and even if we do, the browser should not allow us to ignore it. However, have you tried setting the value of this header to SAMEORIGIN?

Regards,
Dimo
the Telerik team