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: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 11 Feb 2019 11:18:15 +0100
Cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
Message-Id: <C0D36559-9649-48FE-AA1A-2446B5DDD61D@greenbytes.de>
To: Willy Tarreau <w@1wt.eu>

> Am 11.02.2019 um 10:17 schrieb Willy Tarreau <w@1wt.eu>:
> I'm not speaking about a limit on the number of pushes, but on the number
> of allocated streams, which are immediately created in the reserved state
> once the PUSH_PROMISE frame is seen. If I were to implement push in haproxy,
> I would have no choice but to enforce this limit anyway because memory is
> not an infinite resource.

Alas, the limited memory is also true for httpd. I was rather hoping haproxy found a way around this...

> The problem is that the period between PUSH_PROMISE and HEADERS consumes
> memory that is not accounted for. I'd just want to be sure this period is
> covered by the count. That basically means that if a client says it
> supports up to 100 concurrent streams, there are no more than 100 consecutive
> PP frames without a HEADERS or DATA frame carrying an ES flag in the middle.
> Not only I don't see this as an unreasonable expectation, but I do find the
> opposite unreasonable.

I agree. Servers should count PPs agains the stream limit.

However the question remains what Cory should implement here? 

If there is a scenario where a near unlimited number of PPs can be triggered, this becomes a DoS vector either way. Experience says that an early and deterministic PROTOCOL_ERROR might serve us better than some dynamic mitigation that does not really solve the problem but makes breakage more obscure.

- Stefan

PS. httpd's mod_proxy_http2 does disable PUSH on backend connections. With 103 Early Hints, there seems to be no benefit on low latency.
Received on Monday, 11 February 2019 10:18:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 11 February 2019 10:18:42 UTC