proposal: x/net/http2: Add ConfigureTransportWithOptions function

[caesarxuchao]

http2.ConfigureTranport configures a net/http HTTP/1 Transport to use HTTP/2, but it does not allow setting http2 specific configurations, e.g., ReadIdleTimeout and PingTimeout. See end-user issue #40201.

The proposal is that adding a ConfigureTransportWithOptions function, which takes a TransportOptions as an input to configure http2 specific configurations.

golang/net#74 is an implementation of this proposal.

[caesarxuchao]

Created this proposal issue per request by @bradfitz at https://go-review.googlesource.com/c/net/+/236498/6#message-40edaf7326dde94c3440c6e8f1f8b1e6ca18b9a7.

Copying reviewers in that CL, @bradfitz @bcmills @rsc @fraenkel @tombergan

[neild]

I don't think we need an entirely new representation of HTTP/2 transport configuration; the *http2.Transport type already exposes all the necessary configuration fields. The problem is that http2.ConfigureTransport doesn't provide any way to get at the *http2.Transport it creates.

I propose instead:

package http2

// ConfigureTransports configures a net/http HTTP/1 Transport to use HTTP/2.
// It returns a new HTTP/2 Transport for further configuration.
// It returns an error if t1 has already been HTTP/2-enabled.
func ConfigureTransports(t1 *http.Transport) (*Transport, error) { ... }

Having ConfigureTransport and ConfigureTransports functions with almost identical names is unfortunate, but the two will sort next to each other in godoc and the difference between the two is obvious from the function signature.

[gopherbot]

Change https://golang.org/cl/264017 mentions this issue: x/net/http2: add ConfigureTransports

[caesarxuchao]

That's a good solution! Thanks, @neild.

At first I was concerned that with this solution, the user won't be able to configure the http2 transport (t2) that's registered as the upgrade handler of t1, but then I realized that t2 is a pointer, so the user can just modify the t2 that's returned by ConfigureTransports.

[caesarxuchao]

The underlying issue was fixed by https://go-review.googlesource.com/c/net/+/264017/.

[gopherbot]

Change https://golang.org/cl/266898 mentions this issue: all: update vendored dependencies for Go 1.16 release