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

Omit params field from requests instead of sending null value #640

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

selu
Copy link

@selu selu commented Oct 2, 2021

Based on the specification, the request's params must be an array or an object if it exists, so sending a null value is not valid. Actually, it causes errors for KODI JSONRPC server with requests without any parameters. That's why I tried to find a way to fix this issue.

The solution is very simple, just I haven't updated the comments for the params field.

Signed-off-by: Szabolcs Seláf <selu@selu.org>
Signed-off-by: Szabolcs Seláf <selu@selu.org>
Signed-off-by: Szabolcs Seláf <selu@selu.org>
@selu selu marked this pull request as ready for review October 2, 2021 10:06
Copy link
Contributor

@tomusdrw tomusdrw left a comment

Choose a reason for hiding this comment

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

@selu thanks a lot! This looks indeed sensible. Do you mind adding an additional test case to make sure that the server side of the library is correctly converting missing params into None?

I think adding a reverse test case (i.e. deserialize without params) would suffice, unless I didn't see we already have a testcase like that.

core/src/types/request.rs Outdated Show resolved Hide resolved
Copy link
Member

@niklasad1 niklasad1 left a comment

Choose a reason for hiding this comment

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

Thanks, I agree with your interpretation of the spec.

I suggest additional tests for jsonrpc derive (if possible):

  1. a method without params: fn a() -> BoxedFuture
  2. a method with optional param: fn b(p: Option<usize>)

Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com>
@selu
Copy link
Author

selu commented Oct 5, 2021

@tomusdrw , I found the test case for deserialize without params, it is the last item of fn call_deserialize() between lines 263 and 273 in file core/src/types/request.rs

@selu
Copy link
Author

selu commented Oct 5, 2021

Thanks, I agree with your interpretation of the spec.

I suggest additional tests for jsonrpc derive (if possible):

1. a method without params: `fn a() -> BoxedFuture`

There is already a test case for empty params in derive/tests/macros.rs

#[rpc]
pub trait Rpc {
	/// Returns a protocol version.
	#[rpc(name = "protocolVersion")]
	fn protocol_version(&self) -> Result<String>;fn should_accept_empty_array_as_no_params() {
	let mut io = IoHandler::new();
	let rpc = RpcImpl::default();
	io.extend_with(rpc.to_delegate());

	// when
	let req1 = r#"{"jsonrpc":"2.0","id":1,"method":"protocolVersion","params":[]}"#;
	let req2 = r#"{"jsonrpc":"2.0","id":1,"method":"protocolVersion","params":null}"#;
	let req3 = r#"{"jsonrpc":"2.0","id":1,"method":"protocolVersion"}"#;

However, this checks another cases too.

2. a method with optional param: `fn b(p: Option<usize>)`

I could not find test case for optional param, probably it worth it to add one. Would it be ok in the same file in a similar way?

@niklasad1
Copy link
Member

I could not find test case for optional param, probably it worth it to add one. Would it be ok in the same file in a similar way?

Yes, just make a new unit test for it in that file should be fine

Signed-off-by: Szabolcs Seláf <selu@selu.org>
@selu
Copy link
Author

selu commented Oct 6, 2021

@niklasad1 , test is added for the optional parameter, please review.

io.extend_with(rpc.to_delegate());

// when
let req1 = r#"{"jsonrpc":"2.0","id":1,"method":"sqr","params":[2]}"#;
Copy link
Member

@niklasad1 niklasad1 Oct 6, 2021

Choose a reason for hiding this comment

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

I would like to add requests with "params":[] and "params":null here otherwise looks great

Copy link
Author

Choose a reason for hiding this comment

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

Added those variations to the test case.

// when
let req1 = r#"{"jsonrpc":"2.0","id":1,"method":"sqr","params":[2]}"#;
let req2 = r#"{"jsonrpc":"2.0","id":1,"method":"sqr","params":[]}"#;
let req3 = r#"{"jsonrpc":"2.0","id":1,"method":"sqr","params":null}"#;
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be rejected as invalid?

Copy link
Author

Choose a reason for hiding this comment

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

It's a good question, I know only KODI jsonrpc server, that rejects only "params":null variation, but accepts both "params":[] and "params":{} as an empty parameter.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd distinguish 3 different cases:

  1. Method expects positional arguments (either 0 or some being optional)
  2. Method expects named arguments (either 0 or some being optional)
  3. Method expects raw arguments

In case (1) IMHO only params: [] should be accepted, similarly in case (2) only params: {} should be accepted. In both cases omitting params should be rejected.
In the 3rd case we can accept any combination, since it's up to the method to handle the raw parameters being passed.

Regarding params: null I'm wondering if that should be forbidden completely, since it's not really part of the spec.

Copy link
Member

@niklasad1 niklasad1 Oct 7, 2021

Choose a reason for hiding this comment

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

In both cases omitting params should be rejected.

hrm, really? In the client code Params::None would rejected then?

Regarding params: null I'm wondering if that should be forbidden completely, since it's not really part of the spec.

I'm fine with that and it might better to be explicit, mainly because it might be possible that a request contains the wrong type/format and the default value is then used without that the caller gets informed by that....

Copy link
Contributor

Choose a reason for hiding this comment

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

hrm, really? In the client code Params::None would rejected then?

I was checking the code and it might not be what we do now. AFAICT in case of optional parameters we parse None correctly as well. Anyways, I think this discussion is a bit tangential to that particular PR, so let's open an issue and discuss there.

The code in PR is an improvement for the client side for sure, we might want to follow up on how we want the server to behave separately.

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.

None yet

3 participants