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

Re: [XMLHttpRequest] responseText decoding

From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
Date: Sun, 01 Apr 2007 03:53:16 +0200
To: "Anne van Kesteren" <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tp20u2j25rel5w@quark>

On Wed, 21 Mar 2007 12:29:09 +0100, Anne van Kesteren <annevk@opera.com>  

> Personally I would like to have things for XMLHttpRequest work similarly  
> to other content (not fetched through XMLHttpRequest), but it seems this  
> might be tricky to get right.

It is indeed tricky, especially considering RFC-3023 and the 'text/*'  
media types. A lot of 'text/*' content on the web breaks RFC-3023 and  
RFC-2046, and discussions on the Atom mailing list concluded (at least for  
me) that those specifications needs to be disregarded, at least for all  
XML media types.

While breaking those specifications in another specification indeed leaves  
a bitter taste, it's apparent that they weren't written with the current  
web and XML content in mind, or at least that the 'text/xml' registration  
respected and payed more attention to RFC-2045 and 2046 than to the XML  

Defaulting to anything but iso-8859-1 or UTF-8 on the web today doesn't  
make much sense, especially not US-ASCII. It made sense in the 80's, but  
doesn't any more and I strongly believe disregarding RFC-2046 in this  
regard is the right thing to do, since the compatibility of existing MIME  
parsers isn't a concern the XHR specification needs to take.

It's an interesting discussion, though, and I would love to see a global  
and final conclusion on the matter, not just applying to XHR or Atom.

Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Received on Sunday, 1 April 2007 01:50:27 UTC

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