It's surprising that grpc_cli always attempts to use the reflection
service even when providing local proto files. Document the
existence of a flag that surpresses this behavior.
The HTTP status codes are more for REST; they don't work with gRPC. We
shouldn't be encouraging them and they are confusing when you compare
them to doc/http-grpc-status-mapping.md .
Today, these clients will receive an HTTP status 200 (OK) with a trailer that
gRPC clients would be able to interpret as an error, but non-gRPC clients would
interpret as a success. In Go and Java, this will have a grpc-status of
UNKNOWN due to an unexpected content-type header. In C, the content-type
header is currently ignored, but a grpc-status of UNAVAILABLE will be returned
if a handler for that method is not registered (which is likely in this
scenario).
This change updates the gRPC HTTP/2 spec to recommend returning HTTP status 400
(Bad Request) to interoperate better with non-gRPC clients.
Note that we should not do any enforcement on user-agent, as the spec
specifically says "the protocol does not require a user-agent to function".
Although it is spelling mistakes, it might make an affects while reading.
Co-Authored-By: Nguyen Phuong An <AnNP@vn.fujitsu.com>
Signed-off-by: Kim Bao Long <longkb@vn.fujitsu.com>
statuscodes.md is one of the top search results for "grpc status codes",
right behind codes.proto. Since this is a landing page for many people*,
and since the title and description of this page purports to be the
generic status codes documentation page, it seems like a good idea to define
terms before using them.
* Many people who are new to grpc/protobuf, for example, will be more
accustomed to and choose markdown files over .proto files.