Hey folks!

The Go net/http library of course now supports HTTP2, and the library expects HTTP2 protocol negotiation to happen as part of the TLS handshake. This is great and fine and good and to be encouraged, yay encrypting everything.

One of the interesting challenges with the Go implementation is that this negotiation happens under the covers, and is an internal detail to the library, away from programmer control. I do agree that's also probably a good default.

Unfortunately, this means that there isn't a way to do the negotiation for HTTP2 using a different crypto stack (or a different transport type entirely). I'm sure the Go developers don't feel awesome about the cgo-using https://github.com/spacemonkeygo/openssl, but the current situation is that it's faster, supports more hardware accelerated encryption, and people use it. I'd love to fix all of those issues, but even if they were fixed, I still think it's useful to support an ecosystem of crypto libraries, instead of just the one, albeit excellent, crypto/tls.

We're interested in using HTTP2 except with our own initial negotiation (whether or not it's our OpenSSL bindings). It currently looks like the only options to do our own HTTP2 protocol negotiation (instead of using crypto/tls) are to fork net/http to add the following 3 lines of code, or to write our own implementation of HTTP2:

// I FEEL SO BAD ABOUT THIS FORK
type HTTP2Transport struct {
    http2Transport
}

Obviously I'd prefer a s/http2Transport/HTTP2Transport/g over this struct addition.

I realize asking for a type to be exported adds a burdensome support requirement for future library releases wrt backwards compatibility guarantees, but this makes all of the HTTP2 protocol infrastructure vastly more usable and reusable.

What are the chances of this happening?