Opened 12 years ago

Closed 12 years ago

#5388 closed defect (fixed)

XML mimetypes not handled correctly by IE

Reported by: guest Owned by: anonymous
Priority: high Milestone: 1.2
Component: Core Version: 1.0
Keywords: Mime Type application/atom+xml Cc: hehuij@…, jared.jurkiewicz@…
Blocked By: Blocking:

Description (last modified by benschell)

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.

Attachments (2)

5388.patch (538 bytes) - added by benschell 12 years ago.
5388-2.patch (963 bytes) - added by Jared Jurkiewicz 12 years ago.
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.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 12 years ago by James Burke

Milestone: 1.0.21.1
Priority: highnormal
severity: blockernormal

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.

comment:2 Changed 12 years ago by James Burke

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

comment:3 Changed 12 years ago by James Burke

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

comment:4 Changed 12 years ago by guest

Thanks for the comments.

1 The response code is just a simple XML format.It should reproduce with any XML format response.

  1. Yes, I pass in handleAs: "xml"
  2. 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.

comment:5 Changed 12 years ago by James Burke

Resolution: wontfix
Status: newclosed

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.

comment:6 Changed 12 years ago by benschell

Description: modified (diff)
Resolution: wontfix
Status: closedreopened

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.

Changed 12 years ago by benschell

Attachment: 5388.patch added

comment:7 Changed 12 years ago by benschell

Summary: application/atom+xml can not be specified in bindArgXML mimetypes not handled correctly by IE

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).

comment:8 Changed 12 years ago by benschell

Cc: jared.jurkiewicz@… added

comment:9 Changed 12 years ago by James Burke

Milestone: 1.11.2

comment:10 Changed 12 years ago by Jared Jurkiewicz

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

Changed 12 years ago by Jared Jurkiewicz

Attachment: 5388-2.patch added

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.

comment:11 Changed 12 years ago by Jared Jurkiewicz

Resolution: fixed
Status: reopenedclosed

(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

Note: See TracTickets for help on using tickets.