Re: Are HTTP/2 state changes atomic with respect to SETTINGS_MAX_CONCURRENT_STREAMS?

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