spec: should include more details on how invalid requests and responses should be handled

[jhump]

The spec describes valid requests and a valid responses, but, aside from how to handle an invalid content-type for streams or unsupported message codec for unary, it does not indicate what actions a Connect server or client should take in the face of an invalid request or response.

On the server side:

• How should a server handle a request with an unsupported method (i.e. anything but POST for most methods; anything but POST or GET for idempotent methods)?
• How should a server handle a streaming request that indicates an unsupported codec?
• It should be clarified that the response content-type for streaming calls must match the request content-type.
• How should a server handle a streaming request for a server-stream operation that has an incorrect number of request messages (!= 1)?
• How should a server handle a stream message that has the "compressed" bit set even though no compression is configured via content-encoding?

There are similar concerns with how a client should handle an invalid response.

• How should a client handle a response with an invalid content-type?
• How should a client handle an unsupported response content-encoding?
• How should a client handle a streaming response with a non-200 HTTP status code?
• How should a client handle a streaming response for a client-stream operation that has an incorrect number of request messages (!= 1)?
• How should a client handle a stream message that has the "compressed" bit set even though no compression is configured via content-encoding?

The spec should be expanded to provide more clear guidance on expected behavior in the face of these kinds of errors.

[akshayjshah]

All good points :) It'd be great for the spec to match the conformance tests on all of these points.