No reason I recall. I think it was just muscle memory when I wrote it.

I started digging into this, and can't seem to write a test that has an HTTP/2 enabled client.

The problem is that HTTP/2 is disabled on all clients that set InsecureSkipVerify on their transports, which is needed to use httptest's HTTPS servers, because TLSClientConfig will be non-nil but there's no public func like http2.ConfigureTransport to reenable it. The one bundled in the net/http library is unexported and so are the structs it relies on.

So, I can't seem to figure out how to get a HTTP/2 enabled client inside a test in net/http/httputil.

But maybe there's something I missed?

(edited last comment to be more clear)

Actually, the hard-coding of the fields is pointless.

From the docs:

https://golang.org/pkg/net/http/#Request

        // The protocol version for incoming server requests.
        //
        // For client requests these fields are ignored. The HTTP
        // client code always uses either HTTP/1.1 or HTTP/2.
        // See the docs on Transport for details.
        Proto      string // "HTTP/1.0"
        ProtoMajor int    // 1
        ProtoMinor int    // 0

And I saw another bug where people were using ReverseProxy with HTTP/2 just fine. (But that wasn't the point of the bug, IIRC).

So I think there's nothing to do here.

I'll remove those lines from the ReverseProxy code, though.

CL https://golang.org/cl/28412 mentions this issue.