Re: Dealing with Invalid UTF-8

The solution I'd prefer is to go with the typed codecs I've proposed, which
can be separated out from the main header compression algorithm and have a
clearly defined backwards compatibility story.
On Sep 2, 2013 7:40 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> Hi,
>
> I note that compression spec still pretends that field values are encoded
> in UTF-8.
>
> Have we agreed on this? If so, how do you forward existing header fields
> that may not be UTF-8???
>
> Best regards, Julian
>
>
> On 2013-08-16 18:31, Roberto Peon wrote:
>
>> Yup.
>>
>>
>> On Fri, Aug 16, 2013 at 2:30 AM, Julian Reschke <julian.reschke@gmx.de
>> <mailto:julian.reschke@gmx.de>**> wrote:
>>
>>     On 2013-08-14 00:12, James M Snell wrote:
>>
>>         https://github.com/http2/__**http2-spec/issues/232<https://github.com/http2/__http2-spec/issues/232>
>>         <https://github.com/http2/**http2-spec/issues/232<https://github.com/http2/http2-spec/issues/232>
>> >
>>
>>         The current header compression draft states that header field
>> values
>>         are UTF-8. However, the spec says nothing about how to deal with
>>         overlong encodings, invalid UTF-8 octet sequences or valid UTF-8
>>         sequences that encode invalid Unicode codepoints.
>>
>>         I recommend stating that any of these conditions ought to result
>>         in an
>>         error. An encoder MUST NOT output any of these; and a decoder
>>         ought to
>>         signal a connection error if encountered.
>>
>>
>>     ...whether this is an issue or not depends on what we decide we
>>     respect to whether field values are octet sequences or strings...
>>
>>     Best regards, Julian
>>
>>
>>
>>
>