If I create a Listener with tls.Listen() it just silently blocks or rejects gRPC requests, whether I connect the Listener directly to my gRPC service or use it as the main Listener for cmux. I've reported it: grpc/grpc-go#7313, but I think there's also a problem with cmux, which makes it more serious.
I can pass a Listener created by net.Listen to gRPC, using grpc's ServerOptions to handle the TLS. I can also use that Listener as the input to cmux and pass a cmux matching Listener to gRPC, but it's not much use, because none of the matchers (except Any()) work in this case. I know most of them wouldn't be expected to, because they can't see inside the encrypted part of the request, but ChatGPT claimed that HTTP2() and HTTP1Fast() should be able to perform matching at the very start of the request, before TLS handshaking. Maybe it's just wrong.
Using HTTP2() and HTTP1Fast() would be a less than ideal work-around anyway, because one day gRPC might not be the only HTTP2 service trying to share a cmux. Would it be possible to have cmux accept TLS credentials so that all the matchers can access the info they need even when the incoming request is unaltered TLS?
If I create a
Listener
withtls.Listen()
it just silently blocks or rejects gRPC requests, whether I connect the Listener directly to my gRPC service or use it as the main Listener for cmux. I've reported it: grpc/grpc-go#7313, but I think there's also a problem with cmux, which makes it more serious.I can pass a Listener created by
net.Listen
to gRPC, using grpc'sServerOption
s to handle the TLS. I can also use that Listener as the input to cmux and pass a cmux matching Listener to gRPC, but it's not much use, because none of the matchers (exceptAny()
) work in this case. I know most of them wouldn't be expected to, because they can't see inside the encrypted part of the request, but ChatGPT claimed thatHTTP2()
andHTTP1Fast()
should be able to perform matching at the very start of the request, before TLS handshaking. Maybe it's just wrong.Using
HTTP2()
andHTTP1Fast()
would be a less than ideal work-around anyway, because one day gRPC might not be the only HTTP2 service trying to share a cmux. Would it be possible to have cmux accept TLS credentials so that all the matchers can access the info they need even when the incoming request is unaltered TLS?