IE11 not honoring responseType: 'json'

[evonsdesigns]

I am trying to execute a simple xhr.get call and use the json object in response.body. This works fine in Chrome and Firefox, but in IE11; it does not convert the response.body into an object, but leaves it as a String. Here it only converts the response.body if isJson is set in the options ahead of time. I have no need for that property besides to hack it to work for IE11. Shouldn't isJson be set to true if the responseType is 'json' or the json property exists?

Returns a string in response.body in IE11

xhr.get({
  url: myUrl?parameters,
  responseType: 'json'
}, callback);

My hack to convert response.body to an Object in IE11

xhr.get({
  url: myUrl?parameters,
  responseType: 'json',
  json: true
}, callback);

It looks like Microsoft is aware of it, but no fix coming for IE11.

[TehShrike]

Related to #114

[TehShrike]

It has seemed pretty odd to me that you have to specify json: true even when the server is putting Content-Type:application/json headers on the response.

[evonsdesigns]

Without the json: true property, when my requests hit getBody(), xhr.responseType is an empty string in IE11. Even with Content-Type:application/json on the response header.

[naugtur]

Now consider other browsers that xhr supports like IE8 or IE9.
that's why json field remains the only option. Also, detecting response type and auto-parsing without explicit request would break backward compatibility and forever forbid you from getting a json response as text with intention to parse later or not at all.

I don't think we could introduce a change to fix this issue. Planning to close as wontfix.

[TehShrike]

Does request/request really ignore the Content-Type header on responses from the server? I assumed this was a bug.

[TehShrike]

Personally, an XHR client ignoring the Content-Type header on the response seems like a bug to me, but if request/request doesn't do it and it's "desired functionality" then I don't imagine it's worth breaking backwards compatibility. Just a bit more impetus to improve the docs.

[AurelioDeRosa]

I confirm the library is ignoring the Content-Type. This issue is breaking the Keystone.js CMS.

The workaround of setting the json property to true does work, but I think the library should handle this.

[naugtur]

This is a bug in IE11 and the correct response would be to fix it there.

https://github.com/request/request is not sniffing content-types and the aim of xhr is to mimic their API.

All I could do without breaking compatibility with request is setting isJson to true internally if responseType==='json'
It could be a breaking change for existing users, so I can add that to v3

I'm open to opinions about that.

[AurelioDeRosa]

I think the whole point of a library is to abstract and avoid people dealing with browsers issues. A great example is what jQuery does and how it provides the same experience regardless of the browsers and their issues. So, while I appreciate that this is a IE bug, the library should avoid devs to even know about it.

[naugtur]

This library has more goals than abstracting away browser issues.
As I said, I have an idea how to introduce a fix for IE11 in v3 without sacrificing other goals - keeping semantic versioning and remaining API compatible with https://github.com/request/request

If you can help me find a way to fix it without breaking any possible applications that use xhr, I'm all ears. We could release the fix very soon, without changing major version.

Also feel free to PR a test that covers this exact case. It always helps with looking for fixes.

[stloc]

on IE don't use xhr.responseType = 'json'; and parse yourself the response var res = JSON.parse(xhr.responseText);

var xhr = new XMLHttpRequest();
    //xhr.responseType = 'json';
    var params = ...
    xhr.open("POST", "/xxx", true);
    xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
    xhr.onreadystatechange = function() {//Call a function when the state changes.
      if(xhr.readyState == 4 && xhr.status == 200) {
        var res = JSON.parse(xhr.responseText);
      }
    }
    xhr.send(params);