XML mimetypes not handled correctly by IE

[guest]

When I get a response with mime type application/atom+xml. The response will not be deal with xml but with string. So we can not parse it as XML.

I tested that it works well in FF but failed on IE.

[jburke]

Did you pass in handleAs: "xml" to the dojo.xhr method call? If so, then I can see where IE does not know how to properly deal with that mime type. It would be good to know if a plain XMLHttpRequest call to the server gives you anything back in the responseXML property.

[jburke]

Having a test case would help (at least a test case of the JavaScript? code being used.

[jburke]

Having a test case would help (at least a test case of the JavaScript? code being used. And maybe a sample server response document.

[guest]

Thanks for the comments.

1 The response code is just a simple XML format.It should reproduce with any XML format response. 2. Yes, I pass in handleAs: "xml" 3. After some further investigation and discussion with some guys. I believe it is a limitation/bug in Internet Explorer itself. In the case of sending the file as application/xml and application/atom+xml, the browser provides the data of each in xhr.responseXML and Dojo does no further processing itself on it. Once the data object has been passed back in the callback, when the content-type is application/atom+xml, Internet Explorer does not provide the childNodes. The childNodes property is empty (so is data.lastChild, since there are no children). It seems like Internet Explorer simply doesn't parse the XML correctly given this content-type.

It seems Dojo isn't doing the processing of the XML, it's in the Internet Explorer XHR object that is handling it.

[jburke]

There is a dojox module that might help you manually convert the response in internet explorer:

dojo.require("dojox.data.dom");
var xmlDom = dojox.data.dom.createDocument(response.responseText, "text/xml");

Closing this as a wontfix, since it is an IE issue, and there is a workaround using dojox.data.dom. We do not want to include dojox.data.dom in the base dojo.js because of size concerns, given that this is an edge case.

[benschell]

Jared J and I looked at this bug a few months ago and had a bit of correspondence with Alex about it. This problem is a little bit more generic than the original summary and description alluded to. In fact, in IE, if you perform an XHR request with handleAs set to XML and the server sends back any XML-based mimetype that IE does not understand, this fails.

With some deliberation, Jared and I created the attached patch. This patch is actually more generic than the existing code. Rather than checking that the request was performed using file:/// as is done currently, the response is inspected to ensure the documentElement value is set. If not, the request needs to be re-parsed using the XML handlers available to IE. This patch fixes the described behavior, addresses a current solution, and decreases the size of core by a few characters.

I figure this issue is relatively important, as it may occur to any user who wants to use a specification such as Atom, which prescribes sending a feed using a mimetype of application/atom+xml.

[benschell]

By important, above, I mean worthy of not requiring one to resort to dojox.* code, but instead have this handled in core (as is already done for file:/// instances).

[jaredj]

Alex is okay with this fix. So, will integrate and test it.

[jaredj]

Unit test needed fixing too that passed a fake XML object. Had to set documentElement on it to make IE pass on the generic fix for the unknown XML mime-type issue and file:// issue.

[jaredj]

(In [13576]) Fix for unknown xml mime-type issue with IE. Generic fix also fixes the file:// issue with xml files, but required minor UT change to not fail. Test in question is a bit hokey to begin with, passing a fake xml DOM to the handler seems a bit .. odd (and doesn't really test much). fixes #5388