None of the actual client implementations require that the Connect RPC code and the HTTP code are aligned (which is actually good since it allowed us to improve the mappings (#130) without it being a breaking change in practice).
This updates the language in the spec to make it a little more clear that a client should not necessarily treat it as an error if the Connect RPC code and HTTP status code do not agree. Admittedly, this is a rather subtle single word change. We could be even more explicit about what clients should do. But I think that might be better saved for a future document that provides a more behavior-focused spec (vs. protocol/wire-format-focused), which can also include guidance and requirements about other things that are today only codified in conformance test expectations.
None of the actual client implementations require that the Connect RPC code and the HTTP code are aligned (which is actually good since it allowed us to improve the mappings (#130) without it being a breaking change in practice).
This updates the language in the spec to make it a little more clear that a client should not necessarily treat it as an error if the Connect RPC code and HTTP status code do not agree. Admittedly, this is a rather subtle single word change. We could be even more explicit about what clients should do. But I think that might be better saved for a future document that provides a more behavior-focused spec (vs. protocol/wire-format-focused), which can also include guidance and requirements about other things that are today only codified in conformance test expectations.