Support JSON-RPC 2.0

mezrin commented at 9:24 pm on August 30, 2013: none

Currently Bitcoind supports JSON-RPC 1.0 and couple of 2.0 features

If you look at existing implementations - 61 of 71 works ONLY with 2.0 version. And in reality there is no Java library that supports 1.0 http://en.wikipedia.org/wiki/JSON-RPC#Implementations Moreover - wiki page looks outdated, I think that all libs except 2-3 support only 2.0 version.

We need main features from JSON-RPC 2.0 (http://www.simple-is-better.org/rpc/#differences-between-1-0-and-2-0):

Transport independence. Bitcoind should not throw 500 http error on every exception. It’s only for crashed code. For example, there is no Java JSON-RPC lib that provide sufficient support for hadling 500 http error. So, if you develop Java service that uses Bitcoind - you are not able to work with custom Bitcoind exceptions. (https://github.com/bitcoin/bitcoin/blob/master/src/bitcoinrpc.h) Otherwise you either have to write from scratch or modify existing library, what generally is not easy. Moreover, nobody except you will support this lib for JSON-RPC 1.0
Reduced fields. Some libraries throw an error if the fields “error” and “result” are found together - it’s true for JSON-RPC 1.0, but wrong for 2.0
named parameters

Full support of 2.0 is preferable.

P.S. In recent days, I’m implementing a Java service that uses Bitcoind - guys, this is hell. The current interface is not suitable for real-world applications that deal with money. I don’t understand why version 1.0 instead of 2.0 was choosen…

jgarzik commented at 9:29 pm on August 30, 2013: contributor

Ultimately it is an internal control interface for bitcoind. Spec compliance for the sake of spec compliance is a nice side project for someone, but we don’t just want to add code for little value.

Of course anywhere that we produce code that breaks other implementations, absolutely, let’s fix that.

mezrin commented at 9:48 pm on August 30, 2013: none

ok, I hope that there is a man who knows C + + and ready to implement 2.0 support ))

Now, if it’s possible - let’s stop to throw 500 http error for every internal exception. It will be the step toward JSON-RPC 2.0 ))

For example, if you call method “getreceivedbyaddress” and provide wrong address - Bitcoind should return 200 http response and the same message as now (not 500 http error with the message). It’s the feature that blocks normal use of the Bitcoind by a Java client

jgarzik commented at 9:53 pm on August 30, 2013: contributor

Changing ‘500’ HTTP status to something else seems like a reasonable request.

luke-jr commented at 1:32 am on August 31, 2013: member

Addressing your issue #2 (including only one of result vs error) breaks python-bitcoinrpc at least, as well as JSON-RPC 1.0 compatibility. I propose we upgrade to full JSON-RPC 2.0 at the same time as we switch to using integer Numbers for all amounts. :)

mezrin commented at 6:56 am on August 31, 2013: none

ok, result vs error could be fixed some later :) 500 http error code have much higher priority for Java clients

laanwj commented at 10:32 am on August 31, 2013: member

Agree with @jgarzik. Not breaking compability with current clients is more important IMO. I’m fine with an optional JSON-RPC 2.0 mode if anyone is so inclined (and it doesn’t result in much more code), but let’s not randomly break old clients.

mezrin commented at 11:11 am on August 31, 2013: none

yes, optional JSON-RPC 2.0 mode, that is set via the bitcoin.conf, is the best solution.

About breaking compatibility - switch from 500 http error code to 200 http response is break any existing client or not?

luke-jr commented at 12:47 pm on August 31, 2013: member

@laanwj When multiple RPC versions have been proposed in the past, the conclusion at the end was that we should just break compatibility at some ‘Y’ (as in x.y.z) release since the client is beta anyway.

laanwj commented at 2:42 pm on August 31, 2013: member

IMO “it’s beta anyway” is a bad excuse, a lot of software is relying on the interface as it is now. Better have a very good reason to break compatibility.

sipa commented at 2:45 pm on August 31, 2013: member

I had no clue we were using HTTP 500 status to report RPC errors, but it does explain why some JSON-RPC libraries don’t deal well with bitcoind error conditions. Fixing this seems very reasonable, unless there is actually software relying on this.

How about fixing this for 0.9rc, and if people complain before final, revert it or make it optional, with the plan to deprecate it later?

anton9088 commented at 8:16 pm on January 29, 2014: none

I found a solution to this problem. For resolve you must go in rpcserver.cpp and change

void ErrorReply(std::ostream& stream, const Object& objError, const Value& id) { // Send error reply from json-rpc error object //int nStatus = HTTP_INTERNAL_SERVER_ERROR; int nStatus = HTTP_OK;

0int code = find_value(objError, "code").get_int();
1if (code == RPC_INVALID_REQUEST) nStatus = HTTP_BAD_REQUEST;
2else if (code == RPC_METHOD_NOT_FOUND) nStatus = HTTP_NOT_FOUND;
3string strReply = JSONRPCReply(Value::null, objError, id);
4
5//stream << HTTPReply(nStatus, strReply, false) << std::flush;
6stream << HTTPReply(nStatus, strReply, true) << std::flush;

}

sipa commented at 8:21 pm on January 29, 2014: member

Yeah, why are we using a 5xx status code for a problem with the RPC parameters?

laanwj commented at 8:28 pm on January 29, 2014: member

The same reason as most other crazy stuff in bitcoind. It’s always been that way and no one dared to change it.

laanwj added the label RPC on May 9, 2014

LinusU commented at 12:29 pm on June 3, 2014: none

Might i suggest that instead of adding a config for jsonrpc version, just look at the incoming request. If it contains "jsonrpc": "2.0" then respond with a 2.0 compliant object.

Then we could encourage people to follow the spec and when we feel comfortable, remove the old responses.

Also, the difference is so subtle so I really don’t think that we will break any existing clients.

cono commented at 10:01 pm on December 23, 2015: none

:+1: for #2 I’ve tried 3 different libraries in Perl, they treat:

0"error": null

as an error.

Due to the http://www.jsonrpc.org/specification :

0error
1  This member is REQUIRED on error.
2  *This member MUST NOT exist if there was no error triggered during invocation.*
3  The value for this member MUST be an Object as defined in section 5.1.

Bushstar referenced this in commit 2c5e2bc6c8 on Apr 8, 2020

pinheadmz commented at 7:18 pm on February 14, 2023: member

Possible solution: #27101 Looking for concept ACKs on that before finishing

pinheadmz assigned pinheadmz on Jun 2, 2023

ryanofsky closed this on May 16, 2024

ryanofsky referenced this in commit 75118a608f on May 16, 2024

Support JSON-RPC 2.0 #2960