Re: HTTP/2 Header Encoding Status Update

On 2013-02-28 09:22, Mark Nottingham wrote:
>
> On 28/02/2013, at 6:27 PM, Julian Reschke <julian.reschke@gmx.de> 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]
>>>> So, the biggest concern here, I think, is that the conversion of a UTF-8 value to ASCII/Latin-1 -- to be able to forward the header on a HTTP/1.x hop -- requires knowledge of the header.
>>>>
>>>> Would you want to define a standard way to encode UTF-8 in Latin-1 (e.g., percent-encoding) for headers that use this? It would constrain the headers (and likely rule out any existing headers from using UTF-8), but I don't see how this is going to be viable otherwise.
>>>>
>>>
>>> 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.
>
> I think what's being suggested is that *new* headers can opt-in to a format whereby the entire value is percent-encoded where needed when expressed in Latin-1, but not when it's in UTF-8. Existing headers wouldn't be able to do so (unless they already fit this convention).
> ...

But for *new* headers we could simply pick UTF-8, no? (even on 1.1)

Best regards, Julian

Received on Thursday, 28 February 2013 09:13:58 UTC