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.
* Expose the C-Core API in Cython layer
* Handle the object translation
* Create a separate package for Channelz specifically
* Handle nullptr and raise exception if seen one
* Translate C++ Channelz unit tests
* Adding 5 more invalid query unit tests
Adding peripheral utility for grpcio-channelz package
* Add to `pylint_code.sh`
* Add to Python build script
* Add to artifact build script
* Add to Bazel
* Add to Sphinx module list
* Use templates instead of generating them every time
* Theme changed
* Add grpc_* modules
* APIs grouped
* No documentation for class members without docstring
* Add docstring for status code