The Connect Unexpected Requests suite has an unexpected-compression case for unary requests, and the gRPC and gRPC-Web suites have one each, but no case sends a Connect streaming request with an unsupported connect-content-encoding. In the gRPC and gRPC-Web suites, the unary cases exercise the same framing and grpc-encoding header that streams use. Connect unary and streaming requests use different headers and framing, so the Connect suite only covers the unary side.
A server that treats an unknown encoding as identity passes the current suites: it answers internal once it sees a compressed message, and handles an uncompressed one as usual. connect-py did this; connectrpc/connect-py#365 fixes it.
I have the case on a branch: main...i2y:conformance:i2y/unexpected-stream-compression
Case
A server-stream request in the Connect suite, next to the unary unexpected-compression case:
server-stream/unexpected-compression: connect-content-encoding: foo with one zstd-compressed message, expecting CODE_UNIMPLEMENTED.
connect-go and connect-es both return unimplemented here, since they negotiate request compression the same way for every protocol, and the spec asks servers to handle connect-content-encoding with the same error-reporting rules as content-encoding.
I left out an empty connect-content-encoding, since implementations differ there: connect-go treats it as identity, while connect-es rejects it.
Results on the branch
Related: #1142, which covers compressed messages with corrupt contents; this one covers an encoding the server doesn't support.
Happy to open a PR from the branch if this looks right!
The Connect Unexpected Requests suite has an
unexpected-compressioncase for unary requests, and the gRPC and gRPC-Web suites have one each, but no case sends a Connect streaming request with an unsupportedconnect-content-encoding. In the gRPC and gRPC-Web suites, the unary cases exercise the same framing andgrpc-encodingheader that streams use. Connect unary and streaming requests use different headers and framing, so the Connect suite only covers the unary side.A server that treats an unknown encoding as identity passes the current suites: it answers
internalonce it sees a compressed message, and handles an uncompressed one as usual. connect-py did this; connectrpc/connect-py#365 fixes it.I have the case on a branch: main...i2y:conformance:i2y/unexpected-stream-compression
Case
A server-stream request in the Connect suite, next to the unary
unexpected-compressioncase:server-stream/unexpected-compression:connect-content-encoding: foowith one zstd-compressed message, expectingCODE_UNIMPLEMENTED.connect-go and connect-es both return
unimplementedhere, since they negotiate request compression the same way for every protocol, and the spec asks servers to handleconnect-content-encodingwith the same error-reporting rules ascontent-encoding.I left out an empty
connect-content-encoding, since implementations differ there: connect-go treats it as identity, while connect-es rejects it.Results on the branch
internal("sent compressed message without compression support"), on both its sync and async servers.Related: #1142, which covers compressed messages with corrupt contents; this one covers an encoding the server doesn't support.
Happy to open a PR from the branch if this looks right!