Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

[Martin Thomson <[e-mail]>]

On 23 July 2013 14:32, Roberto Peon <[e-mail]> wrote:
> Even if push promises were limited by some configuration, changes to that
> configuration can cause this condition to occur. Thus, clients must be able
> to handle PUSH_PROMISE frames by at least discarding them.

I'm a little concerned by the suggestion that PUSH_PROMISE can simply
be discarded.  It creates a reservation for a stream, which
necessarily creates state in the client.

If, as you point out, the client could lift this limit from zero, is
there some corresponding expectation that the client remembers all of
these reserved streams so that they can enter the right state at the
point that the server decides to exercise the reservation?  Without
any limits on number or the time that a reservation can remain
outstanding, the only rational response a client implementer has is to
reset those streams, if they don't want unbounded state commitment
(even if it is a relatively small allocation for each stream - 2 bits
in the best case - anything greater than zero could be problematic).

We've done a lot to protect resources on a server, but I don't think
that a client is able to limit the commitments it has to make in order
to continue to use a connection.