This modifies the code which handles failed server responses to attempt
to unmarshal the response bytes as a regular JSON-RPC response
regardless of the HTTP status code and, if that fails, return an error
that includes the status code as well as the raw response bytes.
This is being done because some JSON-RPC servers, such as Bitcoin Core,
don't follow the intended HTTP status code meanings. For example, if
you request a block that doesn't exist, it returns a status code of 500
which is supposed to mean internal server error instead of a standard
200 status code (since the HTTP request itself was successful) along
with the JSON-RPC error response.
The result is that errors from Core will now show up as an actual
RPCError instead of an error with the raw JSON bytes.
This also has the benefit of returning the HTTP status code in the
error for real HTTP failure cases such as 401 authentication failures,
which previously would just be an empty error when used against Core
since it doesn't return the actual response along with the status code
as it should.
This refactors the notification state mutex out of the state itself to
the client. This is being done since the code makes a copy of the
notification state and accesses that copy immutably, and therefore there
is no need for it to have its own mutex.
The existing check to only log errors from websocket connections when
the error is not because the connection is being shutdown only detects
the single case where the remote client was shutdown.
This commit modifies that logic to include when the connection is being
forcibly shutdown via closing the quit channel and when it has been
shutdown from a client side close.
Don't log "Established connection" message on new when
DisableConnectOnNew is set and no connection was actually established.
Do log that same message when Connect() successfully connects.
This commit contains several changes needed to update the client to use
the latest version of btcjson. In addition, it contains a couple of other
minor changes along the way.
While the underlying changes are quite large, the public API of this
package is still the same, so caller should generally not have to update
their code due to that. However, the underlying btcjson package API has
changed significantly. Since this package hides the vast majority of that
from callers, it should not afffect them very much. However, one area in
particular to watch out for is that the old btcjson.Error is now
btcjson.RPCError, so any callers doing any type assertions there will need
to update.
The following is a summary of the changes:
- The underlying btcjson significantly changed how commands work, so the
internals of this package have been reworked to be based off of requests
instead of the now non-existant btcjson.Cmd interface
- Update all call sites of btcjson.New<Foo>Cmd since they can no longer
error or take varargs
- The ids for each request are part of the request now instead of the
command to match the new btcjson model and are strict uint64s so type
assertions are no longer needed (slightly improved efficiency)
- Remove the old temporary workaround for the getbalance command with an
account of "*" since btcwallet has since been fixed
- Change all instances of JSONToAmount to btcutil.NewAmount since that
function was removed in favor of btcutil.Amount
- Change all btcws invocations to btcjson since they have been combined
Previously the exported Disconnect and Shutdown functions called each other
and therefore needed to release and reacquire the locks which could
potentionally allow a request to sneak in between the lock and unlock.
This commit changes the exported Shutdown function so that everything is
done under the request lock to prevent this possibility. In order to
support this, the shared code between the Disconnect and Shutdown
functions has been refactored into unexported functions and the locking
has been altered accordingly.
Also, replace the sendMessage function with a select over the send and
disconnect channels to prevent any issues with queued up messages.
joint debugging effort between myself and @jrick
Previously, requests could still be sent to a shutdown client and
added to the client's internal data structures, without ever
responding to the future with an error for a shutdown client (causing
hangs when blocking on the future receive). This change fixes this by
performing a non-blocking read of the client's shutdown channel before
adding a request, and responding with the shutdown error if the client
has begun or completed its shutdown.
ok @davecgh
This commit modifies the error handling for websocket connections to fall
back to returning the status text returned from the server if the
handshake fails and it's not due to an authentication or invalid endpoint.
This change set equips the RPC client with handling of non successful
HTTP responses. An HTTP response is considered non successful when its
status code is not in the range 200..299
This commit modifies the TLS setup to only override the RootCAs for the
TLS connection if certificates are specified. This allows the
Certificates parameter to be ommitted from the connection config to use
the system CAs.
If connecting to a bitcoin RPC server as an HTTP POST client, full
response objects rather than just the raw result bytes were being
passed to the specific result unmarshalers, causing unmarshal errors
for the incorrect JSON types. To fix this, first unmarshal the
response body into a rawResponse, and pass only the raw result bytes
(or an error) to the specific handlers.
This was reported by nskelsey on IRC.
ok @davecgh
This commit adds logic to track all registered notifications that have
been registered by the client in a notification state when the default
automatic reconnect is enabled.
The notification state is then used to reregister for all previously
registered notifications on reconnect. This allows the caller to
continue receiving notifications across reconnect cycles.
Also, since the new package exposes more connection related error
information, add a new ErrInvalidEndpoint which is returned if the
specified enpoint does not appear to be a valid websocket provider and
only return the ErrInvalidAuth error when HTTP authorization failure
status codes are detected.
Closes#1.
