W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

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

From: Martin Thomson <mt@lowentropy.net>
Date: Mon, 11 Feb 2019 19:04:34 +1100
Message-Id: <1549872274.1246151.1655309992.7900E210@webmail.messagingengine.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 11 February 2019 08:05:00 UTC