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

Re: [XMLHttpRequest] responseText decoding

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 01 Apr 2007 13:34:14 +0200
To: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tp3rrcky64w2qv@id-c0020>

On Sun, 01 Apr 2007 03:53:16 +0200, Asbjørn Ulsberg <asbjorn@ulsberg.no>  
> On Wed, 21 Mar 2007 12:29:09 +0100, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> 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.

This issue is not about the imo bogus part of RFC3023 that says that  
text/xml without a charset parameter must be treated as if US-ASCII was  
specified. I'll just assume that in due course we'll have a more sensible  
specification that says to treat text/xml identically to application/xml.  
Especially given how widely deployed text/xml is versus application/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.

This is not the problem though. I'm not sure which part of my original  
e-mail led you to think it is.

> 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.

Anne van Kesteren
Received on Sunday, 1 April 2007 11:34:24 UTC

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