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

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

From: Alexey Proskuryakov <ap-carbon@rambler.ru>
Date: Mon, 02 Jul 2007 12:22:56 +0400
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Geoffrey Garen <ggaren@apple.com>
CC: <public-webapi@w3.org>
Message-ID: <C2AE9EA0.399F0%ap-carbon@rambler.ru>

On 6/30/07 2:04 AM, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

> Geoffrey Garen wrote:
>> Just to be clear, the widget loads a local file.
> Then how does the file end up with a MIME type, exactly?

  The underlying network layer provides us with one (which is good, because
it lets us treat .html files as text/html, but some widget authors use XML
files with extensions that are not recognized as XML).

> Note that the way Gecko does this is to flag network loads done from
> XMLHttpRequest as having a MIME type hint of application/xml; this type is
> used 
> if the underlying network protocol doesn't provide MIME type information
> (which 
> covers file:// loads in particular).

  Until very recently, we did the same, but it meant that loading local HTML
files didn't respect encoding from META, while loading HTML files via HTTP

  If responseXML is reused for HTML in the future, as Anne mentioned, we
will need to special-case text/html in responseXML anyway, so this doesn't
seem to conflict with always parsing local files as XML for now. Here, I'm
assuming that widget authors are unlikely to load XML from .html files.

- WBR, Alexey Proskuryakov
Received on Monday, 2 July 2007 08:23:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC