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

On 9 July 2014 08:11, Jason Greene <> wrote:

> Wow, are we actually approaching consensus? :)

I think bifurcation is a word that comes to mind  more than consensus :(

CONTINUATIONs are just emergent design uglyness that resulted from the
inability to split headers and small frames.   Having large frames doesn't
solve the base issue, but does get rid of much of the design uglyness that
resulted, plus it supports some tuning/efficiencies of data transfer as
well.  So I really hope we can reach consensus on that part soon.

Jeff proposal is a much bigger step towards a h2 that would have a pure
framing layer, over which http, websocket etc. semantics can be layered.
But it is not a complete step.  Removing the Reference Set would allow
interleaving, but it would still have shared state, so the order of
decompressing is still fixed and thus header encoding and HTTP semantics is
still effectively part of the framing layer.

So I'm wondering if such a drastic step were to be contemplated, if it
would just be better to ask to be rechartered to be tasked with designing a
general web framing layer that could support multiple web protocols - and
then design that fully properly rather than just cut off the bits of h2-13
that don't look like it.     Ie the current design is suffering as it has
been asked only to consider http.   If we were asked to consider http,
websocket and other future protocols, then the outcome would be different

So I think that HPACK as is, is a little complex but does meet our current
charter.  I'm not so sure our charter is correct and if it isn't then Jeffs
proposal probably points in the direction to go.


PS> But under the current charter, I certainly wouldn't weep if the
ReferenceSet was dropped and headers flow controlled.

Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Tuesday, 8 July 2014 23:20:32 UTC