Incorrect Example
Nathaniel McCallum
rpc call with invalid Request object:
--> {"jsonrpc": "2.0", "method": 1, "params": "bar"}
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request."}, "id": null}
This example assumes that the request is an RPC. However, according to
the spec, this is not the case.
Section 4:
"If ['id'] is not included it is assumed to be a notification."
Section 4.1:
"A Notification is a Request object without an 'id' member. ... The
Server MUST NOT reply to a Notification, including those that are
within
a batch request. ... As such, the Client would not be aware of any
errors (like e.g. 'Invalid params.', 'Internal error.')."
Thus, I believe this example to be incorrect. Since 'id' is not
present
in the request we MUST assume that it is a notification and we MUST
NOT
send an error response.
Matt (MPCM)
object:
1) The method value is not a string
2) The params value is not an array or an object
A notification is a valid request object, lacking an id member. In
this case, it wouldn't be considered a valid request object.
On Nov 28, 12:05 pm, Nathaniel McCallum <nathan...@themccallums.org>
wrote:
Nathaniel McCallum
this interpretation might be your intention, but it is not valid
according to the spec. Either the spec needs to be changed to define
this assumption or the example needs to be changed to be in line with
the spec as currently defined.
Second, the behaviour you are proposing in your email makes error
detection very hard. Let's say that I send three requests, one is a
notification and two are requests. I get back two responses, one is
method not found and one is invalid request. Since the invalid request
response comes back with no id, I don't know whether it applies to my
remaining request or my notification. Nor does the json-rpc library
(that I am currently writing) know which callback to call.
The only sane way to track these types of scenarios is via a state
engine (which is what most json-rpc libraries are) and the only way
the state engine can maintain a sane state is if notifications NEVER
send a response. By adopting the policy suggested in the email you
have basically condemned all json-rpc libraries to be of low quality.
Lorenzo Pastrana
> you have basically condemned all json-rpc libraries to be of low
> quality
Hey ! This guy sounds like me a couple of years ago :D
Sorry Nath ... private joke.
Then,
Nath, there is a convetion that the order of precedence is : first
parsing then correctness then application ...
In terms of protocol (which JSON-RPC is), a request that emits an
application error is a request that was 100% successful, that is : it
was lexically correct, syntactically correct and grammatically correct.
Everything that comes after ... is a success.
Tell me if it's ok for you ..
On error detection, the earlier the occurrence in the precedence
stack ... the less elements you have to investigate ..
Lo.
Nathaniel McCallum
socket and get back an invalid request error with no id, which
callback do I call? Keep in mind I'm writing in good async style, so
each of my requests has a callback. If I know that the notification
will never respond and I receive a subsequent response message with an
id, I know that the invalid request error belongs to the request that
did not receive a response. Because I can deduce this, I can fire the
request's callback with the error. However, if the notification may
respond or may not respond, than I have no idea if I can fire the
request's callback or not.
Notifications must NEVER get a response except for parse error. This
is the only way to eventually reconcile responses to callbacks. If the
request is parsable and does not contain an id, we should NEVER
respond.
Yitzchak Scott-Thoennes
> Notifications must NEVER get a response except for parse error. This
> is the only way to eventually reconcile responses to callbacks. If the
> request is parsable and does not contain an id, we should NEVER
> respond.
What you are missing is that a malformed request is not a notification.
The "callback" for a response in this case should be the programmer.
How you get the message to the programmer is going to depend on your
precise situation, of course.
Nathaniel McCallum
implicit memory leak for requests stuck in a needs-response state.
On Nov 29, 4:31 pm, Yitzchak Scott-Thoennes <y...@shiftboard.com>
wrote:
Matt (MPCM)
wrote:
> If I write a request, a notification and a second request to the
> socket and get back an invalid request error with no id, which
> callback do I call? Keep in mind I'm writing in good async style, so
> each of my requests has a callback. If I know that the notification
> will never respond and I receive a subsequent response message with an
> id, I know that the invalid request error belongs to the request that
> did not receive a response. Because I can deduce this, I can fire the
> request's callback with the error. However, if the notification may
> respond or may not respond, than I have no idea if I can fire the
> request's callback or not.
The callback you call, is the one that matches the id in the request
object sent...
Lets break this down so we can clarify the issue. The clearer json-rpc
can be, the better it is for everyone. This is the right place to
discuss the specification, but please take the time to help us
understand your concerns without jumping to extreme proclamations
about condemning and quality. If there is an issue with the spec, I am
sure we will all want it addressed. :)
With your example, if you send 2 request objects (1 a notification)
and get 1 response object back, you would still match on the id before
triggering the callback. I think the issue may be the linking of a
callback in a non-deterministic way (like upon the transport returning
any request object, instead of the expected request object?)
Perhaps you can clarify the sequence of events more. json examples or
short text diagrams often help discussions here. :)
--
Matt (MPCM)
Lorenzo Pastrana
> socket and get back an invalid request error with no id, which
> callback do I call?
None ... (No ID, no callback).
Display a warning and go debug your code until requests are correct (and
your software is not "half dead" :P ).
Your software could(should) cope "dynamically" with execution errors,
but it can hardly be called a software before it issues correctly shaped
requests ..
> Notifications must NEVER get a response except for parse error.
They are NOT notifications until they are correctly shaped.
Out of common sense :
1. Correct JSON (if not => PARSE ERROR)
2. Correct JSON-RPC (if not => INVALID REQUEST)
3. Method Match (if not => INVALID METHOD)
4. Execution
5. Result (Only for full requests)
...
Lo.
Lorenzo Pastrana
> Nope, I get it. But the spec is unclear.
The spec is perfectly clear : the syntax of the requests MUST be
correct. (unless you are planning a fuzzy logic self correcting parser,
it should be the case for all protocols / file formats etc ...
Lo.
Nathaniel McCallum
> On Tue, 2011-11-29 at 13:52 -0800, Nathaniel McCallum wrote:
> > Nope, I get it. But the spec is unclear.
>
> The spec is perfectly clear
False. If I've asked the question, someone else will. Do you want them
searching through a mailing list or do you want it defined in the spec?
Yitzchak Scott-Thoennes
The spec is clear in the least possibly ambiguous way: an example that
directly addresses the issue (and led you to initiate this discussion).
Could you please suggest the changes to the English text that you would
have found helpful?
Sebastiaan van Erk
spec is unclear. It just means that the spec is unclear to that person.
In fact when I was implementing my own implementation of the spec I came
across this very issue, looked at the spec, and found it completely
unambiguous. So I'd have to concur with Lorenzo that the spec is
perfectly clear. :)
Best regards,
Sebastiaan
Nathaniel McCallum
Its very clear that we always respond with an error on any parsing
problem. The following areas are not clear to me from my reading of the
spec:
1. Should a server respond with INVALID REQUEST to a malformed response
object (for instance if it has both result and error)? My guess from
this is YES according to Lorenzo's error hierarchy.
2. Should a server respond with METHOD NOT FOUND when a notification is
sent to an invalid method? I don't see a clear answer to this one
anywhere.
The dispute between Lorenzo and I boils down to these two readings of
the spec:
Lorenzo read the spec as saying:
1. Correct JSON (if not => PARSE ERROR)
2. Correct JSON-RPC (if not => INVALID REQUEST)
3. Method Match (if not => INVALID METHOD)
4. Execution
5. Result (Only for full requests)
I read the spec as saying:
1. Correct JSON, if not => PARSE ERROR
2. Correct JSON-RPC, if not:
2a. If the message lacks an id, drop (notification case)
2b. Else, if the message contains result or error, drop (response case)
2c. Else, INVALID REQUEST (request case)
3. Method Match (if not => INVALID METHOD, unless its a notification)
4. Execution
5. Result (Only for full requests)
While the first one might be common sense, common sense is often neither
common nor sensical. And I think the spec permits both readings. In
short, if Lorenzo's reading is the canonical reading, than it should be
clearly defined in the spec, which it currently isn't.
Sebastiaan van Erk
> The dispute between Lorenzo and I boils down to these two readings of
> the spec:
>
> Lorenzo read the spec as saying:
> 1. Correct JSON (if not => PARSE ERROR)
> 2. Correct JSON-RPC (if not => INVALID REQUEST)
> 3. Method Match (if not => INVALID METHOD)
> 4. Execution
> 5. Result (Only for full requests)
>
> I read the spec as saying:
> 1. Correct JSON, if not => PARSE ERROR
> 2. Correct JSON-RPC, if not:
> 2a. If the message lacks an id, drop (notification case)
- It is clear from the reading of the spec that a Request object is per
definition correct JSON-RPC 2.0.
- A notification is by definition a Request object without an "id"
member (Section 5), which means it is also by definition correct
JSON-RPC 2.0.
- When a rpc call is made, the Server MUST reply with a Response, except
for in the case of Notifications.
Thus the server MUST respond in the case of incorrect JSON-RPC, even if
it is valid JSON but does not contain an id. Lorenzo's reading of the
spec is correct.
Regards,
Sebastiaan
Nathaniel McCallum
On Nov 30, 5:29 pm, Sebastiaan van Erk <svan...@gmail.com> wrote:
> Hi,> The dispute between Lorenzo and I boils down to these two readings of
> > the spec:
>
> > Lorenzo read the spec as saying:
> > 1. Correct JSON (if not => PARSE ERROR)
> > 2. Correct JSON-RPC (if not => INVALID REQUEST)
> > 3. Method Match (if not => INVALID METHOD)
> > 4. Execution
> > 5. Result (Only for full requests)
>
> > I read the spec as saying:
> > 1. Correct JSON, if not => PARSE ERROR
> > 2. Correct JSON-RPC, if not:
> > 2a. If the message lacks an id, drop (notification case)
>
> This is where you make a mistake:
> - It is clear from the reading of the spec that a Request object is per
> definition correct JSON-RPC 2.0.
> - A notification is by definition a Request object without an "id"
> member (Section 5), which means it is also by definition correct
> JSON-RPC 2.0.
> - When a rpc call is made, the Server MUST reply with a Response, except
> for in the case of Notifications.
>
> Thus the server MUST respond in the case of incorrect JSON-RPC, even if
> it is valid JSON but does not contain an id. Lorenzo's reading of the
> spec is correct.
Should a server respond with METHOD NOT FOUND when a notification is
Matt (MPCM)
wrote:
> Should a server respond with METHOD NOT FOUND when a notification is
> sent to an invalid method?
Nothing should be returned, per the spec 4.1 Notification: 'As such,
the Client would not be aware of any errors (like e.g. "Invalid
params.", "Internal error.").'
I like to structure the server code to handle request object layer
first. At the point where the next step would be to generate a
response, if there is no id the server will simply drop whatever was
generated. It makes clear the intent in your code, provides a uniform
flow for all request objects, and provides a spot to debug/log
notification responses prior to them disappearing. Personal preference
of course.
--
Matt (MPCM)
Sebastiaan van Erk
>> This is where you make a mistake:
>> - It is clear from the reading of the spec that a Request object is per
>> definition correct JSON-RPC 2.0.
>> - A notification is by definition a Request object without an "id"
>> member (Section 5), which means it is also by definition correct
>> JSON-RPC 2.0.
>> - When a rpc call is made, the Server MUST reply with a Response, except
>> for in the case of Notifications.
>>
>> Thus the server MUST respond in the case of incorrect JSON-RPC, even if
>> it is valid JSON but does not contain an id. Lorenzo's reading of the
>> spec is correct.
> Should a server respond with METHOD NOT FOUND when a notification is
> sent to an invalid method?
>
- When a rpc call is made, the Server MUST reply with a Response, except
for in the case of Notifications.
So no, the server must not respond.
Best regards,
Sebastiaan
Lorenzo Pastrana
On Wed, 2011-11-30 at 17:14 -0500, Nathaniel McCallum wrote:
> The dispute between Lorenzo and I
Please Nath, it's (eventually) a dispute between you and THE SPEC ... ;)
> boils down to these two readings of
> the spec:
You are reading the spec wrong, and tell us what you expected it to be,
it's ok; as long as you don't conclude that it MUST be the way you
expected.
Please read on :
> 2. Correct JSON-RPC, if not:
At this stage, the presence of an id is anecdotal ... fact is that the
request is malformed, and that's what matters, your server doesn't even
need to know whether it's a notification or a request, and it doesn't
know actually, until POST EXECUTION response time.
If you pursue your analysis of the json chunk further (seeking for an
id) you are plain ignoring an error.
> 2a. If the message lacks an id, drop (notification case)
> 2b. Else, if the message contains result or error, drop (response case)
> 2c. Else, INVALID REQUEST (request case)
If you decide not to issue the error (in case of no id) you are just
misleading your client sending the implicit message "the notification
was correctly formed".
This is where, because you are _carefully_ reading a PROTOCOL to
implement it, your common sense dings "Hey ! Wait a minute ! How would I
ever know if a notification is _malformed_ if I'm doing this ?" ... mmmh
the other way is correct.
Lo.
Nathaniel McCallum
>
> On Wed, 2011-11-30 at 17:14 -0500, Nathaniel McCallum wrote:
>> The dispute between Lorenzo and I
>
> Please Nath, it's (eventually) a dispute between you and THE SPEC ... ;)
I can gladly admit this. I only meant the difference between how you
read it and I read it.