Summary
#200 added strict protocol- and codec-aware content-type validation for gRPC and gRPC-Web unary responses (shared with the client-streaming response parse path), but make_server_stream — used by both call_server_stream and BidiStream — performs no response content-type validation at all.
Why
The exact misroute #200 exists to catch (a gRPC client answered with gRPC-Web framing, or a proto client answered with +json) fails clearly on a unary call (internal / unknown with the expected type named in the message) but on a streaming call still surfaces as envelope-parse garbage, a confusing decode error, or a hung trailer wait. A consumer debugging a streaming endpoint gets the worse diagnostic for the same misconfiguration.
Proposed fix
Reuse validate_grpc_response_content_type from the gRPC/gRPC-Web arms of make_server_stream (connectrpc/src/client/mod.rs). The helper is already protocol-parameterized and Protocol::response_content_type ignores is_streaming for the gRPC family, so it applies as-is; the Connect streaming arm could get an equivalent strict check against application/connect+{codec} as a follow-on decision.
While here, consider the related Connect-side gap noted in the #200 review: the Connect unary path keeps the old lenient starts_with check and does not attach the response headers to its content-type error.
Notes
Surfaced by both review passes on #200. Conformance suites do not currently pin these streaming cases, so this needs unit coverage like the #200 helper tests.
Summary
#200 added strict protocol- and codec-aware
content-typevalidation for gRPC and gRPC-Web unary responses (shared with the client-streaming response parse path), butmake_server_stream— used by bothcall_server_streamandBidiStream— performs no response content-type validation at all.Why
The exact misroute #200 exists to catch (a gRPC client answered with gRPC-Web framing, or a proto client answered with
+json) fails clearly on a unary call (internal/unknownwith the expected type named in the message) but on a streaming call still surfaces as envelope-parse garbage, a confusing decode error, or a hung trailer wait. A consumer debugging a streaming endpoint gets the worse diagnostic for the same misconfiguration.Proposed fix
Reuse
validate_grpc_response_content_typefrom the gRPC/gRPC-Web arms ofmake_server_stream(connectrpc/src/client/mod.rs). The helper is already protocol-parameterized andProtocol::response_content_typeignoresis_streamingfor the gRPC family, so it applies as-is; the Connect streaming arm could get an equivalent strict check againstapplication/connect+{codec}as a follow-on decision.While here, consider the related Connect-side gap noted in the #200 review: the Connect unary path keeps the old lenient
starts_withcheck and does not attach the response headers to its content-type error.Notes
Surfaced by both review passes on #200. Conformance suites do not currently pin these streaming cases, so this needs unit coverage like the #200 helper tests.