Resent-Date: Tue, 23 Jul 2013 16:46:59 +0000
Resent-Message-Id: <E1V1fjn-0003cS-5k@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <CABkgnnURpBaQYSeCTPHyMRbeqEU-=EPuXP2L_Z087o5LY8cxTg@mail.gmail.com>
References: <CA+KJw_5PcUxBiUnQ00=G2C4Q6MnaB=hpNDk+9eTeZMs3Lz-CpA@mail.gmail.com>
 <CABkgnnURpBaQYSeCTPHyMRbeqEU-=EPuXP2L_Z087o5LY8cxTg@mail.gmail.com>
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: =?UTF-8?B?R8OhYm9yIE1vbG7DoXI=?= <gabor.molnar@sch.bme.hu>,
 HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.170; envelope-from=jasnell@gmail.com;
 helo=mail-ob0-f170.google.com
Subject: Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE
Archived-At: <http://www.w3.org/mid/CABP7RbcNUmUWGXC6xmbMWTKX4Lcz3wPvwMX5hr-wAXA8PRCJbA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

+1 to tightening this up... that is: If
SETTINGS_MAX_CONCURRENT_STREAMS =3D 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=C3=A1bor Moln=C3=A1r <gabor.molnar@sch.bme.hu> w=
rote:
>>
>> 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? Th=
ey
>> 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.
>