Re: Is more than 7bits EOS padding or full EOS sequence in huffman byte string subject to compression error?

Thank you all for clarifying the topic.
So at least the current spec treats more than 7 bits padding as a
compression error.
I will add strict check for this padding in our implementation, let's see
what happen in upcoming interop season.

Best regards,
Tatsuhiro Tsujikawa

On Wed, Dec 18, 2013 at 1:53 AM, Roberto Peon <grmocg@gmail.com> wrote:

> As specced it would be an error to encode more than 7 bits of the eos
> symbol. That being said, the eos symbol is currently encoded in at minimum
> 24 bits, so one would have to accidentally encode at least three octets
> (and more likely 4) before it was decodable.
>
> I admit that I'm on the fence about whether or not it should be an error--
> it is sometimes interesting to have the ability to add padding
> intentionally, especially for security purposes, but the spec does not
> currently allow this.
>
> -=R
> On Dec 17, 2013 7:41 AM, "Tatsuhiro Tsujikawa" <tatsuhiro.t@gmail.com>
> wrote:
>
>> Current HPACK draft says that huffman EOS is solely used for padding bits
>> if huffman encoded byte strings does not end in byte boundary.
>>
>> '''
>>
>> The EOS symbol is represented with value 256, and is used solely to
>> signal the end of the Huffman-encoded key data or the end of the
>> Huffman-encoded value data. Given that only between 0-7 bits of the EOS
>> symbol is included in any Huffman-encoded string, and given that the EOS
>> symbol is at least 8 bits long, it is expected that it should never be
>> successfully decoded.
>> '''
>>
>> The question is if the receiver gets more than 7bits EOS prefix or full
>> EOS sequence, should the receiver treat it as compression error? The draft
>> does not explicit in this point.
>>
>> There are several such cases:
>> * The encoded byte string ends in the byte boundary but the compressor
>> appends 8bits EOS prefix in the next byte
>> * The encoder appends full EOS bit sequence and possibly append another
>> EOS prefix as padding.
>>
>> I prefer they are subject to compression error, because checking the
>> padding is easy and unambiguous. And we have done in a strict way in this
>> kind of thing.
>>
>> Best regards,
>>
>> Tatsuhiro Tsujikawa
>>
>>