all: use net/http instead of x/net/http2 #1713
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
This PR adds tests for the most critical parts of the new functionality or fixes.I've updated any docs (developer docs,.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
I've updated the relevant CHANGELOG (here for Horizon) ifneeded with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
Summary
Use the default
net/http
transport which supports http2, instead of usingx/net/http2
.Goal and scope
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 ofx/net/http2
for http2. We only need to usex/net/http2
directly if we want to customize it in ways thatnet/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 package contain more details about the relationship between
net/http
andx/net/http2
.Close #1695
Summary of changes
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:
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 thiscurl
command:This test was successful.
I ran Horizon with TLS enabled, with and without this change, and used h2spec to verify that the server before and after the change has the same spec passes and failures, using this
h2spec
command: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 x/net/http2: sendWindowUpdate may send invalid window size increment golang/go#31170 thatx/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.
Known limitations & issues
N/A
What shouldn't be reviewed
N/A