[JSpecMugen]

I'm using prototype Ajax.Request for the task...

Code:

var request = new Ajax.Request("http://10.1.2.143:8081/jsonrpc", {
        method: "post",
        parameters: { jsonrpc: "2.0", method: "JSONRPC.Introspect", id: 1},
        onSuccess: function(transport) {
            console.log(transport);
        }
});

The response I get is a -32700 Parse Error...

Anyone out there familiar with this method, and what I may be doing wrong?

Thanks!

[topfs2]

JSONRPC exist on http://IP:PORT/jsonrpc which is not what you are requesting

[JSpecMugen]

JSONRPC exist on http://IP:PORT/jsonrpc which is not what you are requesting

Sorry, that was a typo... My code reflects the edit I made above. Still without a response.

[Montellese]

You need to put the field names like "jsonrpc", "method" and "id" between quotation marks. You're request should look like this;

Code:

{ "jsonrpc": "2.0", "method": "JSONRPC.Introspect", "id": 1}

[JSpecMugen]

You need to put the field names like "jsonrpc", "method" and "id" between quotation marks. You're request should look like this;

Code:

{ "jsonrpc": "2.0", "method": "JSONRPC.Introspect", "id": 1}

No, that is merely a formatting situation for the language you're using. In JS the object is properly serialized and this is how I format requests to other JSON-RPC 2 setups.

With all the testing/hacking/playing/fiddling/etc I've done, what I've come to find is that Prototype for some reason adds a trailing &_= onto the POST body of the request.


topfs2, As I said above, using Prototype on requests to other JSON-RPC implementations, I don't have this issue... It seems the XBMC JSON implementation is somewhat strict. Would you consider losing the noose and dropping any and all data after the id:<var> variable?

JSON-RPC 2.0 recognizes the order in which items must appear, so if you drop any and all pairs after the id variable, it wouldn't cause any harm or deviate from the specification.

Tell me what you guys think...

[topfs2]

No, that is merely a formatting situation for the language you're using. In JS the object is properly serialized and this is how I format requests to other JSON-RPC 2 setups.

With all the testing/hacking/playing/fiddling/etc I've done, what I've come to find is that Prototype for some reason adds a trailing &_= onto the POST body of the request.


topfs2, As I said above, using Prototype on requests to other JSON-RPC implementations, I don't have this issue... It seems the XBMC JSON implementation is somewhat strict. Would you consider losing the noose and dropping any and all data after the id:<var> variable?

JSON-RPC 2.0 recognizes the order in which items must appear, so if you drop any and all pairs after the id variable, it wouldn't cause any harm or deviate from the specification.

Tell me what you guys think...

Json is an object, the order does not matter. Please pastebin a log when it fails.

[JSpecMugen]

Json is an object, the order does not matter. Please pastebin a log when it fails.

Sorry, maybe I read the specification wrong. I thought I saw somewhere that the order in which the post args were sent were important.

There's not much to pastebin...

Here's the post.body that my request sends:

Code:

[20101221-13:40:08.186321] info: onSuccess: Body of POST: jsonrpc=2.0&method=JSONRPC.Introspect&id=1&_=, app/assistants/first-assistant.js:66

It does this for any and all requests that I send using the Prototype library. So I'm trying to figure out with my guys on the Prototype/JS side why It's doing this, but on your end you're being too strict about it. Like I said, on other JSON-RPC implementations, I don't have issues with the trailing &_= ...

[topfs2]

There's not much to pastebin...

let a developer be the judge of that, its not like we don't put information in the logs for us...

[JSpecMugen]

let a developer be the judge of that, its not like we don't put information in the logs for us...

You misunderstood. I'm not putting down pastebin or anything... I was just saying the logged output from my application doesn't have much more than one or two lines relevant to my issue...

[kaiser423]

You misunderstood. I'm not putting down pastebin or anything... I was just saying the logged output from my application doesn't have much more than one or two lines relevant to my issue...

He means from the xbmc log....