- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 04 Jan 2010 17:00:25 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "WebApps WG" <public-webapps@w3.org>
On Mon, 07 Dec 2009 16:42:31 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > I think XHR needs to elaborate on how non-ASCII characters in request > headers are put on the wire, and how non-ASCII characters in response > headers are transformed back to Javascript characters. Hmm yeah. I somehow assumed this was easy because everything was restricted to the ASCII range. It appears octets higher than 7E can occur as well per HTTP. > For request headers, I would assume that the character encoding is > ISO-8859-1, and if a character can't be encoded using ISO-8859-1, some > kind of error handling occurs (ignore the character/ignore the > header/throw?). From my limited testing it seems Firefox, Chrome, and Internet Explorer use UTF-8 octets. E.g. "\xFF" in ECMAScript gets transmitted as C3 BF (in octets). Opera sends "\xFF" as FF. > For response headers, I'd expect that the octet sequence is decoded > using ISO-8859-1; so no specific error handling would be needed > (although the result may be funny when the intended encoding was Firefox, Opera, and Internet Explorer indeed do this. Chrome decodes as UTF-8 as far as I can tell. I'd love some implementor feedback on the manner. -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 4 January 2010 16:01:06 UTC