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

IMHO this should be a Compression Error and the session torn down.


On Tue, Dec 17, 2013 at 7:36 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
>
>