W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 8 Jul 2014 16:01:27 -0700
Message-ID: <CAP+FsNcS=n7SOj8=4uOGXdep+SngaC7Y4mrpLKGG57fS=HWtaQ@mail.gmail.com>
To: Nicholas Hurley <hurley@todesschaf.org>
Cc: Jeff Pinner <jpinner@twitter.com>, Jason Greene <jason.greene@redhat.com>, Mike Belshe <mike@belshe.com>, Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
Note that we can still have a reference set and be streaming-- it just
requires that emitting from the reference set is an explicit
This would mean that encoders wouldn't need to know about the reference set
if they didn't care to, which would be nice.


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

> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC