Re: Stuck in a train -- reading HTTP/2 draft.

On 22 June 2014 18:27, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 22 Jun 2014, at 1:58 am, K.Morgan@iaea.org wrote:
>
> > On 19 June 2014 06:49, mnot@mnot.net wrote:
> >> On 18 Jun 2014, at 8:29 pm, Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
> >>>
> >>> I'm starting to really hate the entire HEADER+CONTINUATION kludge
> >>> upon kludge upon kludge hackery.
> >>>
> >>> My preference would be to impose sanity by simply removing CONTINUATION
> >>> and telling cookie monsters that if their HPACK compressed HTTP
> >>> headers do not fit in 16k, they should consider a diet.
> >>
> >> One thing that came up in a side conversation in NYC was the
> possibility of only
> >> HPACKing the HEADERS frame; subsequent CONTINUATION frames would
> >> be uncompressed (so they don't affect state, and could be flow
> controlled).
> >
> > How could this work? Aren't headers allowed to cross frame boundaries?
> You can't switch from compressed to uncompressed in the middle of a header,
> no?
>
> A sender would have to compose their header frames appropriately; e.g.,
> putting all of the small / repeating headers in the compressed frame, with
> remaining frames in the subsequent uncompressed frames. In a pathological
> case, it means that most or all of the headers would be uncompressed.
>
> Personally, I’m OK with that; it supports the weird cases, but doesn’t
> optimise for them. YMMV.
>
>
I like this idea; you can fit a fair whack of "normal" headers in 16K of
Huffman-coded (let alone delta compressed) payload, and if you insist on
sending more than that, then you have to prioritise appropriately. It also
frees us up from blocking on possibly arbitrarily many CONTINUATION frames,
and allows us to gauge the size of incoming header data sooner.

Thinking in terms of my
implementation
, I
​'d likely still want to sit on the entire header block before emitting it
to the API, but I could imagine that someone more streamey (someone with a
more advanced API, or a high-throughput intermediary) would probably
benefit a lot from being able to treat *all* frames as individual
<s>datagrams</s> packets.



-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/