client must not attempt decode responses with wrong content type

[stepancheg]

Bug Report

When non-gRPC error is returned, for example 502 bad gateway by a proxy server, tonic client returns an error like

status: Internal, message: "protocol error: received message with invalid compression flag: 60 (valid flags are 0 and 1) while receiving response with status: 502 Bad Gateway", details: [], metadata: MetadataMap { headers: {"date": "Fri, 01 Aug 2025 02:23:45 GMT", "content-type": "text/html", "content-length": "150", "strict-transport-security": "max-age=31536000; includeSubDomains"} }

Content-type is not application/grpc, so attempt to read first byte as either 0 or 1 for compression is incorrect.

Version

0.13

Error comes from here:

tonic/tonic/src/codec/decode.rs

Line 176 in 87d2d4c

"protocol error: received message with invalid compression flag: {f} (valid flags are 0 and 1) while receiving response with status: {status}"

[LucioFranco]

@dfawley I assume the current implementation is incorrect, do you have an idea of what grpc-go does in this case?

[dfawley]

When the headers indicate the wrong content-type encoding, the stream will be closed immediately (with a RST_STREAM if the server didn't already include an END_STREAM on its headers frame). Locally, the application will see an INTERNAL error code, unless the HTTP status was not 200, in which case we'll do that conversion instead:

https://github.com/grpc/grpc-go/blob/85240a5b02defe7b653ccba66866b4370c982b6a/internal/transport/http2_client.go#L1481-L1485

https://github.com/grpc/grpc-go/blob/85240a5b02defe7b653ccba66866b4370c982b6a/internal/transport/http2_client.go#L1551-L1556

Apparently Go isn't handling 1xx statuses in HEADERS frames correctly (unless the framer we're using hides them, which I would doubt). I believe we'll error instead of ignoring them. (grpc/grpc-go#8485)

Also, apparently Java has some interesting logic to help users with debugging in this case. It will read data frames (if the headers don't include END_STREAM) up to 1kb, and includes that in the status message. (grpc/grpc-go#8487)

And lastly, per @ejona86, if the content-type is grpc, then we should not be inspecting the status, which Go is also doing incorrectly. (grpc/grpc-go#8486)

EDIT: added issue links for all the problems I found with gRPC-Go.