W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 18 Dec 2013 23:30:18 +0900
Message-ID: <CAPyZ6=+d=zWbYDiUYJoC9bLS9pqSx4TFddk+PcYpLy7YhmoF1A@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
>>
>>
Received on Wednesday, 18 December 2013 14:31:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC