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".
If **Timeout** is omitted a server should assume an infinite timeout. Client implementations are free to send a default minimum timeout based on their deployment requirements.
If **Timeout** is omitted a server should assume an infinite timeout. Client implementations are free to send a default minimum timeout based on their deployment requirements.
If **Content-Type** does not begin with "application/grpc", gRPC servers SHOULD respond with HTTP status of 400 (Bad Request). This will prevent other HTTP/2 clients from interpreting a gRPC error response, which uses status 200 (OK), as successful.
**Custom-Metadata** is an arbitrary set of key-value pairs defined by the application layer. Header names starting with "grpc-" but not listed here are reserved for future GRPC use and should not be used by applications as **Custom-Metadata**.
**Custom-Metadata** is an arbitrary set of key-value pairs defined by the application layer. Header names starting with "grpc-" but not listed here are reserved for future GRPC use and should not be used by applications as **Custom-Metadata**.
Note that HTTP2 does not allow arbitrary octet sequences for header values so binary header values must be encoded using Base64 as per https://tools.ietf.org/html/rfc4648#section-4. Implementations MUST accept padded and un-padded values and should emit un-padded values. Applications define binary headers by having their names end with "-bin". Runtime libraries use this suffix to detect binary headers and properly apply base64 encoding & decoding as headers are sent and received.
Note that HTTP2 does not allow arbitrary octet sequences for header values so binary header values must be encoded using Base64 as per https://tools.ietf.org/html/rfc4648#section-4. Implementations MUST accept padded and un-padded values and should emit un-padded values. Applications define binary headers by having their names end with "-bin". Runtime libraries use this suffix to detect binary headers and properly apply base64 encoding & decoding as headers are sent and received.
Doug Fawley
6 years ago