- 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>
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