- From: Jason Greene <jason.greene@redhat.com>
- Date: Sat, 28 Jun 2014 15:38:49 -0500
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Greg Wilkins <gregw@intalio.com>, 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>
On Jun 28, 2014, at 2:48 PM, Roberto Peon <grmocg@gmail.com> wrote: > 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 forward. > > It is better to allow a proxy to forward data if it can. True, although if it does that the HOL blocking will force it to buffer all the other streams, so its not reliably helpful to break things up like that. > > -=R > > > > 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. > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Saturday, 28 June 2014 20:39:51 UTC