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

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

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 22 Jun 2014 12:36:11 +0000
To: Matthew Kerwin <matthew@kerwin.net.au>
cc: Mark Nottingham <mnot@mnot.net>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <11456.1403440571@critter.freebsd.dk>
In message <CACweHNBNUpPWLw+NOE0s17LWL_1OKjWDitTGMxtaUUw6+=UqJg@mail.gmail.com>
, 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
>(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 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.

And I *far* prefer to have a frame length-extension bit, to having
CONTINUATION and all that kludgery.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 22 June 2014 12:36:45 UTC

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