Invalid Batch Example clarification
Andrew Bent
following situation. From the examples in the pending 2.0 spec, it
gives the following example for a response to an invalid batch:
--> [1,2,3]
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request."}, "id": null}
Why does this warrant a single response instead of 3 batched "Invalid
Request" responses?
Otherwise, I must iterate all batches twice, once to make sure they
are all objects, then again to see if the inner objects are valid
requests.
Or is either response allowed depending on whether the server thinks
the batch request has failed versus each request in the batch has
failed?
This seems to me like something that could lead to compatibility
problems between different client / server implementations if not
specified clearly.
Matt (MPCM)
to be returned.
I have limited net access due to power outages in New Hamphire. I'll
review and correct this once I can get a real connection. -sent from
iPhone
--
Matt (MPCM)
Josh Marshall
not an array is because the system cannot determine anything about the
request (it's under the "Procedure call with Invalid JSON-RPC"
subheading in the site wiki, and "RPC Call with Invalid Batch" on the
Google Groups doc), much less assume it is a batch request. Therefore
much like the parse error it returns a single error for the entire
call. But that's the problem with assumptions I guess... :)
I suppose the question is are we saying that any time an array is
passed (and successfully parsed), it MUST be a batch, and then treat
all subsequent errors as batch errors? I think that would make sense
if it is spelled out in large letters in the documentation, and
there's a consensus on it.
Apologies if I shouldn't be chiming in.
Rasjid Wilcox
>
> I suppose the question is are we saying that any time an array is
> passed (and successfully parsed), it MUST be a batch, and then treat
> all subsequent errors as batch errors? I think that would make sense
> if it is spelled out in large letters in the documentation, and
> there's a consensus on it.
I would definitely prefer anything that looks like an array to be
treated as a batch request. I've got an early version of my
bidirectional jsonrpc implementation up at
http://www.openminddev.net/projects/projects/show/python-rpcbd. Its
way of processing batch requests builds on the json splitter idea that
Roland posted here a while ago. Upon seeing a [, it starts trying to
'split' it into json objects. It then sends these parts to the real
json parser. Note that the splitter does not really 'understand' json
fully. Just enough so that for valid json it will split it correctly.
So if passed '[ z, z, z ]' it would emit three json 'objects', and
the real parser would return three parse errors.
On the other hand, an implementation that was designed to run over
http would always get the entire batch request as a single string, so
the sensible thing to do would be to pass the entire string to the
json parser, which would then return a *single* parse error for the
entire 'array'.
Note that if the "batch request" was '[1, 2, 3]', then this is valid
json, and so will return three (invalid request) errors. And if
passed '***', the server should definitely return a (single) parse
error. So either way, the client should be able to handle either an
array of errors, or a single parse error, as a response to a batch
request.
Therefore I suggest that it makes little difference to the *client*
whether it gets a single error or an array of errors. It must be able
to handle both. (Of course an array of errors is actually more
informative in general.)
I actually think that either response is okay. The spec says "If the
batch rpc call itself fails, the return from the Server MUST be a
single Response object with the related error details". Whether the
batch rpc call itself fails for a given input may be server specific!
For the example in the spec "rpc call Batch, invalid JSON", my server
would return an array of responses, the first one being the result of
a successful call, and the second one a parse error. And it may have
already made the first rpc call before the parse error is discovered,
so it has *better* return a result!
I suggest that the example in the spec be adjusted to include
<--[ {"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse
error."}, "id": null} ]
as an *equally* valid response to the "rpc call Batch, invalid JSON".
Cheers,
Rasjid.
Matt (MPCM)
mode once it detects the payload is an array. For now, I have updated
the incorrect example in the spec to show a return of three error
objects in batch response to a 3 non-request-object array.
However, to Rasjid's point... invalid JSON is a bit of another matter.
Batch should be viewed as a container, and you should not start
processing the inside requests until you are sure the container is
valid JSON. I see your point about the complication that arises from
implementations that parse and process json without first validating
the container, but the solution should be to think of the container as
something that must pass some type of schema (even if the server does
not make this check).
If you need rapid processing as a client, sending many single request
objects instead of batch makes more sense and provides a finer grain
error mechanism to invalid json already.
thoughts?
--
Matt (MPCM)
Lorenzo Pastrana
Lo.
Erik
You're the author of that doc so I'd say you know best, but I wonder
if that example is based on this statement from section 6: "If the
batch rpc call itself fails, the return from the Server MUST be a
single Response object with the related error details."
I wouldn't call the example send an outright failure of the RPC call.
I agree with pretty much everyone else that if it is a valid array,
the server should treat it as a batch request even for arrays of one
element. It's a simpler implementation for the server to pack up an
array of responses even if they are all error responses than to track
if there were any successes and return a single error response if
there were none.
Some possibilities:
Request: [1,2,3
Response: {"jsonrpc": "2.0", "error": {"code": -32700, "message":
"Parse Error"}, "id": null}
Request: []
Response: {"jsonrpc": "2.0", "error": {"code": -32600, "message":
"Invalid Request"}, "id": null}
- OR?? -
Response: [{"jsonrpc": "2.0", "error": {"code": -32600, "message":
"Invalid Request"}, "id": null}]
I like the second response better since the request looks like batch
even if it is empty.
Request: [1]
Response: [{"jsonrpc": "2.0", "error": {"code": -32600, "message":
"Invalid Request"}, "id": null}]
I'm going to be a little lazy on this one.
Request: [<Valid Request Object>, <Invalid Request Object>]
Response: [<Valid Response Object>, {"jsonrpc": "2.0", "error":
{"code": -32600, "message": "Invalid Request"}, "id": null}]
On Feb 27, 9:01 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> Looks like a bad example. Off hand, I would expect three error objects
> to be returned.
> --
> Matt (MPCM)
Matt (MPCM)
Your error examples look exactly as I would expect, with the exception
of last response in this post.
->: [1,2,3
<-: {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse
Error"}, "id": null}
->: [1]
<-: [{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request"}, "id": null}]
->: [<Valid Request Object>, <Invalid Request Object>]
<-: [<Valid Response Object>, {"jsonrpc": "2.0", "error": {"code":
-32600, "message": "Invalid Request"}, "id": null}]
================
->: []
<-: {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request"}, "id": null}
->: []
<-: [{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request"}, "id": null}]
->: []
<-: []
================
The first one looks wrong to me, but a single response object looked
equally wrong. If there are no request objects in the batch, perhaps
we should be returning an empty array. That seems more symmetric to
me, as no error occurred as there were no requests.
I have adjusted the spec to be more specific about section 6, the last
line now reads:
"If the batch rpc call itself fails to be recognized as an Array or
valid JSON, the return from the Server MUST be a single Response
object with the related error details."
I have not added anything specific about returning an empty array yet,
until I hear back from others here. In a strange way the passing of
empty batch requests and responses could be used as a heartbeat to
check a ongoing steamed connection.
--
Matt (MPCM)
Lorenzo Pastrana
Request: []
Response: {"jsonrpc": "2.0", "error": {"code": -32600, "message":
"Invalid Request"}, "id": null}
- OR?? -
Response: [{"jsonrpc": "2.0", "error": {"code": -32600, "message":
"Invalid Request"}, "id": null}]
Lo.
Lorenzo Pastrana
I have not added anything specific about returning an empty array yet,
until I hear back from others here. In a strange way the passing of
empty batch requests and responses could be used as a heartbeat to
check a ongoing steamed connection.
Matt (MPCM)
Grin, quite. I am not usually a fan of overloading meanings, just a
passing thought...
How do you feel about the empty array in responds with an empty array
out part?
--
Matt (MPCM)
Erik
I have no issues, just seems a little.... inelegant. It's much like
the client is doing a non-batch request and just sends 0 bytes. Should
the server in that case send nothing or an error response? That's not
really and apples to apples comparison, but it's not entirely apples
to oranges IMHO (0 bytes wouldn't even be valid JSON).
For a heart beat, the empty array would work. The client would know
what it's doing and could just ignore the error response.
I'm sure 2.0 will get finalized and more issues with batch would come
up. It's that way with every new idea. JSON-RPC is a great technology.
I tried my damnedest to push it over SOAP and XML-RPC while at IBM.
Then again "simple" and "works" is not the IBM way.
Lorenzo Pastrana
> HACK!HACK!HACK!
Too bad thi picture didnt passed thru, it was a fearful portrait : http://www.bflv.com/blog/wp-content/uploads/2009/07/3MarsAttacks_MartianSoldier.jpg
Grin, quite. I am not usually a fan of overloading meanings, just a passing thought...
Read here :
http://oxomoxo.gumpig.com/entries/bad-practices/butt-plugged-code
How do you feel about the empty array in responds with an empty array out part?
The whole batch thing for me is a little fragile ... I can live with it as well as I could live with the empty array return ... but(t)
Lo.
Lorenzo Pastrana
--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.
Rasjid Wilcox
> However, to Rasjid's point... invalid JSON is a bit of another matter.
> Batch should be viewed as a container, and you should not start
> processing the inside requests until you are sure the container is
> valid JSON. I see your point about the complication that arises from
> implementations that parse and process json without first validating
> the container, but the solution should be to think of the container as
> something that must pass some type of schema (even if the server does
> not make this check).
>
> If you need rapid processing as a client, sending many single request
> objects instead of batch makes more sense and provides a finer grain
> error mechanism to invalid json already.
>
> thoughts?
I think you are right. Given the ability to send multiple requests
across a single connection, the main reason I even implemented batched
calls was to fully support the spec, although I have in mind
supporting http as a transport where batch requests are useful.
Either way, I can reasonably wait until I've received the whole batch
before starting processing, since if over plain tcp, if the client
needs requests processed as quickly as possible, they can send them
individually, and if over http, that is how they will arrive anyway.
So I can check for well formed json before processing. It also
addresses my other problem, which is that I can check that the array
is either only requests, or only responses, and reject it if it mixes
them, again before any processing takes place.
Cheers,
Rasjid.
Matt (MPCM)
->[]
<-{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request"}, "id": null}
- or -
->[]
<-[]
The first defines batch as containing 1 or more request objects.
The second defines batch as containing 0 or more request objects.
Lorenzo and Erik commented, I was hoping for a little more opinion to
be shared from the community. However, I am moving for the second to
be default. My reasoning being this:
1) Array in, Object out means an error occurred and that the batch was
not processed.
2) Array in, Array out means it was processed fine, even if there was
no actual work performed.
As a result, the only time a batch request will receive an object
response is for invalid json. The rest of the time it will provide one
response object per request (non-notification). No request objects
will result in no response objects, but the container will still be
honored.
--
Matt (MPCM)
Rasjid Wilcox
> So it looks like we are down to two options:
>
> ->[]
> <-{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
> Request"}, "id": null}
>
> - or -
>
> ->[]
> <-[]
>
> The first defines batch as containing 1 or more request objects.
> The second defines batch as containing 0 or more request objects.
>
> Lorenzo and Erik commented, I was hoping for a little more opinion to
> be shared from the community.
Hi Matt,
Sorry for not giving feedback before. I've had a major work deadline.
But I've just realised that the second option is *completely*
impossible to implement in a bidirectional peer-to-peer setting, since
it creates an infinite bounce effect.
-> []
<- []
-> []
... and so on ...
Unless you (artificially) introduce a delay between an empty array
being received and being responded to, you will consume all of the
bandwidth (and over a fast link a lot of the cpu) sending empty arrays
back and forth.
On the other hand, option one is not without issues too!
For example, assuming bidirectional peer-to-peer, consider a batch of
notifications under option one:
-> [
{"jsonrpc": "2.0", "method": "say", "params": ["hello"]},
{"jsonrpc": "2.0", "method": "say", "params": ["world!"]}
]
<- []
Now what? Under option one, the response should be:
-> {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request"}, "id": null}
but of course this is not the correct thing to do, since the empty
batch is just the response to the initial batch of notifications sent.
We could change our response based on 'have we just sent a batch of
notifications' but that smacks of special cases and is not in my mind
very satisfactory.
So we have option 3: An empty batch gets no response at all.
.-> []
(no reply)
Or option 4: Keep option two, with the following clause:
"Implementing batched calls is an optional part of the spec, that
SHOULD be implemented for transports or setups that are unidirectional
and single shot. It MUST NOT be implemented in a setup where a single
endpoint is both client and server."
Thoughts?
Rasjid.
Robert Goldman
> On 12 March 2010 09:11, Matt (MPCM) <wicke...@gmail.com> wrote:
>>
> Or option 4: Keep option two, with the following clause:
>
> "Implementing batched calls is an optional part of the spec, that
> SHOULD be implemented for transports or setups that are unidirectional
> and single shot. It MUST NOT be implemented in a setup where a single
> endpoint is both client and server."
>
I would like to vote for making the batch calls optional, with an api to
establish whether a server supports them.
Speaking personally, right now I have internet socket-based servers (and
clients) in Common Lisp and JavaScript (Mozilla-specific) that I use for
cross-language integration. I follow the JSON-RPC 2.0 spec up to, but
not including batched transports.
It's ok with me if these are just useful internally. I'd be willing to
make them full JSON-RPC servers to the extent of implementing an "I
don't do batch" response, but I really don't have any interest in
implementing the batch transaction protocol.
Best,
r
Matt (MPCM)
a single shared transport... I can see the complication that a blank
array response will generate.
If each peer had a delineated client->server and server->client pipe
that would be one thing, as you then have some context of what the []
means.
Or if each object/array sent was nested in an object expressing the
context... i.e.
{"client_message":{<request object>}"
{"server_message":{<response object>}"
{"client_message":[<request object>,<request object>]"
{"server_message":[<response object>,<response object>]"
{"client_message":[]"
{"server_message":[]"
Then that context is explicitly provided. But it is more overhead,
compared to making those assumptions against just the contents of any
object sent over the pipe.
I would rather see batch become an extension spec, over having part of
the spec and be 'optional'. I am not quite at the point of extracting
batch... just going to take some time to think this through today and
run through things in my mind.
If the result of an empty batch was nothing (and thus treated just
like a batch of notifications)
, this would cause no additional complication. If it returned an error
response object, this would also not be a new behavior, as this could
happen for invalid json batches.
Peer-to-peer clearly doesn't need batch, but other looser coupled
transports do benefit from it.
<Just sort of thinking out loud>...
--
Matt (MPCM)
Matt (MPCM)
->{"client_message":{<request object>}"}
<-{"server_message":{<response object>}"}
->{"client_message":[<request object>,<request object>]"}
<-{"server_message":[<response object>,<response object>]"}
->{"client_message":[]"}
<-{"server_message":[]"}
--
Matt (MPCM)
Rasjid Wilcox
> Or if each object/array sent was nested in an object expressing the
> context... i.e.
> {"client_message":{<request object>}"
> {"server_message":{<response object>}"
> {"client_message":[<request object>,<request object>]"
> {"server_message":[<response object>,<response object>]"
> {"client_message":[]"
> {"server_message":[]"
>
> Then that context is explicitly provided. But it is more overhead,
> compared to making those assumptions against just the contents of any
> object sent over the pipe.
Layering protocols or providing some kind of envelope is certainly one
way to go, and was my original thoughts in terms of doing a
bi-directional version. But once Roland posted the Json splitter, I
went that direction. The advantage of just splitting the stream
(rather than having an separate envelope) is that you can have a
single server that can talk to various types of plain tcp/ip jsonrpc
clients, and not have to 'switch' modes.
> I would rather see batch become an extension spec, over having part of
> the spec and be 'optional'. I am not quite at the point of extracting
> batch... just going to take some time to think this through today and
> run through things in my mind.
>
> If the result of an empty batch was nothing (and thus treated just
> like a batch of notifications)
> , this would cause no additional complication. If it returned an error
> response object, this would also not be a new behavior, as this could
> happen for invalid json batches.
What is the official reply to a batch of notifications? It is not
clear to me from the spec, although I think that no response is the
most consistent with the rest of the spec, rather than an empty
array.
If so, the following is consistent:
-> [ <request>, <notification> ]
<- [ <response> ]
-> [ <notification> ]
(no response)
-> []
(no response)
In summary, a batch generates an array of response objects if and only
if there is at least one (non-notification) request in the batch sent.
If there are no requests (ie, there are only notifications or the
array is empty) the server must not send a reply (except in the case
of a parse error - in which case it didn't really 'get' a batch
request at all).
This should work okay in all the contexts I can think of, including
peer-to-peer.
> Peer-to-peer clearly doesn't need batch, but other looser coupled
> transports do benefit from it.
Although bidirectional peer-to-peer does not need batch, there are
certainly types of plain tcp/ip implementations that could benefit
from it.
I think the biggest complexity that arises from plain tcp/ip
implementations are the number of possibilities. One can think of at
least the following variations:
1) Uni-directional, single shot. (ie, a single request / response per
tcp/ip connection. I think Roland's implementation falls into this
category.)
2) Uni-directional, sequential pipelined. (ie, multiple requests per
connection, but requests are processed and replied to in order)
3) Uni-directional, async piplelined. (ie, multipile requests per
connection, may be processed in any order. Responses may come in any
order.)
4) Bi-directional, sequential pipelined (as (2), but requests and
responses can flow either direction)
5) Bi-directional, async piplelined.
Note that none of the above makes any assumption about which side
initiates the tcp/ip connection. It is certainly possible to have a
uni-directional single-shot setup where the server initiates the
connection to the client, and the (listening) client then makes a
request, processes any response, and then closes the connection.
Batch calls can add value in setup (1), where they provide much of the
advantages of pipelining, without the complexities of having to
manually split requests.
In order to make different tcp/ip implementations compatible, clients
need a way to both tell the server what they can (or can't) do, and
find out what the server can (or can't) do. I'm thinking of an
rpc.capabilities extension, but that is probably a topic for another
day (and another thread).
Cheers,
Rasjid.
Matt (MPCM)
complications and muddies the water. I should have listened to Lorenzo
sooner ;)
So it looks like the final result is that an empty batch or a batch of
notifications should return nothing.
I'll let anyone else chime in over this, but I'll plan on updating the
spec to make this clear (as well as examples).
--
Matt (MPCM)
Matt (MPCM)
Is there a reason you do not want to implement batch support in your
servers?
Just curious, as I've found it trivial to add in my implementations...
--
Matt (MPCM)
Rasjid Wilcox
I can't speak for Robert, but I actually had to redesign my
implementation somewhat to support batch calls, since without batch I
could just dispatch calls to the worker pool of threads, and once each
call was processed the relevant worker could just send a response
directly to the connection, whereas with batch calls the worker has to
place each result into the overall batch object, and check if all
batch items had been processed, and only then send of the result. It
all ended up being much more of a hack that I would have liked. Some
refactoring could certainly clean it up, and waiting until the entire
batch has been received before starting processing (as I think we have
decided needs to happen, so that we can return the correct response to
any parse errors) will help too, but depending on the implementation
it is not always completely trivial to add. At some point I am
looking to do an implementation in Kamaelia, and batch calls will
definitely add a degree of complication there that would not exist
without them.
Cheers,
Rasjid.
Rasjid Wilcox
On reflection, we do still have a choice to make.
As long as an array of notifications returns nothing (as opposed to an
empty array), then an empty array should never be returned by the
server. So even in a peer-to-peer setup, we are free to declare
sending an empty array to be an error.
Thus we have a choice between one of the original suggestions:
->[]
<-{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request"}, "id": null}
and
-> []
(no response from server)
The only purpose for the second option would be to enable its use as a
heartbeat / keep-alive signal, but in many ways that is really
stepping into the domain of the *transport*, and has nothing to do
with jsonrpc itself. As a jsonrpc message, [] is pretty meaningless,
being an envelope with nothing inside. Personally, from an
implementation perspective, I don't mind either way. But I think the
first option probably gives a cleaner spec. If sending [] is allowed,
but it has no meaning within the spec, then someone in some
implementation will give it meaning, and we start to get
incompatibilities.
So I think either we explicitly say that [] is allowed and can be used
as a heartbeat (which returns *no* response), or we declare it an
error. Either way it should not be the response to an array of
notifications.
Cheers,
Rasjid.
Lorenzo Pastrana
Then my question would be : what is a heartbeat mechanism (that isn't simply a notification) actually needed for ?
Lo.
Matt (MPCM)
I think it makes the most sense to return an error object (perhaps a
new -32604 invalid batch error or if not then -32600). This way we
widen the description of input to be a Request Object or an array of
Request Objects. The handling would swap from single to batch return
after that initial test of if the input is a non-empty array.
Any desire to implement a heart beat could be done easily enough via a
method call (notification or otherwise).
--
Matt (MPCM)
Matt (MPCM)
that an empty array should require a single response object (an
error). If we can determine that the array has at least one item, even
if that item is not a valid request object, it should be returning any
responses as part of the array.
I had posted this a few days ago, but it seems googlegroups ate them
(or I hit reply-to-author by mistake, but I doubt that somewhat).
--
Matt (MPCM)
Rasjid Wilcox
> To follow up and close out this thread... I have update the spec so
> that an empty array should require a single response object (an
> error). If we can determine that the array has at least one item, even
> if that item is not a valid request object, it should be returning any
> responses as part of the array.
Hi Matt,
There needs to be something said to the effect that:
The server MUST NOT return an empty array in response to a batch call.
It should either return an error, or a non-empty array of responses.
In particular there should be no response (at all) to an array of
notifications.
An example of an array of notifications getting no response would be good too.
Without something along the lines of the above, it falls apart for the
case of peer-to-peer.
Cheers,
Rasjid.
Matt (MPCM)
have added phrasing to show the intent. If not, the examples spell it
out for now.
--
Matt (MPCM)
Rasjid Wilcox
Seems clear enough. Thanks for that Matt.
Cheers, Rasjid.