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…

image

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: ,

Comments

26 Comments
Zlatko Says:

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

Andreas Says:

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 Says:

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 Says:

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

Andreas Says:

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:

https://github.com/Studio-42/elFinder/issues/263

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: https://github.com/Studio-42/elFinder/commit/60ce68418b

Andreas Says:

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 Says:

REQUEST
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
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

Zlatko Says:

Sorry! Wrong data!!!

Andreas Says:

Does that mean you found and solved the problem?

Zlatko Says:

Not yet:(

Aydar Akhmetov Says:

Hi!
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 Says:

Thanks! I will try tomorrow!:)

Aydar Akhmetov Says:

Helped? :)

Andreas Says:

Zlatko: did Aydars solution work?

jkella Says:

HI Andreas,

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

Andreas Says:

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 Says:

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

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

Aydar Akhmetov Says:

You are welcome :)

Aydar Akhmetov Says:

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

Shamir Salih Says:

No – I havent it.

Njål Says:

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 Says:

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 Says:

You saved my day,
thanks.

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

  • El Servas Says:

    I can’t thank you enough for this!!