You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the gRPC docs for compression, when a server sends a response using an unrecognized/unsupported encoding the client MUST report the error with an "internal" error code. (See bullet 5 in the test cases section of that doc.)
The reverse case (client sends a request using an encoding not supported by the server) on the other hand must use an "unimplemented" error.
In grpc-go, both of the above situations result in an "unimplemented" error. Receiving messages in both the client and server runs through the checkRecvPayload function in rpc_util.go which always returns "unimplemented". It should instead have a condition so that it returns "internal" when called from a client.
The text was updated successfully, but these errors were encountered:
That [your assessment of the bug] sounds right to me. If the client uses UNIMPLEMENTED in this case, it could be confused with the method not being implemented on the server.
According to the gRPC docs for compression, when a server sends a response using an unrecognized/unsupported encoding the client MUST report the error with an "internal" error code. (See bullet 5 in the test cases section of that doc.)
The reverse case (client sends a request using an encoding not supported by the server) on the other hand must use an "unimplemented" error.
In grpc-go, both of the above situations result in an "unimplemented" error. Receiving messages in both the client and server runs through the
checkRecvPayload
function inrpc_util.go
which always returns "unimplemented". It should instead have a condition so that it returns "internal" when called from a client.The text was updated successfully, but these errors were encountered: