W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

HTTP/2 re-sync connection level flow control?

From: Graham King <graham@gkgk.org>
Date: Wed, 13 Feb 2019 23:47:40 -0500
Message-Id: <02746239-a6e1-41b9-877b-9cac4d94012d@www.fastmail.com>
To: ietf-http-wg@w3.org
Given a range of HTTP/2 implementations with their bugs, edge cases, varied interpretations and understandings of the spec, not to mentioned network issues, the connection-level flow control values could get out of sync between client and server. 

Once client and server get out of sync, there is no mechanism for them to re-sync. The WINDOW_UPDATE values are always relative (increment). If the client reaches a window of 0 it will block. With enough deployments, and sufficiently long running connections, it seems almost inevitable that some will block because of this.

This happened in Go 1.11. DATA frames sent after a stream close weren't being counted towards flow control on the server side, but were on the client side (It is fixed in Go 1.12): https://github.com/golang/go/issues/28204

In QUIC (at least at some point, I couldn't find this in HTTP/3 spec) the sender sends a BLOCKED frame when it's window reaches 0. QUIC also includes a flow control value in RST frames to permit resync. https://docs.google.com/document/d/1F2YfdDXKpy20WVKJueEf4abn_LVZHhMUMS5gX6Pgjl4/edit#heading=h.i0f2zh9yfysp

Should HTTP/2 include a means for client and server to resync absolute connection level flow control values?
Received on Thursday, 14 February 2019 10:41:06 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 February 2019 10:41:08 UTC