W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #540: "jumbo" frames

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 26 Jun 2014 12:18:16 +1000
Message-ID: <CACweHNBKm0uO7kBrn_0Pefwg10Xejn97CL6dn4jgq-gUjWvESA@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Thursday, 26 June 2014 02:18:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC