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