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.