Investigate dropping use of golang.org/x/net/http2 in Horizon #1695
Assignees
Labels
Comments
7 tasks
leighmcculloch
added a commit
that referenced
this issue
Sep 5, 2019
Use the default `net/http` transport which supports http2, instead of using `x/net/http2`. At some point early on we adopted using `x/net/http2` as the http2 transport in our servers. It was probably necessary at the time, I'm not sure, but it's not necessary today unless we need full access to configure the transport. In our case we're initializing the http2 package with an empty config, so that alone suggests we are unnecessarily using that package. @bartekn noticed this while reviewing #1688 (comment) a dependency upgrade required for the shift from Dep to Modules. The `net/http` package uses a vendored version of `x/net/http2` for http2. We only need to use `x/net/http2` directly if we want to customize it in ways that `net/http` doesn't expose, or if we want to use a later version of the http2 transport that has yet to be included in a release of Go. A huge downside of using the package directly though is that if critical fixes are made to it and included in a minor Go release we won't get them unless we manually update this package. The godocs for the [net/http](https://golang.org/pkg/net/http/) package contain more details about the relationship between `net/http` and `x/net/http2`. Close #1695 Summary of changes: - Remove configuration of the http2 transport for Horizon. - Remove configuration of the http2 transport for code shared by Federation, Bifrost, and Bridge. Testing: No tests that we have in the repository will identify any issues with this change, and any tests we could write would be complex and not helpful longterm, so I took a manual approach: 1. I ran Horizon with TLS enabled, with and without this change, and used curl to verify that the HTTP2 upgrade occurs successfully and results in a `HTTP/2 200` response, using this `curl` command: ``` curl -vk --http2 https://localhost:8000 ``` This test was successful. 2. I ran Horizon with TLS enabled, with and without this change, and used [h2spec](https://github.com/summerwind/h2spec) to verify that the server before and after the change has the same spec passes and failures, using this `h2spec` command: ``` h2spec http2 -t -k -h=localhost -p=8000 ``` This test was successful on most runs. There were definitely spec failures, but they were consistent before and after the change. In one run I noticed spec 6.9.3 part 3 (window updates) failed on `net/http`, however on re-runs it didn't fail. Investigating, I found a report in golang/go#31170 that `x/net/http2` may not be handling window updates correctly in some scenarios, and so it is likely that this issue is intermittent and present when using either and I just witnessed it only on one. An identical change was also made to code shared by the federation, bifrost, and bridge servers. I ran the same tests above against the federation server with TLS enabled to verify that both code paths were unaffected.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@bartekn identified when reviewing #1688 (comment) that our use of the Go subpackage golang.org/x/net/http2 in Horizon is probably unnecessary given we aren't providing any custom configuration.
We should stick to using the stdlib
net/httppackage for http servers as it supports http2. The http2 subpackage is only intended for situations requiring significant customization.The text was updated successfully, but these errors were encountered: