New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC: Strict JSON-RPC 2.0 compliance (gated behind flag) #12435
RPC: Strict JSON-RPC 2.0 compliance (gated behind flag) #12435
Conversation
@@ -180,7 +180,7 @@ class UniValue { | |||
bool push_back(std::pair<std::string,UniValue> pear) { | |||
return pushKV(pear.first, pear.second); | |||
} | |||
friend const UniValue& find_value( const UniValue& obj, const std::string& name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
univalue changes need to be submitted upstream, not here :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
He did that (see OP).
Concept ACK |
src/rpc/server.cpp
Outdated
{ | ||
} catch (const int x) { | ||
if (x != -1) { | ||
throw; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented in the univalue PR that this catch should probably be for a derived class of std::exception
, not int
. If this is the case, there will be no need to re-throw, as the std:exception handler will catch all else below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, throwing an int is really weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK 6fe7afa
Just a few small comments. As others have noted, should definitely figure out something to throw that isn't an int.
strReply = JSONRPCReply(result, NullUniValue, jreq.id); | ||
if (ret.isNull()) { | ||
// JSON-RPC 2.0: return nothing at all | ||
return false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this create different behavior for degenerate returns when not passing -strictjsonrpcspec
?
src/httprpc.cpp
Outdated
else | ||
throw JSONRPCError(RPC_PARSE_ERROR, "Top-level object parse error"); | ||
std::string strReply; | ||
strReply = ret.write() + "\n"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could just do std::string strReply(ret.write() + "\n");
*/ | ||
|
||
bool fStrictJSONRPCSpec = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this have some kind of g
prefix given it's a global? Also, may want to use snake_case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, should be g_strict_jsonrpc_spec
or such w/ the new guidelines.
src/univalue/include/univalue.h
Outdated
@@ -304,4 +306,9 @@ extern const UniValue NullUniValue; | |||
|
|||
const UniValue& find_value(const UniValue& obj, const std::string& name, const bool throw_if_not_present = false); | |||
|
|||
class KeyNotPresentError: public std::runtime_error { | |||
public: | |||
KeyNotPresentError(): std::runtime_error("KeyNotPresentError") {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These exception constructors are usually made explicit
to prevent implicit conversion. You can see uint_error as an example.
Tests are failing on the latest commit. Looking in to it. |
doh! |
Squash needed at some point. |
Nice. Concept ACK. |
43f349c
to
76eb200
Compare
My attempt to squash this seems to have gone awfully wrong. Trying to fix it up... edit: should be fine now. |
76eb200
to
d87d60a
Compare
Related: #2960 |
@@ -302,6 +305,6 @@ static inline bool json_isspace(int ch) | |||
|
|||
extern const UniValue NullUniValue; | |||
|
|||
const UniValue& find_value( const UniValue& obj, const std::string& name); | |||
const UniValue& find_value(const UniValue& obj, const std::string& name, enum UniValue::keystatus *status=NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure this univalue API change is really necessary? You could find out if the key is there with an additional call to Univalue::exists
? (or am I missing something)
(travis failure is due to subtree check for univalue) |
The last travis run for this pull request was 151 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened. |
Needs rebase |
Closing this for now, and adding "up for grabs" tag. Let me know if you want to start work on this again and I'll reopen… |
This patch adds a -strictjsonrpcspec flag.
If the flag is used, bitcoind enters JSON-RPC 2.0 mode, which allows it to be fully spec-compliant (and thus work with libraries like libjson-rpc-cpp without modification).
I've added a functional test for the specific bits of the spec that I've changed.
univalue changes are included in this commit for ease of review but I can pull those out (see bitcoin-core/univalue-subtree#12)