W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: character encoding in header fields, was: SPDY Header Frames

From: James M Snell <jasnell@gmail.com>
Date: Tue, 17 Jul 2012 08:05:27 -0700
Message-ID: <CABP7RbfSMfNJBOkqRzsqdCOJ9Yi=9ZvjEOyW7efz0OwZOzgSzw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On Tue, Jul 17, 2012 at 7:59 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2012-07-17 16:48, James M Snell wrote:
>> Tunneling 1.1 traffic via 2.0 would likely be the easy part; it's the
> Not even that. Given an HTTP/1.1 message containing non-ASCII octets in
> header field value, you simply don't know what unicode characters to map
> them to.
> This is not theoretical; some UAs process UTF-8 in Content-Disposition,
> some use the installation's locale character set.
> Yes, this is a mess, but it's not clear to me how to break out of it
> without breaking *some* setups that currently "work".
+1 ... there are quite a few issues that I would like to see HTTP/2.0
resolve that fall into the same issue. Some breakage will occur and I'm
good with that.

>  ...
>> The one thing we need to determine is: how critical is the ability to
>> support seamless down-level conversion from 2.0 to 1.1 within a request?
>> Is it acceptable for us to say that while 2.0 can be used to transport
>> 1.1 messages, the reverse is not possible.
>> ...
> So how do you transport a 1.1 message inside 2.0 if it contains non-ASCII?
> Treat the header field value as binary?
That's my initial thought but still noodling over it. I'm open to
suggestions but really want to keep the header encoding as compact as

- James

> Best regards, Julian
Received on Tuesday, 17 July 2012 15:06:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 15:06:26 GMT