Re: Dealing with Invalid UTF-8

We have not agreed that the compressor should have to interpret
Utf-8, but we have not agreed that it shouldn't.

I think it should be doing byte-based  comparisons for values right now,
with the rest (e.g. other encodings) to be decided after the bare-bones is
working and interoperating.

-=R

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