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

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 18 Dec 2013 00:36:04 +0900

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

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 17 Dec 2013 08:46:29 -0800

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

On Tue, Dec 17, 2013 at 7:36 AM, Tatsuhiro Tsujikawa
<[email-masked]>wrote:

> 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.
>
> * The encoder appends full EOS bit sequence and possibly append another
> EOS prefix as padding.
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Dec 2013 08:53:02 -0800

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" <[email-masked]>

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 18 Dec 2013 23:30:18 +0900

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 <[email-masked]> wrote:

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