x/net/http2: rename and export Transport's t1 field

[mna]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?

   go version go1.7rc4 darwin/amd64

2. What operating system and processor architecture are you using (go env)?

   GOARCH="amd64"
   GOHOSTARCH="amd64"
   GOHOSTOS="darwin"
   GOOS="darwin"

3. What did you do?

   Directly use an http2.Transport to set its AllowHTTP field to true, to enable HTTP/2 over HTTP (and set DialTLS accordingly, as mentioned here: x/net/http2: support h2c for http2 #14141 (comment)).

4. What did you expect to see?

   Have access to the same rich set of configuration options as are available on http.Transport.

5. What did you see instead?

   Many configuration options from http.Transport are not available on http2.Transport (e.g. controlling idle connections in the ClientConnPool).

As discussed on golang-dev mailing list (https://groups.google.com/forum/#!topic/golang-dev/HmqDsLpTywk), as it currently stands, if we have to directly use the http2.Transport, we have to give up on a number of configuration options that are present only on http.Transport. @bradfitz suggested to rename and export the http2.Transport.t1 field to fix this.

[nathany]

👍

I'm currently pulling in x/net/http2 just to call http2.ConfigureTransport with a custom certificate for an HTTP/2 client. It would be lovely if I could cause the standard library to use HTTP/2 instead. This is the code that I currently use x/net/http2 for:

// NewClient sets up an HTTP/2 client for a certificate.
func NewClient(cert tls.Certificate) (*http.Client, error) {
    config := &tls.Config{
        Certificates: []tls.Certificate{cert},
    }
    config.BuildNameToCertificate()
    transport := &http.Transport{TLSClientConfig: config}

    if err := http2.ConfigureTransport(transport); err != nil {
        return nil, err
    }

    return &http.Client{Transport: transport}, nil
}

[bradfitz]

Nathan, how is that related to this bug?

[nathany]

Sorry @bradfitz. I thought it was related and that I may not be the only one wanting to use net/http directly for HTTP/2 even when configuration changes are necessary. Guess I misread the forum discussion.

[bradfitz]

@nathany, per #14275 and other bugs, we've decided that we're going to stay out of people's way who are doing custom things with their configuration. There's nothing wrong with importing "golang.org/x/net/http2" to wire up an abnormal configuration.

This bug is about giving more control to people who are already importing golang.org/x/net/http2.

[pwaller]

There's nothing wrong with importing "golang.org/x/net/http2" to wire up an abnormal configuration

Is this documented somewhere? After a search, your comment was the only thing I could really find that says it explicitly. https://golang.org/pkg/net/http/ says nothing about HTTP2 being disabled if you specify a TLSClientConfig. Can we get a way to enable HTTP2 and specify a TLSClientConfig without requiring the external dependency? If my request is reasonable I am happy to create a separate issue.

[quentinmit]

Since this doesn't affect http2 as used in the release, I'm moving this to the Unreleased milestone.