gRPCurl functionality to support HTTP/3 (QUIC), as the underlying transport mechanism.

[larspaulsen]

trafficstars

If a given system uses the newly support HTTP/3 channel configuration then gRPCurl's current TCP only implementation can not provide any usefulness.

The solution is for gRPCurl's gRPC functionality to support HTTP/3 (QUIC), as the underlying transport mechanism.

Alternatives: None.

What is HTTP/3 and why is support important? https://devblogs.microsoft.com/dotnet/http-3-support-in-dotnet-6/#what-is-http-3-and-why-is-support-important

gRPC with HTTP/3 https://devblogs.microsoft.com/dotnet/http-3-support-in-dotnet-6/#grpc-with-http-3

Github: grpc/grpc grpc/grpc#19126 grpc/proposal#256 https://github.com/JamesNK/proposal/blob/jamesnk/http3/G2-http3-protocol.md

[jhump]

@larspaulsen, I would file in issue at https://github.com/grpc/grpc-go. There is no intent to write a gRPC-over-HTTP/3 implementation in this repo that is bespoke to grpcurl -- we rely on the standard gRPC runtime for a reason.

If a given system uses the newly support HTTP/3 channel configuration then gRPCurl's current TCP only implementation can not provide any usefulness.

This doesn't seem correct. I suspect it is unlikely that gRPC server runtimes would not support both. While the linked proposal does indicate a mode where the client can require HTTP/3 up-front, the typical flow in the proposal is that the first request is HTTP/2 and that the server sends a special response telling the client to upgrade to HTTP/3 (via an Alt-Svc header). That means that servers will often support both protocols. So the TCP-only implementation is certainly still useful, until such time as the underlying gRPC library supports HTTP/3.