Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

The whole point of push-promise is to not count them, and so to avoid the
condition where the number of resources it wishes to push exceed the max
concurrent stream limit, causingna race.

E.g. if max concurrent stream limit is 10, but I have 21 resources to push.
If push-promise counted, I'd be unable to advertise push promise for all of
these resources, potentially causing a race on the 11 resources the server
was not allowed to send luah-promise for. This would be true even if I was
sending the resources one at a time...

You ask a separate question about whether or not push-promise can be sent
when max-concurrency is 0. Personally, I don't see any real harm in it. The
client can discard the data after putting them through the compressor.
Push-promise is only distinguishable from the headers  frame by the opcode,
so we should be talking about very minimal amounts of code.

-=R
 On Jul 23, 2013 7:30 AM, "Gábor Molnár" <gabor.molnar@sch.bme.hu> wrote:

> It is possible to set SETTINGS_MAX_CONCURRENT_STREAMS to 0. AFAIK, the
> design rationale behind this is that a client can forbid server push if it
> does not implement it yet or just does not want to receive push streams.
>
> Since streams in "reserved (local)" state do no count as active stream,
> the server can still promise push streams even if
> SETTINGS_MAX_CONCURRENT_STREAMS is 0. (But it can not actually send the
> content on the promised stream.)
>
> This goes against the design rationale, since clients will still have to
> be able to deal with PUSH_PROMISEs if they want to comply to the standard.
>
> What is the rationale behind not counting reserved streams as active? They
> usually become active very soon so it would make sense to count them as
> active as well. This would also prohibit servers promising streams when
> SETTINGS_MAX_CONCURRENT_STREAMS is 0.
>
>   Gábor
>