Issues related to gRPC "trailers only" responses

[jhump]

The HTTP/2 definition of a "trailers only" response (per gRPC protocol spec) has no data frames: the response is done with the single response header frame.

This must be relaxed a little for gRPC-Web, which does not require HTTP/2. In existing implementations, a "trailers only" response is one that has no body and no trailers (the headers are interpreted as trailers).

This client, on the other hand, eagerly searches for a "grpc-status" header in the response headers, and assumes it is a "trailers only" response if it is present -- even if the response includes a body or other trailers.

To better align with other implementations and to more closely align to the definition of a "trailers only" response in the gRPC spec, this client should only consider a response to be a "trailers only" response when there is no body and no trailers. If it receives a response that includes "grpc-status" in the headers, but also has a body (or any trailers), that initial status header should be ignored.

The current behavior does not typically issues in practice, but could cause incorrect interpretation of responses in misbehaving servers or in servers that inadvertently allow a (possibly malicious) user-provided payload to set extra response headers.

[jhump]

This was fixed in #274 and then released in v0.7.0.