W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: BLOCKED frame specification

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 22 Apr 2014 12:05:46 -0700
Message-ID: <CABkgnnXg5aSU0KMdske3rCv4YEic_D5=3o_L3jnYnr+6Ahkp1Q@mail.gmail.com>
To: Hasan Khalil <mian.hasan.khalil@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Integrating a paraphrased version now.  A few observations below.
(Net result: even less text :)

On 7 April 2014 14:43, Hasan Khalil <mian.hasan.khalil@gmail.com> wrote:
> Endpoints MUST NOT send a successive BLOCKED frame on a given stream id
> (including "0") unless the associated flow control window became positive
> since the last time that a BLOCKED frame for that flow control window was
> sent. This can happen only as a result of receiving a WINDOW_UPDATE frame or
> appropriate SETTINGS frame increasing said flow control window. (TODO: Add
> reference to appropriate sections of flow control spec?) (TODO: Add
> GOAWAY-ENHANCE_YOUR_CALM usage here as appropriate behavior in this case?)

During normal operation, it's going to be difficult to determine when
a WINDOW_UPDATE was seen and acted upon by a peer with any real
certainty.  SETTINGS at least has an acknowledgement.  I'm not going
to add anything for this, though I will make a note of this in the DoS

> BLOCKED can be sent by a peer that has sent a frame bearing the END_STREAM
> flag. This means that a receiver could receive a BLOCKED frame on a "half
> closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an
> error, see Section 5.1.

This doesn't make sense.  You only want to send BLOCKED when you might
normally send DATA.
Received on Tuesday, 22 April 2014 19:06:13 UTC

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