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

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
possible.

- James


> Best regards, Julian
>