W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: HTTP/2 Header Encoding Status Update

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 28 Feb 2013 09:22:20 +0100
Message-ID: <512F13BC.90500@gmx.de>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
CC: James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2013-02-28 09:11, "Martin J. Dürst" wrote:
> Hello Julian,
> On 2013/02/28 16:27, Julian Reschke wrote:
>> On 2013-02-28 00:00, James M Snell wrote:
>>> On Wed, Feb 27, 2013 at 2:45 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>> Hi James,
>>>> [snip]
>>> Yes, I think that is reasonable. One key thing is that existing
>>> headers would need to be explicitly redefined to take advantage of the
>>> new encoding options so it would be technically invalid to take any of
>>> the existing headers and encode them as UTF-8 unless their definition
>>> has been changed in spec. That said, a standard mapping like you
>>> suggest would be good in the cases we do have to drop down from http/2
>>> to /1. Percent-encoding seems to be perfectly reasonable.
>>> ...
>> That's not going to work for existing header fields and existing code on
>> HTTP/1.1.
>> This is a hairy problem. If it wasn't, we would already have solved it.
> Can you give actual examples?

Non-ASCII characters in Content-Disposition's filename parameter; 
sometimes decoded as UTF-8, sometimes as ISO-8859-1, sometimes based on 
the referring page's encoding, sometimes using the browser's default locale.

Whatever you choose here *will* break some UAs.

Best regards,

Received on Thursday, 28 February 2013 08:22:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC