- From: Yoav Nir <ynir.ietf@gmail.com>
- Date: Tue, 8 Apr 2014 22:02:10 +0300
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Hasan Khalil <mian.hasan.khalil@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
It looks good to me, except I would replace the word “debugging” with the word “troubleshooting”. The former is usually associated with implementation development, whereas the latter is associated with figuring out why my download keeps breaking up. On Apr 8, 2014, at 2:59 AM, Mark Nottingham <mnot@mnot.net> wrote: > Thanks, Hasan. > > What do people think? > > My inclination at this point is to include this in the implementation draft, but mark it AT RISK -- i.e., we might pull it out before finalising the spec, based upon whether it turns out to be useful in interop. > > Cheers, > > > On 8 Apr 2014, at 7:43 am, Hasan Khalil <mian.hasan.khalil@gmail.com> wrote: > >> Here's at least a starting point. Comments welcome. >> >> 6.x BLOCKED >> >> The BLOCKED frame (type=0xPLACEHOLDER) conveys flow control and data availability status useful in tuning and debugging flow control. >> >> The BLOCKED frame contains no payload and does not define any flags. Semantically the BLOCKED frame is used to indicate to a remote endpoint that data subject to flow control was available to be sent, and that the underlying transport was ready to send said data, but was prohibited from sending said data due to either stream-level or connection-level flow control windows being nonpositive. The specific flow control window prohibiting the sending of said data is indicated in the stream id of the BLOCKED frame. In the stream-level flow control blockage case, the frame's stream identifier indicates the affected stream; otherwise the value "0" indicates connection-level flow control blockage. >> >> 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?) >> >> 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. >> > > -- > Mark Nottingham http://www.mnot.net/ > > > >
Received on Tuesday, 8 April 2014 19:02:44 UTC