Deal with broken deployments

[edsko]

The spec says: Implementations should expect broken deployments to

• send non-200 HTTP status codes in responses (Deal with HTTP status codes other than 200 #197)
• as well as a variety of non-GRPC content-types (Synthesize errors for invalid content-type #205)
• and to omit Status & Status-Message. (Deal with missing trailers #206)

Implementations must synthesize a Status & Status-Message to propagate to the application layer when this occurs.

Note that the spec specifically states this about dealing with responses (i.e., client-side). Indeed, for dealing with requests (server-side) the spec has different requirements; for example, a missing content-type header should result in a HTTP 415 status.

Additionally:

• When decoding invalid values implementations MUST NOT error or throw away the message. (Test that we can access values of invalid headers #208)

At worst, the implementation can abort decoding the status message altogether such that the user would received the raw percent-encoded form. Alternatively, the implementation can decode valid portions while leaving broken %-encodings as-is or replacing them with a replacement character (e.g., '?' or the Unicode replacement character).

We don't do this yet.

[domenkozar]

I get the following back:

 SomeExceptionWrapper (STMException [("atomically",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Util.Thread", srcLocFile = "src/Network/GRPC/Util/Thread.hs", srcLocStartLine = 203, srcLocStartCol = 7, srcLocEndLine = 203, srcLocEndCol = 17}),("withThreadInterface",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Util.Session.Channel", srcLocFile = "src/Network/GRPC/Util/Session/Channel.hs", srcLocStartLine = 339, srcLocStartCol = 5, srcLocEndLine = 339, srcLocEndCol = 24}),("recv",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Client.Call", srcLocFile = "src/Network/GRPC/Client/Call.hs", srcLocStartLine = 131, srcLocStartCol = 32, srcLocEndLine = 131, srcLocEndCol = 44})] (SomeExceptionWrapper (ThreadInterfaceUnavailable {threadInterfaceCallStack = [("withThreadInterface",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Util.Session.Channel", srcLocFile = "src/Network/GRPC/Util/Session/Channel.hs", srcLocStartLine = 339, srcLocStartCol = 5, srcLocEndLine = 339, srcLocEndCol = 24}),("recv",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Client.Call", srcLocFile = "src/Network/GRPC/Client/Call.hs", srcLocStartLine = 131, srcLocStartCol = 32, srcLocEndLine = 131, srcLocEndCol = 44})], threadInterfaceException = ResponseInvalidStatus (Status {statusCode = 404, statusMessage = "Not Found"})})))

It would be great if the response and request were included to be able to understand what's happening.

[edsko]

This issue is not about connectivity issues, but about non-compliant gRPC implementations that use HTTP error codes instead of gRPC error codes to indicate problems (gRPC problems are meant to be indicated with a HTTP error of 200 and then a non-zero grpc-status). The 404/not found in your message suggests it's not able to connect to the remote server at all? Not sure what kind of request/response you're hoping to see; in particular, request, response in gRPC terms (the messages sent to and from the server) have not yet happened at the connecting stage.

[edsko]

In response to @domenkozar 's comment above: as I mentioned previously, grapesy now includes the full response body in case of server errors. As of #197, a 404 Not Found from the server will now result in a GrpcUnimplemented exception; I have added a test in #207 to ensure that we still include the response body in this gRPC exception.

[edsko]

All aspects of this ticket I think are now working and tested. Also verified that the few changes we made did not break the interop tests. Closing!