- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 11 Jul 2014 21:53:55 +0200
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Jul 11, 2014 at 02:40:53PM -0500, Jason Greene wrote: > > Still, the real issue is the one I quoted: forcing an implementation > > to hold multiple partially complete header sets open is a superb DoS > > vector. Better than the HOL blocking we've been talking about, which > > can be easily contained. > > > > You can do that the same (and prevent it the same) either way. I can create N > connections with incomplete headers just as easily as I can create N streams. > The server can prevent N streams just as easily as it can prevent N > connections. And with streams, you're limited to MAX_CONCURRENT_STREAMS per connection. That said, it's not a reason for dismissing a DoS risk for one's typical use case. I think it favors the single-framed headers with no continuation at all. Currently continuation are a way to build a super-large atomic header frame which prevents interleaving and breaks interactivity just as if an equally large frame was set at once instead. So if we can all agree on 64kB max frame size for the rare case where such large headers are required and get rid of continuation, there's no more HOL blocking than with continuation and we avoid the DoS caused by concurrent users sharing the same connection. Regards, Willy
Received on Friday, 11 July 2014 19:55:14 UTC