dojo.xhrPost does not call the error handler when the response could not be parsed

[attila.lendvai]

is it a valid expectation from me that whatever happens either the 'error' or the 'load' handler of dojo.xhr should be called?

---

the situation:

• js initiates an async XHR request with handleAs: "xml"

• server sends back an xml content type response, but with empty body

• js tries to parse the empty body as xml, so an error happens

• my error handler given to dojo.xhrPost is not called (which renders the js side of my application dead)

---

if it's an invalid expectation from me, then i'm in trouble, because i need sync xhr requests in certain situations. but if i use dojo.xhr with sync: true, then the browser window pretty much hangs for the time of the request, including animations.

so, i've added my own feature to track fake-sync xhr requests (which are sync: false for dojo), but if there are situations when none of my handlers get called, then i can't properly do my own sync request tracking.

[Adam Peller]

Kris - sounds a little like our empty JSON problem? Don't know if error callbacks on Deferreds would be called for internal errors.

[James Burke]

I just did a test of this in Firefox 3.6, doing a dojo.xhrGet() with handleAs:xml, for an empty file, and it appears that an XML document is returned, but the lastChild is a node with nodeName of "parsererror".

So, the main issue is that Dojo does not get a chance to get an error -- the browser is parsing the empty document, but creating what looks like an XML document with an error node. So I do not believe we will be able to fix this since the browser does not give us insight into the document.

If you noticed a different behavior on a different browser, that would be good to know, but I would have expected the browser to throw, but apparently at least in Firefox, it tries to create some XML document shell for the case.

[attila.lendvai]

firefox bug about not throwing for xml parse errors:

​https://bugzilla.mozilla.org/show_bug.cgi?id=45566

[attila.lendvai]

firefox documentation about the behavior: ​https://developer.mozilla.org/En/DOMParser

what if dojo "fixed" this weird behavior?

[Adam Peller]

do you get any callback from the Deferred? I think this is only a critical problem if you do not get any callback at all... if you get an "error" document back as "success", at least you have the opportunity to check it, right? What do the other browsers do?

Wow, a 10-year old bug: ​https://bugzilla.mozilla.org/show_bug.cgi?id=45566 Handling Mozilla XML quirks would seem to be an option, but it's a judgement call if this belongs in core.

[attila.lendvai]

i've set up a test for this in my environment, i'll try to post it online somewhere.

meanwhile various response objects:
opera: an empty (? no firebug...) XmlDoc? object
chrome: nil
firefox: a Document object with a single parsererror node

ff is surprising me here, because in the synthetic test i assembled it behaves properly ('load' handler gets called), while in my real world error neither the 'load' nor the 'error' handler is called?!

the real-world error is due to a recent regression in the network library i'm using to emit the http responses, so probably some weird network related thing (socket improperly closed? etc...) confuses ff and/or dojo.

i guess now i should come up with a synthetic test that provokes the erratic behavior, because simply returning the HTTP headers with a zero length HTTP body works (more or less) as expected.

[James Burke]

Sounds like then it may be a server/FF interaction problem. To verify that it is not Dojo you can do just a plain XMLHttpRequest call without using Dojo, but I suspect that Dojo is not the problem.

Feel free to reopen if you do find Dojo is the problem.