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

Re: BLOCKED frame specification

From: Daniel Sommermann <dcsommer@fb.com>
Date: Tue, 8 Apr 2014 14:51:25 -0700
Message-ID: <53446F5D.8030206@fb.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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

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