by Andreas

Jquery + JSON: IE8/IE9 treats response as downloadable file

We’ve recently been working with the pretty brilliant web based elFinder file manager. This component has a truckload of features, but for a very specific function (uploading files through the web browser) we came across a tricky problem. Upon receiving a JSON response from an HTTP handler (.asxh) Internet Explorer 8 triggered the following warning:

To Help Protect Your Security, Internet Explorer has blocked this website from displaying content with security certificate errors. Click here for options…


After opting for “Download file”, subsequent responses just triggered the “Save file” dialog box. The contents of this file was the perfectly fine JSON response, but this was not understood by Internet Explorer 8. In Internet Explorer 9 the warning was supressed and the response seemed to simply be ignored, leaving our jQuery component waiting for its JSON reply in vain. Chrome, Opera and Firefox had no issues, and processed the response as pure JSON.

After a fair bit of research trying to find the bug both server and client side, it turned out that Internet Explorer didn’t like that the Content-Type in the response header was "application/json”. Setting the Content-Type to “text/html” specifically for IE in the .asxh handler before returning the JSON response did the trick. It now works as expected across all browsers.

A simple method checks the browser and updates the content type if applicable (note: this is just an extract):

        private static string SetContentTypeBasedOnBrowserAndCommand(HttpContext context)
            var contentType = "application/json"; // default
            // if browser is IE
            if (DegreeCore.Util.BrowserUtil.IsIE(context.Request.Browser))
                // override response
                 contentType = "text/html";

            return contentType;



The non-reversible hair loss from occational problems like this has yet again been put on hold – for now.

Tags: ,
  • Zlatko

    I have the same problem (json) in Firefox!???

  • Andreas

    Really? Have you tried changing the content type to “text/html” before returning the response for FF as well?

    Another thing you can check is what the “accepted types” in the Request header says for your application. Make sure it includes “text/html” or at least “*/*”, or else the browser might not accept it and only offer you the option to save it as a file.

    Let me know how you go, because this could be useful for others!

  • Zlatko

    it seems that everything is ok!? But it isn’t!!!

    elFinder 2.0

    I have the same message when open elFinder!

    Invalid backend response.
    Data is not JSON.

  • Zlatko

    In head I have: meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″

  • Andreas

    It was actually in ElFinder my problem occured as well. Have you written your own .NET connector, or is it in PHP or some other language? While researching this problem I came across an article with the same “Invalid backend response. Data is not JSON” error as the one you have:

    I originally posted my problem there as well, but was told this had to be a connector issue in my case. Maybe that article might help you? The bugfix for that particular problem is shown here:

  • Andreas

    Regarding your last comment:

    Is that from the response header? Can you also send the content-type and accepted parameters from the request header?

  • Zlatko

    User-Agent Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
    Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language sl,en-gb;q=0.7,en;q=0.3
    Accept-Encoding gzip, deflate

    RESPONSE HTTP/1.1 200 OK
    Server nginx/1.0.6
    Content -Type text/html
    X-Powered-By PHP/5.3.8
    Content-Encoding gzip

  • Andreas


    Which platform are you running ElFinder on? PHP, Python, .NET… ? And which operation triggers this problem (in my case it was the UPDATE command)? Have you written the connector yourself or is it one of the ones listed here:

  • Zlatko

    Sorry! Wrong data!!!

  • Andreas

    Does that mean you found and solved the problem?

  • Zlatko

    Not yet:(

  • Aydar Akhmetov

    I broke my brains while resolving this problem.
    My solution:

    header(‘Content-Type: text/plain; charset=utf-8’);
    header(‘X-Content-Type-Options: nosniff’);

  • Zlatko

    Thanks! I will try tomorrow!:)

  • Aydar Akhmetov

    Helped? :)

  • Andreas

    Zlatko: did Aydars solution work?

  • jkella

    HI Andreas,

    Do we any option to run jquery drag and drop in Internet Explorer ..

  • Andreas

    jQuery drag and drop should work in all browsers, but not sure I understand the question :) Is it related to this post, or just a general jQuery question?

  • Shamir Salih

    Thanks Aydar , I set the content type and it worked for me…

    header(‘Content-Type: text/plain; charset=utf-8′);

  • Aydar Akhmetov

    You are welcome :)

  • Aydar Akhmetov

    Do you use it: header(‘X-Content-Type-Options: nosniff’)?

  • Shamir Salih

    No – I havent it.

  • Njål

    Here’s a static method (no input/output) that detects IE and sets ContentType directly!

    public static void SetProperJsonContentType()
    var ua = HttpContext.Current.Request.UserAgent;
    HttpContext.Current.Response.ContentType = (!String.IsNullOrEmpty(ua) && ua.ToLower().Contains(“msie”)) ? “text/html” : “application/json”;

  • Rodrigo

    Hi, Great Post!

    I’m facing the same issue, but I’m not calling the url from a .jsp or .aspx page, I’m calling direclty from Browser URL. Do you know how can I change this on the browser configuration? I really need to call a JSON URL to use via IE, via Chrome is working properly. Thanks

  • Kerem

    You saved my day,

  • Pingback: Kerem YILMAZ » IE doesn’t like “application/json” content type.()

  • El Servas

    I can’t thank you enough for this!!