- From: Alexey Proskuryakov <ap-carbon@rambler.ru>
- Date: Mon, 26 Feb 2007 13:29:28 +0300
- To: Bjoern Hoehrmann <derhoermi@gmx.net>, <public-webapi@w3.org>
- CC: Anne van Kesteren <annevk@opera.com>
On 2/22/07 12:26 PM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote: > You have a similar situation e.g. for text/css and text/html, where the > specifications similarily override their underlying protocols. It does > not strike me as very likely that implementers will implement the draft > so that including an external document using some markup and using XHR > will result in widely different results. In my testing, I have found that existing implementations already deduce the charset for XHR response in a way that's drastically different from normal page loading. The default is indeed UTF-8 in all cases (rather than us-ascii or the browser default). The content is only examined for encoding information if it's XML, so an encoding specified in an Http-Equiv meta or a CSS @charset is ignored. An XML declaration does have an effect if the response is XML. The above is a generalization, of course, as the behavior is not very consistent between browsers (for example, IE sometimes uses different encodings for responseText and responseXML!). Firefox behavior looks the most logical to me, and Safari/WebKit nightly builds implement it now. I have some ad hoc tests at <http://nypop.com/~ap/webkit/xmlhttprequestenc/001.html> and <http://nypop.com/~ap/webkit/xmlhttprequestenc/xmlhttprequestenc.html>. - WBR, Alexey Proskuryakov
Received on Monday, 26 February 2007 10:29:49 UTC