Re: BLOCKED frame specification

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
section.

> 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