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

> Am 11.02.2019 um 10:17 schrieb Willy Tarreau <>:
> 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