Re: BLOCKED frame specification

I'm not a huge fan of this proposal as it seems to add complexity for 
not much gain. It seems debug data in the GOAWAY frame or an extra 
RST_STREAM code (e.g. BLOCKED_FLOW_CONTROL_TIMEOUT) would serve well 
enough here.

This proposal may also encourage bad protocol implementation. For 
instance, a broken flow control implementation might be patched to 
"work" by automatically sending WINDOW_UPDATE frames whenever a BLOCKED 
frame is received, despite internal state problems.

> 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?)
This requires implementations to track more state. Is there any reason 
that this is a MUST NOT? It seems like SHOULD is strong enough. How 
servers respond to many BLOCKED frames should be left flexible. For 
instance, a pathological sequence of BLOCKED / WINDOW_UPDATE / BLOCKED / 
... etc may warrant an ENHANCE_YOUR_CALM as well.

Received on Tuesday, 8 April 2014 21:51:51 UTC