gRPC reimplemented http2 because they had to. We started with the same http2.Framer code and they wrote their gRPC-specific http2 client & server in parallel with me writing net/http's http2 client and server. I'm currently working on unifying them (see grpc/grpc-go#75).

I might accept h2c as a separate package under x/net/http2, but it won't be part of the Go standard library or on by default. Some of the work was already done as part of golang/net@d62542d

@bradfitz thanks.

gRPC reimplemented http2 because they had to

My thought is that eventually, another framework like gRPC should not have to reimplement http2 because the standard (or at least x/net) package would support all valid protocol use-cases. I realise gRPC came before your implementation so it was not an option there, but long term it seems bad that anyone else (like me) who wants to use HTTP/2 for inter-service communication (according to spec) has to reinvent the wheel despite "HTTP/2" implementation existing in standard lib.

To be clear, for my use-case I'm mostly interested in inter-service communication where I assume I control both client and server, so I really want HTTP/2 over TCP with "prior knowledge" (section 3.4) rather than HTTP/1.1 Upgrade.

But I think it makes sense that there is at least a somewhat official library (even if it stays in x) that supports the whole spec.

I looked at the old PR for upgrade support which seems a little hairy in the way it integrates with http server - I can see it's not a simple request to support.

I might accept h2c as a separate package under x/net/http2, but it won't be part of the Go standard library

Fair enough. Can I ask how the two interact? I'm using 1.6rc which uses http2 automatically when serving TLS via net/http (standard library) but the http2 implementation appears to still be this one in x/net. Do you consider http2 to be "standard library" due to its integration with net/http even though the implementation is still in x/net and still has TODO items on public interface or did I misunderstand something (like a subset got copied over)?

I will take a look through the commit you linked and get a better idea what the options are in terms of optional h2c upgrade and/or prior knowledge support with net/http.

Thanks again for your help.

Hmm I see your linked commit is against net/http2 not x/net/http2 implying it does exist in standard library, but if I run godoc on my local 1.6rc http2 is still in x in the Release Candidate despite being integrated with net/http.

We vendor a copy of x/net/http2 into net/http so http2 can be automatic for the standard library. What I mean is that I will not enable h2c automatically for the standard library, but h2c work can happen in a subpackage of x/net, like x/net/http2/h2c.

Thanks Brad, that's clear now.

On 29 Jan 2016, at 18:03, Brad Fitzpatrick notifications@github.com wrote:

We vendor a copy of x/net/http2 into net/http so http2 can be automatic for the standard library. What I mean is that I will not enable h2c automatically for the standard library, but h2c work can happen in a subpackage of x/net, like x/net/http2/h2c.

—
Reply to this email directly or view it on GitHub.

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

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

Sorry to bother, but i found it's quite easy to make a h2c client with a little modification to golang.org/x/net/http2

package main

import (
    "crypto/tls"
    "fmt"
    "io/ioutil"
    "log"
    "net"
    "net/http"

    "golang.org/x/net/http2"
)

func main() {
    client := http.Client{
        // Skip TLS dial
        Transport: &http2.Transport{
            DialTLS: func(netw, addr string, cfg *tls.Config) (net.Conn, error) {
                return net.Dial(netw, addr)
            },
        },
    }

    resp, err := client.Get("http://localhost:8080/test")
    if err != nil {
        log.Fatal(err)
        return
    }

    fmt.Printf("resp: %#v\n", resp)

    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        log.Fatal(err)
        return
    }

    fmt.Println(string(body))
}

then remove the restriction from golang.org/x/net/http2/transport.go in func (t *Transport) RoundTripOpt(req *http.Request, opt RoundTripOpt) (*http.Response, error)

    //if req.URL.Scheme != "https" {
    //  return nil, errors.New("http2: unsupported scheme")
    //}

I agree that nearly all browsers will not support h2c, but there are some h2c server serving traffic as another RPC service (not gRPC), so can https restriction be loosen a little to support h2c client?

I'd be fine with an http2.Transport.AllowHTTPScheme bool knob.

