W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: XHR LC comment: header encoding

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>
Message-ID: <op.u50mqzmf64w2qv@annevk-t60>
On Mon, 07 Dec 2009 16:42:31 +0100, Julian Reschke <julian.reschke@gmx.de>  
> 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
Received on Monday, 4 January 2010 16:01:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:04 UTC