W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

From: James M Snell <jasnell@gmail.com>
Date: Tue, 23 Jul 2013 09:46:03 -0700
Message-ID: <CABP7RbcNUmUWGXC6xmbMWTKX4Lcz3wPvwMX5hr-wAXA8PRCJbA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Gábor Molnár <gabor.molnar@sch.bme.hu>, HTTP Working Group <ietf-http-wg@w3.org>
+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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC