XmlHTTPRequest and responseXML in IE

[Chris Smith]

Been banging my head against this one for some time. I'm attempting to
use XmlHTTPRequest to read an XML document from the web server and
interact with it using the DOM. So far, I've had less than perfect luck
with IE. What I've established:

- In IE, the responseXML property sometimes returns an empty document.
- It always does so when testing on local files.
- It (sometimes? always?) works fine when pages are served by a web
server.

I saw one comment on the web explaining that it only parses the response
into a DOM in responseXML if the HTTP response's content type is
text/xml. That would kinda make sense, I guess, if I assumed that local
requests simply don't have a content type and so aren't parsed.

Anything else to watch out for? Is there a workaround to force IE to
always parse the response text, even if it doesn't happen to guess that
the format is XML?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Steve van Dongen]

Been banging my head against this one for some time. I'm attempting to
use XmlHTTPRequest to read an XML document from the web server and
interact with it using the DOM. So far, I've had less than perfect luck
with IE. What I've established:

- In IE, the responseXML property sometimes returns an empty document.
- It always does so when testing on local files.
- It (sometimes? always?) works fine when pages are served by a web
server.

Maybe you're issuing async requests (good) but not waiting until the
data is ready (bad).

I saw one comment on the web explaining that it only parses the response
into a DOM in responseXML if the HTTP response's content type is
text/xml. That would kinda make sense, I guess, if I assumed that local
requests simply don't have a content type and so aren't parsed.

Anything else to watch out for? Is there a workaround to force IE to
always parse the response text, even if it doesn't happen to guess that
the format is XML?

It's not a matter of "guessing" the format because the content-type
indentifies what the server is sending back. If you know better than
the server, then use responseText instead of responseXml and do
whatever you want with the data. You can also just forget about
XMLHTTP completely and use a DOMDocument object's load(<url>) method.

Regards,
Steve

 

[Chris Smith]

Maybe you're issuing async requests (good) but not waiting until the
data is ready (bad).

Nah, using synchronous requests.

It's not a matter of "guessing" the format because the content-type
indentifies what the server is sending back. If you know better than
the server, then use responseText instead of responseXml and do
whatever you want with the data. You can also just forget about
XMLHTTP completely and use a DOMDocument object's load(<url>) method.

Well, the server will always report text/xml as far as I know, but IE
seems to not work with local files, which makes it a bit difficult to do
exploratory testing. Aside from that, I've just seen this thing start
and stop working enough that I'm nervous about trusting it to work in
production. I *think* I can trace times when it hasn't worked to errors
in the returned XML content, but since I've seen empty DOM documents
when the XML is fine in some scenarios (at least with local files), I'm
being skeptical.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Stephen]

Maybe you're issuing async requests (good) but not waiting until the
data is ready (bad).

[...snip...: Noting that the OP responded he uses sync ... ]

Could you please give an explanation of why one should prefer async over
sync?

Thanks
Stephen

 

[Steve van Dongen]

Maybe you're issuing async requests (good) but not waiting until the
data is ready (bad).

[...snip...: Noting that the OP responded he uses sync ... ]

Could you please give an explanation of why one should prefer async over
sync?

I should clarify that my comments are intended to be taken in the
context of client-side script running in a web page. I don't believe
there are any problems with using sync requests if you are writing
script running in ASP or WSH.

I remember reading a comment by a Microsoft program manager that he
regretted that they had ever published sample code that demonstrated
sync requests. Unfortunately he never explained the reasons behind
the comment, but this is why I say to always use async...

The big thing with sending sync requests is that your page is
basically frozen from the time that the request is sent until a
response is received. When using async, the request is sent and your
callback function is called when the server responds so that you can
process the response. In the meantime, any script you have will
continue executing, the browser is free to do whatever processing it
needs to do, and your script can respond to events.

A more obscure problem is that using sync requests can potentially
lead to deadlocks though I admit that I have no idea how likely it is.
Our group was developing an application where we kept hitting
deadlocks and it was traced to the fact that the application was using
a combination of sync and async requests. I don't know the exact
details but the problem wouldn't have happened if we had used all sync
requests or all async; it was just the combination of the two types
that caused the deadlock. The browser always makes async requests;
therefore your script should make async requests as well.

Also, you have the ability to cancel an async request. OTOH with a
sync request you have no choice but to wait for it to complete (and
hope the server isn't in a bad state which causes it to never
respond).

Regards,
Steve

 

[Stephen]

Been banging my head against this one for some time. I'm attempting to
use XmlHTTPRequest to read an XML document from the web server and
interact with it using the DOM. So far, I've had less than perfect luck
with IE. What I've established:

- In IE, the responseXML property sometimes returns an empty document.
- It always does so when testing on local files.
- It (sometimes? always?) works fine when pages are served by a web
server.


Maybe you're issuing async requests (good) but not waiting until the
data is ready (bad).

[...snip...: Noting that the OP responded he uses sync ... ]

Could you please give an explanation of why one should prefer async over
sync?

I should clarify that my comments are intended to be taken in the
context of client-side script running in a web page. I don't believe
there are any problems with using sync requests if you are writing
script running in ASP or WSH.

... comment by a Microsoft program manager that he
regretted ...

.. your page is basically frozen ...

.. sync requests can potentially lead to deadlocks ...

The browser always makes async requests..

yes, I believe this is the nature of HTTP

...Also, you have the ability to cancel an async request...

That seems to cover a lot of bases; thanks for the thorough response...

Stephen

 

[Chris Smith]

The big thing with sending sync requests is that your page is
basically frozen from the time that the request is sent until a
response is received. When using async, the request is sent and your
callback function is called when the server responds so that you can
process the response. In the meantime, any script you have will
continue executing, the browser is free to do whatever processing it
needs to do, and your script can respond to events.

Are you saying that the browser is essentially single-threaded, and if I
take a long time to return from a JavaScript function, the browser can't
do anything else in that time frame? That would be a reason to use
async requests, I suppose, but I'm appalled that it is the case.

I'm not concerned about the display of the page (which is really all
auto-generated by DHTML based on the contents of the XML file I'm
loading, anyway). However, if the browser wouldn't be able to show a
menu, or close itself, or other basic functions, that would certainly be
a pain.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Think a little about it and all will sit perfectly. As the name implies,
XMLHTTPRequest calls a document using the HTTP protocol. When you test on
local files, you don't use the HTTP; when testing via a web server, you do.

IOW, always test with a server. It simulates the final conditions more
accurately.

Well, that would make sense if the documentation didn't explicitly say
that this class can actually issue requests over other protocols as
well. In any case, it's not the local file issue itself that concerns
me; it's the fact that there's behavior that seems to be contrary to the
documentation, and I don't feel comfortable relying on correct behavior.
I thought I'd ask here to see if anyone had a nice explanation, or
enough experience to say with confidence that this works reliably.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jim Ley]

Are you saying that the browser is essentially single-threaded, and if I
take a long time to return from a JavaScript function, the browser can't
do anything else in that time frame?

javascript is single threaded, and it will lock the window to input
and updates while it's processing.

Which is why you don't use sync, or sleep in any event driven
environment.

Jim.

 

[Chris Smith]

javascript is single threaded, and it will lock the window to input
and updates while it's processing.

Which is why you don't use sync, or sleep in any event driven
environment.

Okay, point taken. This resolves my concurrency concerns, I guess, in
another thread. I assume this is true between frames, not just within a
frame? If so, then I'll definitely go switch to async requests.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation