- From: Martin Thomson <mt@lowentropy.net>
- Date: Mon, 11 Feb 2019 19:04:34 +1100
- To: ietf-http-wg@w3.org
On Mon, Feb 11, 2019, at 17:55, Willy Tarreau wrote: > I think even for H2 we could address this, because I find it extremely > unlikely that some real workloads depend on the unbound aspect of this. > The change could be as simple as sayng that the stream is counted when > it is created (PUSH_PROMISE) just the way it works in the other direction. > And it most likely matches what implementations can naturally do. I would > not be surprised if some of them continue to count the allocated streams > towards the limit anyway. That would be a breaking change, so you would want to signal it. And I'm not sure that it would place any meaningful limit on the number of pushes. You can still send PUSH_PROMISE and fulfill the promise without any feedback, meaning that as long as you can complete the entire cycle, you can send unbounded pushes if even a single push is allowed. The only meaningful limit in that case would be TCP flow/congestion control. The real fix is to add feedback into the loop and force the server to wait until the client allows it. The MAX_PUSH_ID in h3 does that; a similar fix could be used here.
Received on Monday, 11 February 2019 08:04:58 UTC