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

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

From: Roberto Peon <grmocg@gmail.com>
Date: Sat, 28 Jun 2014 12:48:03 -0700
Message-ID: <CAP+FsNc0jaQGnbpEznp3nynbKWLDT-pAYpqvq7KQMgx26352_A@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Willy Tarreau <w@1wt.eu>, 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>
If you're concerned that headers are being sent a byte-at-a-time (slowloris
style), then you could do that with a regular headers frame anyway.
If you're concerned that the overhead of frames is blowing up the
bandwidth, then that could happen with PING, SETTINGS, DATA, etc. and is
not unique to HEADERS or HEADERS processing.
It is also point-to-point, and so any non-malicious client should be
unaffected by malicious clients.

The requirement to send END_HEADERS unless it is at max size adds a DoS
vector because it makes it impossible for a proxy to forward anything or
send anything until it has buffered the entire HEADERS, even when it has
all of the information necessary to figure out to which server it should

It is better to allow a proxy to forward data if it can.


On Sat, Jun 28, 2014 at 1:23 AM, Greg Wilkins <gregw@intalio.com> wrote:

> 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 that.
> cheers
> --
> 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 19:48:30 UTC

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