Re: Large Frames, Continuations, Flow Control, and changing HPACK

Note that we can still have a reference set and be streaming-- it just
requires that emitting from the reference set is an explicit
opcode/flag/bit.
This would mean that encoders wouldn't need to know about the reference set
if they didn't care to, which would be nice.

-=R


On Tue, Jul 8, 2014 at 3:53 PM, Nicholas Hurley <hurley@todesschaf.org>
wrote:

> That, however *requires* a streaming implementation, which while possible,
> is not required by HPACK in its current state.
>
> --
> Peace,
>   -Nick
>
>
> On Tue, Jul 8, 2014 at 3:48 PM, Jeff Pinner <jpinner@twitter.com> wrote:
>
>> > .... Being required to split the
>> > HPACK encoding at JUST the right point to fit in a 64k frame is a much
>> > uglier change than asking "I've generated more than 16k of headers.
>> Does my
>> > peer support a frame size that this fits in?"
>>
>> This isn't really an accurate description. Without the reference set,
>> HPACK is now streaming so the decision becomes:
>>
>> 1) Encode this header into x bytes.
>> 2) Is x > 64k? This will never work any more, ABORT!
>> 3) Do x more bytes fit into this frame?
>> 4a) If yes, add x bytes and increase frame length.
>> 4b) If no, flush this frame and start a new one.
>>
>
>

Received on Tuesday, 8 July 2014 23:01:53 UTC