So that you inform reverse proxy servers to use it for routing.
Tested with nginx/1.13.12, which is the latest release of nginx as of today.
Usage: `grpcurl --authority example.com localhost`
See https://github.com/grpc/grpc-go/pull/1064 for the PR to grpc-go which enabled this feature.
See https://tools.ietf.org/html/rfc7540#section-8.1.2.3 and https://tools.ietf.org/html/rfc3986#section-3.2 for what is a valid :authority header value.
Note that `grpcurl -H ':authority: example.com' localhost` doesn't work in two ways.
One is that the current implementation of grpcurl splits `:authority: example.com` to `[]string{"", "authority: example}` and considers it as a header with an empty key and a value of "authority: example.com" which isn't valid.
Another one is that `-H` passes request metadata, whereas `:authority` header must be provided at connection time.
* add more control over request metadata between reflection calls and main RPC invocation
* add flag to print a message template (when describing message types)
* relax some command-line argument issues to warnings
I have not been able to figure out the severe flakiness in Go 1.6. And I'm tired of digging for it. Go 1.6 is two years old now, so I suppose it's not valuable to support it. (I had added to the matrix originally just to match the actual grpc-go project, which also supports Go 1.6.)
It's always the same issue: `TestPlainText` in `tls_settings_test.go`. And the behavior appears to be as if the server keeps closing the connection. But it doesn't plague any other test case, which is very mysterious. It's as if the server were configured for TLS and closes the connection when it sees the HTTP/2 preface (which doesn't look like a TLS handshake). But I just don't see how that could be possible, so it must be something else going awry.
Yusuke KUOKA