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
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

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