When returning a binary stream, Socket hosting model's error handling isn't consistent with Http hosting model's

[SteveSandersonMS]

Both hosting models handle errors consistently and correctly for non-Stream responses.

But for Stream responses, if the invoked Node module throws an uncaught exception,

• The Http hosting model handles it well, behaving the same as if you invoked callback(error, null) and ends up throwing an exception back in .NET land containing the error info
• The Socket hosting model doesn't handle it well. It calls connection.end(errorInfoAsJson), but when this string gets back into .NET land, it just becomes the content of the result stream. It doesn't throw an exception like you'd expect.

This is because the Socket hosting model, when you return a binary string, just literally passes the binary data back to .NET without any encoding/prefix/suffix, so it doesn't even have a way to signal to .NET that the response for a given call should be regarded as an error. To solve this, consider adding a short prefix before the Stream-type responses that specifies whether the remaining data in the stream should be regarded as the success-case binary data, or a JSON string describing an exception to be thrown.

[SteveSandersonMS]

Since there is no plan to release the socket-based transport, this is irrelevant so I'll close it.