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

Re: XHR LC comment: header encoding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 05 Jan 2010 12:24:08 +0100
Message-ID: <4B432158.5020006@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
Anne van Kesteren wrote:
> On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>> Wouldn't it then be better to throw for any non ASCII characters? That
>> way we don't restrict ourself for when (if?) IETF defines an encoding
>> for http headers.
> 
> The defined encoding is ISO-8859-1 (unfortunately).

Well, that's debatable, as RFC 2616 wasn't sufficiently precise.

What's a fact is that some HTTP APIs treat them as ISO-8859-1 (servlet 
API, for instance).

HTTPbis currently has:

"Historically, HTTP has allowed field content with text in the 
ISO-8859-1 [ISO-8859-1] character encoding and supported other character 
sets only through use of [RFC2047] encoding. In practice, most HTTP 
header field values use only a subset of the US-ASCII character encoding 
[USASCII]. Newly defined header fields SHOULD limit their field values 
to US-ASCII characters. Recipients SHOULD treat other (obs-text) octets 
in field content as opaque data." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-08.html#rfc.section.3.2>

>> At the very least, throwing if the upper byte is non-zero seems like
>> the right thing to do to prevent silent data loss.
> 
> That works for me.

Sounds good to me as well.

Best regards, Julian
Received on Tuesday, 5 January 2010 11:24:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT