Re: #540: "jumbo" frames

On 25 June 2014 06:10, Mark Nottingham <mnot@mnot.net> wrote:

> WRT the "jumbo" frame (i.e., flagging that some prefix of the payload is
> actually an extension length) -- this sort of hack is necessary to
> back-port bigger frames onto an existing protocol. Let's not do it out of
> the gate.


But we have to backport bigger "frames" into the protocol: namely the
unlimited sized headers that we are currently stuffing into CONTINUATION
frames.

An increase to 64KB frames would not allow us to drop CONTINUATION frames,
as apparently we still need to support huge headers.

Note that with continuations, that cannot be interleaved with other frames,
we effectively have a jumbo frames anyway.  The END_HEADERS bit is the
extension bit and the extension length is at the end of the first frame (in
the header of the next "frame").

Semantically there is little difference between HEADERS+CONTINUATION* and
jumbo frames.  It is just that jumbo frames are simpler to describe,
explain, motivate, implement, understand, debug etc.

Another plus of jumbo frames is we know the total encoded length up front
and can reject large frames immediately.  CONTINUATIONS have the problem
that you don't know how big they will eventually get and they just keep
coming.  CONTINUATIONS also have a DOS vector of a client sending many 1
bytes CONTINUATIONS

The minus of jumbo frames is it makes sending huge headers a little harder
as you have to completely encode to know the length before you start
sending them.  Decoding can still be streamed if you really want.


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.