if http_proxy server plugin experiences an err related to its function (not a mixnet-related error), then write the error message as a response for the client. Currently it is returned as an error, and client doesn't consume it, only times out.
Pursue elimination of unnecessary client-side timeouts, when an error has occurred. In some cases, this can be a mis-configuration from the client (like unsupported/incorrect URL for RPC endpoint). Fail faster for better UX, and return an informative error message to the client.
Notes
Send all the useful things (for the client) in the response.
This will require changes on both server and client side, to send the error message as a response to the client.
Differentiate between errors related to the mix network and those related to the app protocol (http_proxy + walletshield) as well as which of those errors are useful for the walletshield client.
Consider what is useful from client (human operator) perspective in terms of error message wording.
Examples of errors that may be useful for the client
validateRequestURL failed
URI not matched with config Networks
http.DefaultClient.Do failed
http response is too big
Example for writing response to client (vs returning Error)
following #17
if http_proxy server plugin experiences an err related to its function (not a mixnet-related error), then write the error message as a response for the client. Currently it is returned as an error, and client doesn't consume it, only times out.
Pursue elimination of unnecessary client-side timeouts, when an error has occurred. In some cases, this can be a mis-configuration from the client (like unsupported/incorrect URL for RPC endpoint). Fail faster for better UX, and return an informative error message to the client.
Notes
Examples of errors that may be useful for the client
validateRequestURL failed
URI not matched with config Networks
http.DefaultClient.Do failed
http response is too big
Example for writing response to client (vs returning Error)