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

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