Skip to content
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

types: make jsonrpc field optional #1385

Closed
wants to merge 4 commits into from
Closed

types: make jsonrpc field optional #1385

wants to merge 4 commits into from

Conversation

niklasad1
Copy link
Member

@niklasad1 niklasad1 commented May 31, 2024

Close #1142

Previously, we made the interpretation that jsonrpc field must exist but recently #1045 explained to me that it could be interpreted as optional.

So, let's change it to optional all over jsonrpsee.

I'm not 100% convinced by the interpretation of request object but it doesn't bother me to support it for stuff without the jsonrpc header...

@niklasad1 niklasad1 requested a review from a team as a code owner May 31, 2024 10:03
@niklasad1 niklasad1 changed the title fix: make jsonrpc field optional types: make jsonrpc field optional May 31, 2024
// Without params and ID.
(r#"{"jsonrpc":"2.0","id":null,"method":"subtract"}"#, None, None, method),
(r#"{"jsonrpc":"2.0","id":null,"method":"subtract"}"#, None, None, method, Some(TwoPointZero)),
Copy link
Collaborator

@jsdw jsdw May 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the idea of giving the version too so that you'd add a test which didn't have the "jsonrpc" field? :)

types/src/request.rs Outdated Show resolved Hide resolved
@jsdw
Copy link
Collaborator

jsdw commented May 31, 2024

I'm not 100% convinced by the interpretation of request object but it doesn't bother me to support it for stuff without the jsonrpc header...

Yeah; I wasn't 100% convinced (I mean, without the version, how do you know how to interpret a given request/response?).

The spec does also say this:

JSON-RPC 2.0 Request objects and Response objects may not work with existing JSON-RPC 1.0 clients or servers. However, it is easy to distinguish between the two versions as 2.0 always has a member named "jsonrpc" with a String value of "2.0" whereas 1.0 does not. Most 2.0 implementations should consider trying to handle 1.0 objects, even if not the peer-to-peer and class hinting aspects of 1.0.

Emphasis on "always" is mine

@niklasad1
Copy link
Member Author

5 Response object

When a rpc call is made, the Server MUST reply with a Response, except for in the case of Notifications. The Response is > expressed as a single JSON Object, with the following members:

jsonrpc
A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0".

result
This member is REQUIRED on success.
This member MUST NOT exist if there was an error invoking the method.
The value of this member is determined by the method invoked on the Server.

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

id
This member is REQUIRED.
It MUST be the same as the value of the id member in the Request Object.
If there was an error in detecting the id in the Request object (e.g. Parse error/Invalid Request), it MUST be Null.

The only way around that is that is doesn't specify "REQUIRED" for jsonrpc stuff but yeah I agree

@niklasad1 niklasad1 closed this May 31, 2024
@jsdw
Copy link
Collaborator

jsdw commented May 31, 2024

The only way around that is that is doesn't specify "REQUIRED" for jsonrpc stuff but yeah I agree

Yeah, I was initially agreeing with this PR on account of that, but maybe the spec just isn't quite being clear, or it's allowing it to be optional for implementations to handle 1.0 too (which doesn't have that field at all)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Subscriptions just returns None (no error) - manual tokio_tungstenite works fine
2 participants