- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 23 Jun 2014 08:54:58 -0700
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: K.Morgan@iaea.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
+1... especially if it means getting rid of CONTINUATION. On Mon, Jun 23, 2014 at 5:36 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote: > On 23/06/2014, K.Morgan@iaea.org <K.Morgan@iaea.org> wrote: >> On Sunday,22 June 2014 14:36, phk@phk.freebsd.dk wrote: >>> , Matthew Kerwin writes: >>> >>>>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 >>> >>> I would have it be the max length of *any* frame we're willing to accept, >>> and the default would then obviously be the 16kbyte currently implicit in >>> the standard. >>> >> >> So are you proposing the "jumbo frame" marker for all frames, not just the >> HEADERS frames? > > I suppose so. It makes no sense on a fixed-length frame like PING, but > it simplifies the machinery no end if all frames have the same > handling -- that's the whole idea, in fact. > >> I think it's a great idea, but I know it makes a bunch of >> people nervous about HOL blocking if you allow more than 16K in a DATA >> frame. >> > > Hence the setting. > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ >
Received on Monday, 23 June 2014 15:55:50 UTC