Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

On Tue, Jul 23, 2013 at 3:13 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 23 July 2013 14:32, Roberto Peon <grmocg@gmail.com> 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.
>

Well, the alternative is to crash :)
And by discard, I mean RST the reserved stream.
RSTing a reserved stream that the client has no intention of listening to
seems reasonable.
Market forces will force servers to mostly not do stupid crud w.r.t.
sending PUSH_PROMISE when the client really won't use it.
I could imagine smart clients that, wishing to conserve bandwidth, still
want the server to use PUSH_PROMISE like things instead of inlining, but
are happy to leave the potential latency savings on the table.
Such clients want to see what the server is advertising, even when the
number of pushed streams is limited to zero.

Also, remember that a server may push a cache validation/invalidation...


> 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).
>
>
I believe the client should remember everything it hasn't RST.


> 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.
>

Given the above, do you still feel that way? :)
-=R