The client implementation only examines the response "content-type" header for the Connect unary protocol for non-200 HTTP status codes, to make sure it is "application/json". For other scenarios, it does not check that response header and will instead assume the content-type is correct begin consuming the response body.
This can lead to hard-to-debug errors with unexpected codes when the actual content is not parse-able per the expected message codec. In the worst case, it could possibly result in no error, if the content just happens to be parse-able. In that case, the response message is certain to be incorrect/invalid but it would be provided to application code without an error anyway.
The client implementation only examines the response "content-type" header for the Connect unary protocol for non-200 HTTP status codes, to make sure it is "application/json". For other scenarios, it does not check that response header and will instead assume the content-type is correct begin consuming the response body.
This can lead to hard-to-debug errors with unexpected codes when the actual content is not parse-able per the expected message codec. In the worst case, it could possibly result in no error, if the content just happens to be parse-able. In that case, the response message is certain to be incorrect/invalid but it would be provided to application code without an error anyway.
Found by conformance tests in v1.14.0.