W3C home > Mailing lists > Public > public-webapi@w3.org > June 2007

Re: XMLHttpRequest.responseXML returning null for non-XML MIME types

From: Anne van Kesteren <annevk@opera.com>
Date: Sat, 30 Jun 2007 14:39:30 +0200
To: "Geoffrey Garen" <ggaren@apple.com>, public-webapi@w3.org
Message-ID: <op.tuqir41q64w2qv@annevk-t60.oslo.opera.com>

On Fri, 29 Jun 2007 22:34:46 +0200, Geoffrey Garen <ggaren@apple.com>  
wrote:
> The XMLHttpRequest spec says that, if an HTTP response contains a  
> content-type header that is not XML, XMLHttpRequest .responseXML should  
> return NULL  
> (http://www.w3.org/TR/XMLHttpRequest/#xml-response-entity-body).
>
> I'm looking into this issue because it has broken a widget on Mac OS X.  
> The widget uses XMLHttpRequest to load a valid XML file and then read  
> responseXML. Unfortunately, the file comes to use with an incorrect MIME  
> type (application/octet-stream), so we return NULL and later throw an  
> exception.
>
> To me, it seems preferable to try to parse the response as XML,  
> returning NULL only if parsing fails. The spec already says you should  
> do this if the content-type header is missing. Why not do it always?

To allow extensions in the future. For instance, we might want to populate  
responseXML with HTML if the MIME type is text/html. However, I understand  
this is about file requests, which are not addressed by the specification.  
I suppose I should try to cover them in version 2.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Saturday, 30 June 2007 12:39:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT