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

On Mon, Feb 11, 2019 at 05:58:11PM +0000, Mike Bishop wrote:
> The attack we were concerned about at the time was giving you a partial
> response and forcing you to buffer state for it, then another, then another,
> and never actually finish anything.

In the end that's exactly what we currently have : a PUSH_PROMISE frame
creates a stream on the client, which needs to buffer some elements from
this frame, until possibly forever (even due to server bugs where the
stream is lost there and the HEADERS frame never delivered).

> If you have fully consumed a push, you
> can flush the state, either by delivering it to the application or by
> discarding it entirely.

Sure but my point was regarding the cases where you can't consume it
because it is never completely sent.

> The DoS this permits is blocking the actual response behind lots of pushes --
> something the server can do anyway by simply withholding the response.

But if the stream was counted from the PP frame, that would hold true
as well.


Received on Monday, 11 February 2019 18:47:02 UTC