Re: Flow control for server push

> On 3 May 2016, at 10:23, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> 
> The difference is that this condition may arise with every implementation in the chain being well implemented. PUSHes are often trigger by an application layer that is unaware of other instances of itself and the server may not be able to decide if the PUSHes are necessary/wanted (notifications) or just cache bloating.

Yeah, that’s definitely a substantive difference, but "well implemented" in this instance is a difference of degree, not of kind. There is nothing spec-violating about incrementing flow control windows one byte at a time, it’s just obviously stupid. But that doesn’t necessarily prevent it from happening if the implementation is sufficiently incautious about what it does. Similarly to repeatedly emitting SETTINGS frames with no actual changes, or emitting over-large SETTINGS frames: the specs allow it, it’s just a bad idea. The same applies to emitting 200 pushed streams with no content: you can do it, but you should expect that the connection won’t work well for you!

But maybe the best comparison is with large header blocks. These are explicitly allowed and designed for in RFC 7540, even though they can be just as effective an accidental DOS tool as a blizzard of pushed streams. But all RFC 7540 does here is provide some way to signal to the server what a limit might be (SETTINGS_MAX_HEADER_LIST_SIZE). It doesn’t even try to claim that any size lower than this is allowed: this setting is strictly advisory, and the endpoint setting it is welcome to behave otherwise like it isn’t there. Otherwise, both servers and clients can decide that the other peer messed up (servers can 431, clients can RST_STREAM).

It would likely be enough to just add a new error code (TOO_MANY_PUSHES) and have clients emit that on a RST_STREAM when rejecting pushes that don’t want to be handled. An extra setting to signal how many pushes a client is likely to accept in the same vein as SETTINGS_MAX_HEADER_LIST_SIZE would be a nice-to-have, but isn’t really needed, especially as it’d be advisory at best.

So I agree with you and Roy: the best we really need to do is provide ways to feedback to server operators when they’re in a situation that is causing a client to discard data. Pushes are strictly optional and a client is free to ignore them without notifying the server, so the client is already equipped to handle this better than it can handle the oversized header block, so I don’t really find this problem too troubling.

Cory