This largely undoes a recent change to do more validation of trailers-only responses (#685), which disallows a body or trailers in what appeared to be a trailers-only response. In that change, a trailers-only response was identified by the presence of a "grpc-status" key in the headers.
In this PR, a trailers-only response is instead defined by the lack of body and trailers (not the presence of a "grpc-status" header). This PR also tweaks some other error scenarios:
If trailers (or an end-stream message) is completely missing from a response, it's considered an internal error. But if trailers are present, but the "grpc-status" key is missing, it's considered an issue determining the status, which is an unknown error.
Similarly, if a response content-type doesn't appear to be the right protocol (like it may have come from a non-RPC server), the error code is now unknown. But if it looks like the right protocol but uses the wrong sub-format/codec, it's an internal error.
Note that in grpc-go, this behavior is also seen in the client, but this PR doesn't attempt to address that in the connect-go client. Instead, that change can be made when #689 is addressed.
This PR also now makes connect-go more strict about the "compressed" flag in a streaming protocol when there was no compression algorithm negotiated. Previously, this library was lenient and did not consider it an error if the message in question was empty (zero bytes). But to correctly adhere to gRPC semantics, it MUST report this case as an internalerror (see bullet 6 in the test cases section of the gRPC compression docs).
This largely undoes a recent change to do more validation of trailers-only responses (#685), which disallows a body or trailers in what appeared to be a trailers-only response. In that change, a trailers-only response was identified by the presence of a "grpc-status" key in the headers.
In this PR, a trailers-only response is instead defined by the lack of body and trailers (not the presence of a "grpc-status" header). This PR also tweaks some other error scenarios:
internalerror. But if trailers are present, but the "grpc-status" key is missing, it's considered an issue determining the status, which is anunknownerror.unknown. But if it looks like the right protocol but uses the wrong sub-format/codec, it's aninternalerror.This PR also now makes connect-go more strict about the "compressed" flag in a streaming protocol when there was no compression algorithm negotiated. Previously, this library was lenient and did not consider it an error if the message in question was empty (zero bytes). But to correctly adhere to gRPC semantics, it MUST report this case as an
internalerror (see bullet 6 in the test cases section of the gRPC compression docs).