HTTP/2 re-sync connection level flow control?

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