- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 11 Jul 2014 14:54:53 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Jul 11, 2014, at 2:46 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 11 July 2014 12:40, Jason Greene <jason.greene@redhat.com> wrote: >> 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. > > The limit that a server might permit is very different for streams and > connections, so it's not the same thing at all. I can have 300k requests delivered over any ratio of connections to streams. Granted connects are a bit more throttled, and make a bit more noise. > >> Roberto’s analysis is really just an argument that streaming is problematic for receivers, and to that I agree. If it’s benefits are to be limited to 1:1 connection proxies then I don’t think the benefits of the feature justify its complexity. > > It's more than that, it's an observation that concurrency limits > matter. The current design limits this particular point to 1, not > SETTINGS_MAX_CONCURRENT_STREAMS. That bounds state commitments in a > predictable fashion. The DOS attack is the amount of memory allocated per incomplete request. The server can track that, and it can easily RST_STREAM when it detects there is too much. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 11 July 2014 19:56:11 UTC