document what the server's ServeHTTP is missing compared to the Serve method

[nhooyr]

https://godoc.org/google.golang.org/grpc#Server.ServeHTTP

Note that ServeHTTP uses Go's HTTP/2 server implementation which is totally separate from grpc-go's HTTP/2 server. Performance and features may vary between the two paths. ServeHTTP does not support some gRPC features available through grpc-go's HTTP/2 server, and it is currently EXPERIMENTAL and subject to change.

What precisely are the differences?

[dfawley]

There are a number of differences; too many to document in the godoc comment. Here are the ones I can think of right now:

• Keepalive pings and server enforcement of client keepalive pings
• Max idleness detection
• Connection-level stats handlers
• InTapHandle (called before handling a new stream to potentially kill it before allocating any resources for it)

In addition, it is not a feature actively maintained by the grpc-go team; I would avoid using it.

[ronnylt]

In addition, it is not a feature actively maintained by the grpc-go team; I would avoid using it.

@dfawley is there any other way of sharing the same port (such as 443 for https) between gRPC and an existing http.Handler?

I would like to follow your advice of avoid using it, mainly if it's a feature actively maintained by the grpc-go team.

Thanks

[dfawley]

You could use something like cmux for server-side port sharing. This will delegate the whole Conn over to gRPC after the headers are sent by the client, and then go through the grpc-go HTTP/2 transport. (Note that you will need the "workaround" for Java since grpc-go v1.18 [ref] and PR to update their docs.)