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

Re: CONTINUATION was: #540: "jumbo" frames

From: Greg Wilkins <gregw@intalio.com>
Date: Sat, 28 Jun 2014 10:23:25 +0200
Message-ID: <CAH_y2NFm8vH-6gdM3r+E8JVbECdjDXUGmDGUixXu6BcpzsG-yg@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Johnny Graettinger <jgraettinger@chromium.org>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 27 June 2014 22:16, Willy Tarreau <w@1wt.eu> wrote:

> Would that be OK for every one ?

It would help with my concern of Continuations being used as a DOS vector
with 1 byte per frame, so long as you are proposing text that say a send
MUST NOT have the END_HEADERS bit clear unless the frame is at max size?
Any receiving can treat non full frames without the END_HEADERS bit set as
a protocol error?

Note that it does not address my concern of code that is not used by 99.99%
of users but that complicates the handling of every frame and will only get
used/tested in a tiny minority of deployments.   Such code is asking to
contain lurking bugs and exploits.... however I think my fundamental
concern with continuations probably goes back to their jumbo frame nature
and hpack's single state table... so we would need a big rewrite to address


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.
Received on Saturday, 28 June 2014 08:23:54 UTC

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