@bradfitz I'd be fine wth the knob too. So, will it be shipped?

If somebody sends me a change.

@bradfitz It seems golang.org/x/net/http2 not hosted on github?

Here is a diff. Since http port is not 443, i add some if-else to use 80

diff --git a/http2/configure_transport.go b/http2/configure_transport.go
index daa17f5..dde578a 100644
--- a/http2/configure_transport.go
+++ b/http2/configure_transport.go
@@ -32,7 +32,7 @@ func configureTransport(t1 *http.Transport) (*Transport, error) {
        t1.TLSClientConfig.NextProtos = append(t1.TLSClientConfig.NextProtos, "http/1.1")
    }
    upgradeFn := func(authority string, c *tls.Conn) http.RoundTripper {
-       addr := authorityAddr(authority)
+       addr := authorityAddr(authority, "https")
        if used, err := connPool.addConnIfNeeded(addr, t2, c); err != nil {
            go c.Close()
            return erringRoundTripper{err}
diff --git a/http2/transport.go b/http2/transport.go
index a7ada8f..a9f24dd 100644
--- a/http2/transport.go
+++ b/http2/transport.go
@@ -75,6 +75,9 @@ type Transport struct {
    // explicitly requested gzip it is not automatically
    // uncompressed.
    DisableCompression bool
+   
+   // Allow plain text HTTP/2
+   AllowHTTPScheme bool

    // MaxHeaderListSize is the http2 SETTINGS_MAX_HEADER_LIST_SIZE to
    // send in the initial settings frame. It is how many bytes
@@ -268,20 +271,27 @@ func (t *Transport) RoundTrip(req *http.Request) (*http.Response, error) {

 // authorityAddr returns a given authority (a host/IP, or host:port / ip:port)
 // and returns a host:port. The port 443 is added if needed.
-func authorityAddr(authority string) (addr string) {
+func authorityAddr(authority string, scheme string) (addr string) {
    if _, _, err := net.SplitHostPort(authority); err == nil {
        return authority
    }
-   return net.JoinHostPort(authority, "443")
+   var defaultPort string
+   if scheme == "http" {
+       defaultPort = "80"
+   } else {
+       defaultPort = "443"
+   }
+   return net.JoinHostPort(authority, defaultPort)
 }

 // RoundTripOpt is like RoundTrip, but takes options.
 func (t *Transport) RoundTripOpt(req *http.Request, opt RoundTripOpt) (*http.Response, error) {
-   if req.URL.Scheme != "https" {
+   if !(req.URL.Scheme == "https" || (req.URL.Scheme == "http" && t.AllowHTTPScheme)) {
        return nil, errors.New("http2: unsupported scheme")
    }

-   addr := authorityAddr(req.URL.Host)
+    
+   addr := authorityAddr(req.URL.Host, req.URL.Scheme)
    for {
        cc, err := t.connPool().GetClientConn(req, addr)
        if err != nil {

@ayanamist, we don't accept patches on Github or in comments. See https://golang.org/doc/contribute.html#Code_review

That is a wall of text, but there's only like 3 real steps there.

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

Since CL https://golang.org/cl/23181 was merged, what is the correct way to configure the server side for this?

Given this server:

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"

    "golang.org/x/net/http2"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Println(r)
    io.WriteString(w, "hello\n")
}

func main() {
    s := &http.Server{
        Addr:    ":8543",
        Handler: http.HandlerFunc(handler),
    }
    http2.ConfigureServer(s, &http2.Server{})
    log.Fatal(s.ListenAndServe())
}

And this client:

package main

import (
    "crypto/tls"
    "fmt"
    "log"
    "net"
    "net/http"

    "golang.org/x/net/http2"
)

func main() {
    client := http.Client{
        // Skip TLS dial
        Transport: &http2.Transport{
            AllowHTTP: true,
            DialTLS: func(network, addr string, cfg *tls.Config) (net.Conn, error) {
                return net.Dial(network, addr)
            },
        },
    }

    resp, err := client.Get("http://localhost:8543")
    if err != nil {
        log.Fatal(fmt.Errorf("error making request: %v", err))
    }
    fmt.Println(resp.StatusCode)
    fmt.Println(resp.Proto)
}

When the client makes a request, the output is:

$ go run client/main.go
2016/08/24 22:31:07 error making request: Get http://localhost:8543: unexpected EOF
exit status 1

And the server output from the handler is:

$ go run server/main.go
&{PRI * HTTP/2.0 2 0 map[] 0x3bd4e0 -1 [] true  map[] map[] <nil> map[] [::1]:63792 * <nil> <nil> <nil> 0xc4200744c0}

If I switch the server to use http2.Server.ServeConn directly, like in the tests in the above CL, it works as expected.

I believe this is due to how http2 is implemented in the standard library: https://github.com/golang/go/blob/release-branch.go1.7/src/net/http/server.go#L1500:L1520

HTTP2 dispatch is implemented in net/http.Server just like any other ALPN-based dispatch, which means it only works with TLS connections (ALPN is part of the TLS spec).

It would take some additional non-ALPN logic to make h2c work the way you describe, and to my understanding @bradfitz has indicated that such additional logic will not be accepted.

I've already accepted a ton of logic for h2c. My policy has been and remains: it should be possible for people to do h2c via a separate package, but it won't be supported by default.

All the pieces should be there now for you to glue it together yourself.

For server-side support you'll need to hijack in the PRI * HTTP/2.0 Handler and then call http2.Server.ServerConn.

Somebody should make a package to make that easier. I have other priorities, but can review CLs.

Somebody should make a package to make that easier. I have other priorities, but can review CLs.

Awesome, thanks @bradfitz. Would the Go team accept a CL to add h2c support, if it was opt-in (e.g. an AllowH2C flag on Server)?

I'd imagine a lot of people writing backend services are pretty excited about the performance advantages of http/2, but would rather terminate TLS at a load balancer.

Thanks for all your hard work on http/2 thus far!

Awesome, thanks @bradfitz. Would the Go team accept a CL to add h2c support, if it was opt-in (e.g. an AllowH2C flag on Server)?

I'd prefer it to be in its own package, hidden away and very much opt-in.

@ejholmes it's been a few months, any update on getting h2c to work with http.Server? I think it'd be very useful to have plain http2 as an option for testing and backend services. Thanks

To save others some time, @hkwi wrote an implementation here: https://github.com/hkwi/h2c

I'm pretty far in getting this done. I expect I will be able submit a PR this weekend.

Change https://golang.org/cl/112997 mentions this issue: Add implementation of h2c into x/net/http2/h2c.

Change https://golang.org/cl/112999 mentions this issue: http2/h2c: Implementation of http2 h2c.

I too wanted h2c for traffic between load balancers that were doing SSL Termination and my golang servers.

I adapted the h2c implementation in Traefik into a standalone http.Handler: https://github.com/veqryn/h2c

package main

import (
	"fmt"
	"net/http"

	"github.com/veqryn/h2c"
	"golang.org/x/net/http2"
)

func main() {

	// Router/Mux (can use any http.Handler)
	router := http.NewServeMux()

	// Handlers...
	router.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprint(w, "Hello World")
	})

	// Wrap the Router
	h2cWrapper := &h2c.HandlerH2C{
		Handler:  router,
		H2Server: &http2.Server{},
	}

	// Server
	srv := http.Server{
		Addr:    ":8080",
		Handler: h2cWrapper,
	}

	srv.ListenAndServe()
}

I'm happy to see that there is now an h2c package in golang.org/x/net/http2/h2c! I would like to add a random data point however that there are legitimate use cases for h2c. In our case, when proxying gRPC through a local Envoy sidecar over a unix socket protected with filesystem permissions. For reasons like that having it in the standard library might be nice, but of course should not be a default. The existing conclusion also is reasonable.

I would like to say THANK YOU @misterwilliam (and @bradfitz for reviewing), fantastic job.