Opened 13 years ago
Closed 13 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: | [email protected]…, [email protected]… |
Blocked By: | Blocking: |
Description (last modified by )
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)
Change History (13)
comment:1 Changed 13 years ago by
Milestone: | 1.0.2 → 1.1 |
---|---|
Priority: | high → normal |
severity: | blocker → normal |
comment:2 Changed 13 years ago by
Having a test case would help (at least a test case of the JavaScript? code being used.
comment:3 Changed 13 years ago by
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 13 years ago by
Thanks for the comments.
1 The response code is just a simple XML format.It should reproduce with any XML format response.
- Yes, I pass in handleAs: "xml"
- 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 13 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 13 years ago by
Description: | modified (diff) |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
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 13 years ago by
Attachment: | 5388.patch added |
---|
comment:7 Changed 13 years ago by
Summary: | application/atom+xml can not be specified in bindArg → XML 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 13 years ago by
Cc: | [email protected]… added |
---|
comment:9 Changed 13 years ago by
Milestone: | 1.1 → 1.2 |
---|
Changed 13 years ago by
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 13 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(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
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.