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: Willy Tarreau <w@1wt.eu>
Date: Mon, 11 Feb 2019 07:55:09 +0100
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20190211065509.GB26821@1wt.eu>
On Mon, Feb 11, 2019 at 10:18:08AM +1100, Martin Thomson wrote:
> On Sat, Feb 9, 2019, at 17:57, Willy Tarreau wrote:
> > I was surprised by this assertion, until I found that streams in the
> > reserved state are not counted. Do you have an idea why it's done this
> > way ? This means that a server can trivially DoS a client or intermediary
> > by pushing 1 billion streams that must be memorized and are not accounted
> > for :-/
> 
> Yep.  There is no practical limit on push in HTTP/2.  We fixed that in
> HTTP/3.  Well, it would be impossible not to fix this in some way, but we
> doubly fixed it anyway.

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.

> As for the original question, I think that Mike's interpretation is closest
> to intent.  If you have 5 streams open and a limit of 5, then opening another
> would be a violation of expectations.

Yes I agree.

> p.s., I find it amusing when people start to read meaning into words.
> Remember that RFCs were written by humans in something of a hurry and without
> the benefit of experience.  It is usually best to consider first what might
> have been intended before wondering about the relative placement of certain
> words.

Definitely! This is why I personally don't like when we go too much into
the algorithms or code-like sequence in RFCs, and I strongly prefer to
illustrate corner cases and possible solutions to better deliver the intent
and let implementers adapt to this.

Willy
Received on Monday, 11 February 2019 06:55:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 11 February 2019 06:55:40 UTC