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

(Apologies for replying to myself)


On 22 June 2014 19:39, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> 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.
>
>
>
I realise I should probably clarify my thoughts on what to do if a single
header doesn't fit in a 16K frame.  The option I like best comes from one
of PHK's earlier posts, where one of the reserved bits in the frame header
is used as a "jumbo frame" marker such that if it's set the first, say,
four octets of payload space is actually an extra 32 bits of payload length
(64 petabytes is pretty stupid, but whatever). To limit the
stupid-potential there'd be an associate SETTING, I think PHK called it
"SETTINGS_MAX_FRAME_SIZE", advertising how much you're willing to receive
in a single frame. I guess it would encode the number of bits by which
you're willing to extend the length, or something like that (default=zero,
of course).

I realise this is a bit of a change from what we currently have, but as
with many of my suggestions, the minimal effort to support it is quite
simple: ignore the setting, and maybe do a little bit more
reading/arithmetic to decide whether to throw a FRAME_SIZE_ERROR. Some of
that could even be gotten around if we make setting the "jumbo frame" bit
illegal without having ACKed a SETINGS_MAX_FRAME_SIZE.

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