Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/net/http2: too much coupling between connection and stream window sizes #15882
I have not really reproduced the problem in the code yet, so this is based on pure source code analysis that I did a while ago (even before http2 was merged into Go 1.6), and since I was reminded of it recently and code didn't change much in that regard in my recent review I decided to finally report it.
There is too much coupling in go implementation of http2 server, which makes stream windows practically useless. The problem is that the only code path where server increments a connection window is in
A hypothetical problematic case would be a file uploading service, that does some database pre-processing before starting to read from
What's more it appears that this approach of coupling connection and stream windows does not even save memory, since
As far as I could understand from the spec connection and stream windows are supposed to be separate, and one good example I've seen recently was http2 in grpc c++ implementation, where connection window is substantially larger than stream window, and the algorithm is also different, as far as I understand: connection window is used for connection-level parsing, decoupled from streams, and updates to client start when more than 3/4 of it is consumed.
Sorry for not providing a code sample to this behavior, I've been postponing this bug report for so long already because of it that I finally decided at least some bug report now would probably be better than no bug report in the foreseeable future again.
Even though this one came first, I'm going to close this in favor of the more succinct #16512 because I don't think there's actually any violation of the flow control specs in our http2 implementation. Let me know if I'm reading this wrong, though.