- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 27 Apr 2016 14:49:54 +1000
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 27 April 2016 at 14:28, Amos Jeffries <squid3@treenet.co.nz> wrote: > My understanding was that endpoints should (MUST?) assume 100 streams > was permissiable up until the SETTINGS was received+ACK'd. After which > point whatever value was ACK'd is used as the limit. > > If the limit was lower than the default 100 some streams the excess may > be delayed on responding or get RST_STREAM with corresponding re-try > being needed when space opened up again (possibly on other connections > for faster total latency). The concurrent stream limit is actually unbounded in the first flights. But unless you have special magic, you won't be able to pack that many requests into the connection before hitting the TCP congestion window. It might be more than 100 though. In practice, you are right. If you go crazy, you risk getting a RST_STREAM.
Received on Wednesday, 27 April 2016 04:50:23 UTC