After pull #4288, RPC messages indicating errors have a Content-Length unrelated
to their actual contents, rendering bitcoin-cli and curl unable to decode the
reply.
This patch sets the Content-Length field based on the actual content returned.
Additionally, pull #4288 clobbered the error descriptions provided in
ErrorReply, which bitcoin-cli relies upon; this patch moves #4288 http-error
descriptions to an HTTPError method, allowing HTTPReply to pass content on
unchanged.
1) support varying content types
2) support only sending the header
3) properly deliver error message as content, if HTTP error
4) move AcceptedConnection class to header, for wider use
First query in the current way (intelligently determining which network
has a non-localhost interface). If this does not succeed, try plain
lookup.
Needed for testing.
Fixes#1827 by always allowing IPv6 to be used.
contrib/devtools/fix-copyright-headers.py script to be able to perform this maintenance task with ease during the rest of the year, every year. Modifications to contrib/devtools/README.md to document what fix-copyright-headers.py does.
Currently it is only possible to use `walletpassphrase` to unlock the
wallet when bitcoin is started in server mode.
Almost everything that manipulates the wallet in the RPC console
needs the wallet to be unlocked and is thus unusable without -server.
This is pretty unintuitive to me, and I'm sure it's even more confusing
to users.
Solve this with a very minimal change: by making the GUI start a
dummy RPC thread just to handle timeouts.
Split bitcoinrpc up into
- rpcserver: bitcoind RPC server
- rpcclient: bitcoin-cli RPC client
- rpcprotocol: shared common HTTP/JSON-RPC protocol code
One step towards making bitcoin-cli independent from the rest
of the code, and thus a smaller executable that doesn't have to
be linked against leveldb.
This commit only does code movement, there are no functional changes.
kazcw