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: Jeff Pinner <jpinner@twitter.com>
Date: Tue, 17 Dec 2013 08:46:29 -0800
Message-ID: <CA+pLO_iOSC-7FhQebAz8pPPAR+E4Lezpbe9KnGwE0A5x4kQNfA@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
IMHO this should be a Compression Error and the session torn down.

On Tue, Dec 17, 2013 at 7:36 AM, Tatsuhiro Tsujikawa

> 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 Tuesday, 17 December 2013 16:46:57 UTC

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