IXMLHttpRequest.responseXml is empty, with no parse error, when responseText contains valid Xml

Question

i am fetching some XML from a government web-site:

http://www.bankofcanada.ca/stats/assets/rates_rss/noon/en_all.xml

i am using the following, fairly simple code:

var
   szUrl: string;
   http: IXMLHTTPRequest;
begin
   szUrl := 'http://www.bankofcanada.ca/stats/assets/rates_rss/noon/en_all.xml';

   http := CoXMLHTTP60.Create;
   http.open('GET', szUrl, False, '', '');
   http.send(EmptyParam);

   Assert(http.Status = 200);

   Memo1.Lines.Add('HTTP/1.1 '+IntToStr(http.status)+' '+http.statusText);
   Memo1.Lines.Add(http.getAllResponseHeaders);
   Memo1.Lines.Add(http.responseText);

i won't show all the body that returns, but it does return valid xml in the responseText:

HTTP/1.1 200 OK
Cache-Control: max-age=5
Connection: keep-alive
Connection: Transfer-Encoding
Date: Fri, 30 Mar 2012 14:50:50 GMT
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Expires: Fri, 30 Mar 2012 14:50:55 GMT
Server: Apache/2.2.16 (Unix) PHP/5.3.3 mod_ssl/2.2.16 OpenSSL/1.0.0d mod_perl/2.0.4 Perl/v5.12.0
X-Powered-By: PHP/5.3.3


<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns="http://purl.org/rss/1.0/"
    xmlns:cb="http://www.cbwiki.net/wiki/index.php/Specification_1.1"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.w3c.org/1999/02/22-rdf-syntax-ns#rdf.xsd">
    <channel rdf:about="http://www.bankofcanada.ca/stats/assets/rates_rss/noon/en_ALL.xml">
        <title xml:lang="en">Bank of Canada: Noon Foreign Exchange Rates</title>
        <link>http://www.bankofcanada.ca/rates/exchange/noon-rates-5-day/</link>

Okay, fine, there's valid xml in there. i know it's valid because...well just look at it. But i also know it's valid by parsing it:

var
   ...
   szXml: WideString;
   doc: DOMDocument60;
begin
   ...
   szXml := http.responseText;
  
   doc.loadXML(szXml);
   Assert(doc.parseError.errorCode = 0);

   Memo1.Lines.Add('============parsed xml');
   Memo1.Lines.Add(doc.xml);

The origianal IXmlHttpRequest contains a responseXml property. From MSDN:

Represents the parsed response entity body.

If the response entity body is not valid XML, this property returns DOMDocument that was parsed so that you can access the error. This property does not return IXMLDOMParseError itself, but it is accessible from DOMDocument.

In my case the responseXml property exists, as it should:

Assert(http.responseXml <> nil);

And there is no parse error of responseText:

doc := http.responseXml as DOMDocument60;
Assert(doc.parseError.errorCode = 0);

as there should be, since the xml is valid.

Except that when i look at the http.responseXml document object, it's empty:

   Memo1.Lines.Add('============responseXml');
   Memo1.Lines.Add(doc.xml);

Is is IXMLHttpRequest (and IXMLServerHttpRequest) returning an empty XML document, when:

• there is xml
• the xml is valid
• there is no parse error

In long form:

uses
    msxml2_tlb;

procedure TForm1.Button1Click(Sender: TObject);
var
    szUrl: string;
    http: IXMLHTTPRequest;
    doc: DOMDocument60;
begin
    szUrl := 'http://www.bankofcanada.ca/stats/assets/rates_rss/noon/en_all.xml';

    http := CoXMLHTTP60.Create; //or CoServerXmlHttpRequest.Create
    http.open('GET', szUrl, False, '', '');
    http.send(EmptyParam);

    Assert(http.Status = 200);

    doc := http.responseXml as DOMDocument60;
    Assert(doc.parseError.errorCode = 0);

    ShowMessage('"'+doc.xml+'"');
end;

How do i make XmlHttpRequest (and more importantly ServerXMLHTTP60) behave as documented?

Stutman

Delphi version information is key in all questions involving the RTL and standard libraries. What version? – Barsac

i'm not using any components from Delphi, but Delphi 5. – Stutman

Related: #8926298 - note the Keepalive comment. Tried that? Also, what IE version and MS XML version, since those matter in these cases, too. I believe MS XML's HTTP methods use WinInet, which has some fun bugs, and it gets updated when you update IE. – Barsac

@WarrenP i tried the timeout; it doesn't change the result (nor should it, since i'm getting a valid response). ie9, msxml 6.0. Do you get the same behavior if you copy-paste the final simplified 8-line version? – Stutman

It's something to do with your use of DOMDocument60 instead of http.responseText, I think. – Barsac

@WarrenP i think you missed something; i want to use the document (rather than responseText) – Stutman

Answer 1

Ii found the problem

i used Fiddler to save the http response to a text file. After that i could modify the response file, and instruct fiddler to serve my hand-crafted alternatives, rather than going to the original web-site.

After 3 hours of fiddling, i managed to track down the problem in the original http response headers:

HTTP/1.1 200 OK
Cache-Control: max-age=5
Connection: keep-alive
Connection: Transfer-Encoding
Date: Fri, 30 Mar 2012 14:50:50 GMT
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Expires: Fri, 30 Mar 2012 14:50:55 GMT
Server: Apache/2.2.16 (Unix) PHP/5.3.3 mod_ssl/2.2.16 OpenSSL/1.0.0d mod_perl/2.0.4 Perl/v5.12.0
X-Powered-By: PHP/5.3.3

should be:

HTTP/1.1 200 OK
Cache-Control: max-age=5
Connection: keep-alive
Connection: Transfer-Encoding
Date: Fri, 30 Mar 2012 14:50:50 GMT
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
Expires: Fri, 30 Mar 2012 14:50:55 GMT
Server: Apache/2.2.16 (Unix) PHP/5.3.3 mod_ssl/2.2.16 OpenSSL/1.0.0d mod_perl/2.0.4 Perl/v5.12.0
X-Powered-By: PHP/5.3.3

Once i found the problem, i was able to back-find the documentation that explain the behavior:

The supported MIME types for MSXML 6.0 are:

• "text/xml"
• "application/xml"
• or anything that ends with "+xml", for example "application/rss+xml"

The RSS feed i'm fetching is actually a Resource Definition Format (RDF) feed, where the content type is supposed to be:

application/rdf+xml

Their use of:

text/html

is wrong on so many levels.

So the behavior i'm experiencing is by design; although frustrating - as there's no easy way to know if the responseXml is "valid".

• the responseXml object will be assigned
• the parseError object will be assigned
• the parseError.ErrorCode is zero
• the responseXml.documentElement will be nil

Stutman

My guess would be that since text/html is not supported, the underlying XML parser is not even parsing any data, which would leave the errorCode set to zero but not create an documentElement object. If the responseText is not empty but the documentElement is, you know something went wrong, and you can test for that. – Immeasurable

Many of the Noon feeds on that site are sending the Content-Type as text/html, but some of them, like "en_USD.xml" and "en_MXN.xml", send application/xml instead. – Immeasurable

So what to do? Hack their XML via some string hackage? – Barsac

@WarrenP i'm falling back to if http.responseXml.documentElement = nil then result := GetXmlObjectFromXmlString(http.responseText) else result := http.responseXml; It's not a thoroughly generic solution, as sometimes there can be an xml document with no documentElement. But in this case it's good enough, because if the xml really is empty then they've done something stupid. – Stutman

Answer 2

I had the same problem with YouTube services.

The responseXml object is dependent on the content-type/MIME of the response.
You could examine the response Content-Type e.g: if http.getResponseHeader('Content-Type') contains text/xml or application/xml only then you can refer to http.responseXml, otherwise it will be empty (see MSDN Remarks). Also note that the responseXml parser validation features are always turned off, for security reasons.

But, the http.responseText will always have the xml text, no matter what content type is in the response, so you can always use a new instance of DOMDocument to load the xml e.g:

...
http := CoXMLHTTP60.Create; // or CoServerXmlHttpRequest.Create 
http.open('GET', szUrl, False, '', '');
http.send(EmptyParam);
Assert(http.Status = 200);

doc := CreateOleObject('Msxml2.DOMDocument.6.0') as DOMDocument60; 
doc.async := False;
doc.loadXML(http.responseText); // <- load XmlHttpRequest.responseText into DOMDocument60 and use it
Assert(doc.parseError.errorCode = 0);

// do useful things with doc object...

Coventry

i don't use the DOMDocument object (and strictly speaking i don't use the XmlHttpRequest object) because the enterprise of mutton-heads thinks it's a good idea to block people's access to the internet (i.e. i have to configure a proxy - which can only be done using IServerXmlHttpRequest). Also, you can't just check for text/xml, need to also check for application/xml, or anything/anything+xml (frought with edge cases i don't even want to care about). – Stutman

Read my answer carefully. I'm saying that you will have a valid responseXml.documentElement object only if the response is explicitly set to text/xml. I'm saying DON'T rely on responseXml and always use responseText and DOMDocument like in the first code example. IServerXmlHttpRequest behaves the same XmlHttpRequest when the response content-type is not text/xml. – Coventry

i'd prefer to let the XmlHttpRequest handle the parsing of the response xml text; otherwise the xml has to go through another encode cycle (encoding as UTF-16 BSTR, then parsed again). It's possible that the documentElement is nil even when the content type is text/xml - so that's a gotcha. – Stutman

I'd also prefer that. But this is by design. :/ – Coventry

Answer 3

Well, this works in Delphi XE and Delphi 7:

procedure TForm1.Button1Click(Sender: TObject);
var
    szUrl: string;
    http: IXMLHTTPRequest;
    doc: {$ifndef UNICODE}WideString{$else}string{$endif};
begin
    szUrl := 'http://www.bankofcanada.ca/stats/assets/rates_rss/noon/en_all.xml';

    http := CoXMLHTTP60.Create; //or CoServerXmlHttpRequest.Create
    http.open('GET', szUrl, False, '', '');
    http.setRequestHeader('Content-Type', 'text/xml;charset=UTF-8');
    http.send(EmptyParam);

    Assert(http.Status = 200);

    doc := UTF8Encode(http.responseText);

    Memo1.Lines.text := doc;
//  ShowMessage('"'+doc.xml+'"');
end;

Hope it works for you in Delphi 5, too. Of course, any unicode characters are going to turn into ? on you, in non-unicode delphi versions.

Barsac

respoonseText works, it's responseXml that is empty (though there's no parse error) – Stutman

Answer 4

You are retreiving the xml from the DOMDocument object itself, but you should be grabbing it from the first node in the document's tree instead, eg:

doc := http.responseXml as DOMDocument60; 
Assert(doc.parseError.errorCode = 0); 
ShowMessage('"' + doc.DocumentElement.childNodes.Item(0).xml + '"'); 

Microsoft's own examples in the documentation for DOMDocument and the xml property show exactly that kind of logic.

Immeasurable

In this case the documentElement is nil. – Stutman

Well, then that explains why the xml is empty - there is nothing in the DOMDocument. – Immeasurable

At the very least it is deceiving: there is nothing in the DOMDocument yet it's valid XML. – Stutman