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: Fri, 8 Feb 2019 21:15:25 +0100
To: Cory Benfield <cory@lukasa.co.uk>
Cc: ietf-http-wg@w3.org
Message-ID: <20190208201525.GB22355@1wt.eu>
Hi Cory,

On Fri, Feb 08, 2019 at 04:42:45PM +0000, Cory Benfield wrote:
> My instinct is to say that these streams do not count against

I agree with you here. In fact whenever you think about concurrency, you
need to think of it including the time and space factors : if it is *not*
this way, then what is the scope where this concurrency is counted on ?
Do you need to measure it over a certain time window ? Fortunately not.
Do you have to measure it at any given point (e.g. your H2 connection
buffer) ? Not at all either since what your agent sees will differ from
what any other agent along the chain sees. Thus this concurrency is purely
event-driven (HEADERS/PUSH_PROMISE = +1, END_STREAM/RST_STREAM = -1) and
you have no other way to accurately measure, hence enforce your limit.
So you can very well have a series of messages each creating and closing
a stream. Similarly you could have a client send HEADERS followed by
RST_STREAM. Any observator outside would see series of +1/-1 and a
concurrency that never exceeds the number of subsequent creations
before an RST.

> This instinct is largely informed by
> Martin's previous characterisation of RFC 7540 as being written "as
> though headers were free". In a model where headers cost nothing, a
> stream guaranteed to be made only of headers never counts against

For me this is distinct, because in your case the HEADERS frame carries
the END_STREAM bit which closes the stream. So in fact between PUSH_PROMISE
and HEADERS it exists. If for any reason your agent sends a series of PP,
then can't send for a while due to poor network conditions, then sends a
series of HEADERS+ES you clearly see that the concurrency really exists.
It's just that in your specific case it's very ephemeral and you can
arrange for it never to exceed 1.

Received on Friday, 8 February 2019 20:15:50 UTC

This archive was generated by hypermail 2.3.1 : Friday, 8 February 2019 20:15:51 UTC