Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

[Martin Thomson <[e-mail]>]

On 23 July 2013 07:28, Gábor Molnár <[e-mail]> wrote:
>
> 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.

The section on push makes the following note:

A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
the number of resources that can be concurrently pushed by a server.
Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
server push by preventing the server from creating the necessary
streams.

Maybe this needs to be more explicit, as in:

Servers MUST NOT push or promise to push if a client advertises a
value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS.

The rationale for permitting reservation without consuming streams is
to allow a server to push more resources than the concurrent stream
limit would allow.  There are cases where a single page pulls in that
many resources (e.g., image search pages).  Because the associated
stream must remain open until all pushes are complete, the alternative
would be to artificially extend the lifetime of the associated stream,
which compounds complexity.

I know that we briefly discussed having a MAX_PUSH or MAX_RESERVED
setting, but we still don't really have a lot of good information
about what this would mean.