Open lukeo3o1 opened 1 year ago
Server.Serve
is documented as only supporting HTTP/2 on a *tls.Conn
:
HTTP/2 support is only enabled if the Listener returns *tls.Conn connections and they were configured with "h2" in the TLS Config.NextProtos.
I'm not certain we want to weaken that requirement; the server is already fairly tightly coupled to *tls.Conn
since it needs to access the ALPN negotiated protocol, and it seems plausible that we'd want to access other details of the TLS connection in the future. What's the use case for this?
@neild thanks for your reply and notice
In my use case I want to use cmux to listen to http2 and grpc services on the same port.
But this *tls.Conn
type requirement will make custom net.Conn
not work with http2 even though the underlying operation is *tls.Conn
The usual way is via grpc's ServeHTTP and treat it like any other handler
Change https://go.dev/cl/431155 mentions this issue: net/http: http2 conn serve's net.Conn type assertion supports non *tls.Conn types
Another way to do this today is to use http2.Server.ServeConn
directly, rather than relying on net/http
routing the connection to the HTTP/2 implementation.
Another way to do this today is to use
http2.Server.ServeConn
directly, rather than relying onnet/http
routing the connection to the HTTP/2 implementation.
Oh, thx! This is a great idea to me
If anyone has the same issue and usecase as me
Maybe you can try to use lukeo3o1/cmux@h2-support
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
What did you see instead?