Re: [grpc-io] Rational behind mapping HTTP 429 to gRPC UNAVAILABLE

In the responses section of that protocol doc ( https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#responses), the "HTTP-Status" production is exactly the string ":status 200". This explicitly means that gRPC servers must always return a HTTP status code of 200 in any gRPC response. On

Re: [grpc-io] Rational behind mapping HTTP 429 to gRPC UNAVAILABLE

> gRPC (currently) always uses 200 for RPC errors I wanted to confirm that servers should return a 200 HTTP status code regardless of gRPC status. I believe this is the case but I didn't find https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md to be explicit about it. On Monday, Oct

Re: [grpc-io] Rational behind mapping HTTP 429 to gRPC UNAVAILABLE

google/rpc/code.proto has the HTTP mappings. Those are REST-centric and are for converting *to* HTTP status code. Multiple of them are obviously wrong for gRPC (e.g., NOT_FOUND→404) and multiple of them are... weak... mapp

[grpc-io] Rational behind mapping HTTP 429 to gRPC UNAVAILABLE

Hi, According to http-grpc-status-mapping.md , HTTP 429 Too Many Requests is translated into gRPC UNAVAILABLE rather than RESOURCE_EXHAUSTED. However, at some point in the past, statuscodes.md