Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

+1 to tightening this up... that is: If
SETTINGS_MAX_CONCURRENT_STREAMS = 0, Servers MUST NOT send
PUSH_PROMISE

On Tue, Jul 23, 2013 at 9:22 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 23 July 2013 07:28, Gábor Molnár <gabor.molnar@sch.bme.hu> 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.
>

Received on Tuesday, 23 July 2013 16:46:50 UTC