Re: HPACK edge cases

On Sat, Mar 8, 2014 at 3:22 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi
> wrote:

> On Fri, Mar 07, 2014 at 09:11:56PM +0900, Tatsuhiro Tsujikawa wrote:
> > On Fri, Mar 7, 2014 at 8:40 PM, Johnny Graettinger <
> > >
> > > EOS has value iff it may be used for padding. As HEADERS etc now have
> an
> > > explicit padding mechanism I'm also not sure it's needed. (Also: To
> pad the
> > > table need only have an 8-bit code. As a canonical code, all-zeros
> would be
> > > the shortest code in the table).
> > >
> > >
> > A while ago, we discussed this in the ML.
> > http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1866.html
> >
> > In short, strictly more than 7 bits of 1 if encountered in decoding must
> be
> > treated as error.
>
> Even with valid UTF-8 (albeit with currently unassigned codepoints), one
> can
> come up with values that have 105 consequtive 1 bits if compressed with
> current tables.
>
>
I mean padding bits at the tail.
When decoding huffman encoded byte string, we process bit by bit and emit
the symbol successfully decoded (but EOS is decoded, it is an error).
Since huffman encoded bytes are not byte aligned, we have possible 1 to 7
bits
of padding. When we processed all bits, the following decoding states are
acceptable:

1) symbol, except for EOS, was just emitted with the last bit.
2) symbol was not emitted, but byte string ended when decoding state
consumed at most 7 bits of consecutive 1.
3) byte string is zero length

I think the other cases are error.

 You referred to the state machine in the another mail, in that transition
graph,
we can mark successful decoding as acceptable state (except EOS).
We also mark the states at most 7 bits of consecutive 1 from the initial
state.

Best regards,
Tatsuhiro Tsujikawa



> -Ilari
>