- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 11 Jul 2014 12:46:43 -0700
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
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. > 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.
Received on Friday, 11 July 2014 19:47:13 UTC