Re: #540: "jumbo" frames

Just to clarify...

On 26 June 2014 09:53, Matthew Kerwin <matthew@kerwin.net.au> wrote:

>
> If we consider the status quo as option 5, its only downsides are:
> END_STREAM is in the wrong place, and jerks who send ginormous headers
> screw up their user experience. Also it's annoying to have to design
> your low level packet shuffler, if you have one, to throw errors if
> one packet has certain bit pattern (HEADERS-END_HEADERS) and the next
> doesn't have another (CONTINUATION).
>
>
I mean to say: the current spec (i.e. treating the HEADERS and
CONTINUATIONs as a single contiguous block​) is option 5, and its downsides
are pretty minor in the grand scheme of things.


I'd be happy to consider my option 4.5 further, if it's not going to bog
everyone down in a circular discussion. That option is essentially:​ only
HEADERS is compressed (using the connection-wide HPACK state), and
subsequent CONTINUATIONs are designed such that individual headers can span
frame boundaries (i.e. introducing a per-stream state -- a buffer for a
partial header).  We buy back the HOL blocking issue (and protect ourselves
against 1-byte CONTINUATIONS, etc.), but we introduce a second state
commitment. OTOH we'd need at least one new setting, to advertise the size
of the buffer we're willing to hold (either as "X bytes per stream," or "Y
bytes shared across all streams.")

(Sorry for replying to myself.)


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