Discussion on json-rpc-over-http

[Matt (MPCM)]

Looking at this I think we should have the option to take the entire
query string as a json encoded object, in addition to the method=,
id=, param= and jsonrpc= naming style

A few examples in this seem little off, as they don't include the
jsonrpc="2.0" item, but pass an object as the param.

Hoping to start conversation around these recommendations. Given the
ZF version, Roland's release, and my pending php release it probably
makes sense to iron this out as the 2.0 json-rpc solidifies.

--
Matt (MPCM)

[Tom Robinson]

I realize JSON-RPC error code might not map perfectly, but I have a
few suggestions...

HTTP status 405 ("Method Not Allowed") might be more appropriate for
-32601 ("Method not found."), rather than 404 (which means the
*resource* was not found)

Also, 500 ("Internal Server Error") doesn't seem appropriate for
-32602 ("Invalid params") or -32700 ("Parse error."), both of which I
think should be considered 400 ("Bad Request")

[Alexandre.Morgaut]

HTTP status codes for RPC errors :

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

4xx codes means client's errors
5xx codes means server's errors

-32601 (Method not Found) :

KO
- the 405 status code doesn't match as it refers to the HTTP protocol
methods (method specified in the Request-Line)
- the 404 status code should only match if each methods refered to a
different URL which is only the case in JSON-RPC when using the GET
method

OK
- the 400 -> "The request could not be understood by the server due
to malformed syntax. The client SHOULD NOT repeat the request without
modifications."
- 461 custom code mixed from 400 and -32601. HTTP clients not
understanding a custom 4xx code have to interpret it as a 400 status
code

I agree that it should be applied to -32602 ("Invalid params") and
-32700 ("Parse error.") with 400 or respectively 462 and 470

HTTP specification is ok with the use of custom status code but we
have to consider to which default behavior it will end (400 Bad
Request or 500 Internal Server Error)

5xx error code should only occur when the client call an existing
procedure with correct parameter in a correct JSON format, and the
server can't handle at this time (bug in the code of the procedure,
database unreachable, server overloaded or down...)

My proposal would then be :

-32700 -> 400 (or 470) Parse error.
-32600 -> 400 (or 460) Invalid Request.
-32601 -> 400 (or 461) Method not found.
-32602 -> 400 (or 462) Invalid params.
-32603 -> 500 (or 563) Internal error.
-32099..-32000 -> 500 Server error.

JSON-RPC doesn't really requires custom status code as it will be read
in the JSON
The only requirement looks to be the distinction between 400 and 500
errors. If a HTTP client receive a 400 HTTP response he may refuse to
send it again without changes

[Alexandre.Morgaut]

About the Content-Type

I think JSON-RPC would gain using a mediatype like :

application/rpc+json

A more explicit alternative may be :

application/rpc-request+json
application/rpc-response+json

with a last candidate :

application/rpc-notification+json

The "+json" suffix would be a good benefit for all JSON formats as the
"+xml" is for XML
HTTP Client, servers, and all MIME compliant technologies (like
emails)
would be able to provide a default renderer for all json formats and
could be sure that this format is plain text without binary bytes
inside
(which is a useful information)

[Alexandre Morgaut]

HTTP response status code for Batch RPC requests

To be able to send a response to a batch requests without waiting the
result of all the requested method, the server will have to send the
status line just before the first result.

So, for batch request I suggest that the returned status code should
be :
- 400 (Bad Request) : When the JSON isn't valid or is not a valid RPC
request/batch request
- 200 (OK) : the batch request is successfully launched (this does
not guaranty the success of the batched procedures)

[Matt (MPCM)]

I've been avoiding the whole mapping json-rpc codes to http status
codes for the moment, but I agree with what you have posted, and
specifically with the related batch http codes.

--
Matt (MPCM)

[RedHog]

I have two issues with JSON RPC 1.0 over HTTP specification:

* It does not address how to handle sessions (cookies? URL encoded
session id?).

* It does not address RPC calls from the server to the webbrowser,
only in the other direction.

The first should be pretty straight forward - just write down what
people are already doing.

The second one on the other hand would be good to have some discussion
around. From what I can read out of the the standard, nothing forbids
multiple messages in the same HTTP request, so a server could
theoretically wait until the client sends a request and piggy back its
call on the response. One solution would then be to mandate that a
client always has one request open, waiting for a response, and opens
a new one (empty, with no calls, notifications or responses in it if
need be) as soon as the last one is closed. What are your ideas on
this?

I haven't read much of the 2.0 spec, how does these two apply to that?

[Matt (MPCM)]

Session tokens are something that you would handle with the transport
using cookies/url. Or it is something that needs to be part of your
API as a parameter.

It is more of an api design decision. I usually recommend designing
your api without requiring it, then using a proxy json-rpc server that
then requires it for transports without the ability to communicate it
indirectly (if you are using such transports). You can easily do the
reverse also.

I guess it also depends if you expect to change the token per request
object, and how that might work in a comet style application... These
parts are not defined because there is also the concept that you are
making stateless calls... so this is not an issue for everyone.

On your second point, the json-rpc server does not have the ability to
invoke anything on the client in 2.0. If you reverse the roles where
the browser is the json-rpc server, then it is basically a transport
limitation which you could get around using comet, or having the
client/server implementation in the code working in concert. json-rpc
is just the middle glue for all these calls, it is easy enough to
write a client that uses json-rpc and your servers api's to let the
client call the shots.

Until we have web sockets, and even then, the browser is going to have
to act like a polling client at best. Mandating that the client has
one request open would not be reasonable for the spec to do IMO. But
in practice it may be what you require of your clients... if you
control both ends.

I too would like to see more discussion around this, especially once
2.0 is stamped : )

--
Matt (MPCM)

[RedHog]

Ok, so 2.0 is client-server, not peer-to-peer. Seems like I should
stay with 1.0 then, I chose JSON-RPC precisely for this reason, very
few other RPC-protocols are peer-to-peer. After some more reading in
this forum, I have seen other people critize this too. So: Why did the
designers of 2.0 chose to go down that path? Is it because in
practice, JSON-RPC turned out to nearly only be used over HTTP, where
this divission is half enforced by the transport layer, or are there
more interesting reasons?

Also, JSON-RPC 1.0 over sockets provides an implicit session. I find
it strange that you would not require, or at least provide for it as
an option, that the transport layer provides sessions.

[BYK]

As far as I understand the protocol, anything RPC is server-client
since the "procedure provider" listens the requests and performs them.
You can emulate a "peer-to-peer" system by implementing server threads
on both sides and agreeing on authentication which IMO is not subject
to json-rpc specs.

[RedHog]

BYK: Not neccessarily: RPC just means remote procedure calls. Any
single procedure call can be said to have a server (the one performing
the procedure) and a client (the one calling it), but that is
stretching it a bit, as there is nothing in the concept of RPC that
dictates that all calls needs to go in the same direction.

I think that the gist of the change between 1.0 and 2.0 is in the
change of slogan from

"JSON-RPC is a lightweight remote procedure call protocol. It's
designed to be simple! The general mechanism consists of two peers
establishing a data connection. During the lifetime of a connection,
peers may invoke methods provided by the other peer."

to

"JSON-RPC is a stateless, light-weight remote procedure call (RPC)
protocol."

You might be right in that JSON-RPC 2.0 allows both sides to be both
server and client (up to the implementor of the spec), but the
statelessness (sessionlessness) and "one shot" (one call per
connection, or queued up batches, not interleaving asynchronous
messages) nature sure makes it better for HTTP based transports and
takes less advantage of the implicit sessions of socket communication,
leaving non-browser based peer-to-peer usages out in the cold.

[BYK]

Well, for the server-client thing we are actually telling the same
story. You can use JSON-RPC in both ways, there is nothing restricting
that both in v1 and v2.

Also, when you use a socket connection, you are still having a server
and a client where, the server cannot send data to the client unless
the client have requested something. This is the case I had with my
work on TCP components years ago. when you come to UDP, then you can
do what you want with JSON-RCP again.

[RedHog]

> Also, when you use a socket connection, you are still having a server
> and a client where, the server cannot send data to the client unless
> the client have requested something. This is the case I had with my
> work on TCP components years ago. when you come to UDP, then you can
> do what you want with JSON-RCP again.

Why would that be? The only division you have is who initiates the
session. After the TCP-connection is set up, data can be sent in both
directions, asynchronously, until either party disconnects. Of course
data in both directions can be formatted as JSON, and be JSON
requests, responses or notifications, and there need not be any timing
relationship between sent data and received data - the pairing of
requests and responses is done with the id parameter.

I guess that we either are talking past each other, or that you
presume that each TCP connection can only contain one request and one
response, and must be held open until the response is sent. There is
no such presumption in JSON-RPC 1.0, but there seems to be in JSON-RPC
2.0...

[BYK]

To be able to immediately receive messages in a TCP connection, you
need a thread which continuously listens a port which makes that
thread some kind of server, I was trying to explain this behavior =)

I do not presume one request per TCP connection and I cannot see
anything in the version 2 definition which implies this. Can you give
an exact phrase and explain why you think it presumes a RESTful
connection?

[RedHog]

> I do not presume one request per TCP connection and I cannot see
> anything in the version 2 definition which implies this. Can you give
> an exact phrase and explain why you think it presumes a RESTful
> connection?

Hm, maybe it's actually me presuming things here :P *reads the spec
thoroughly again*

"JSON-RPC is a stateless..."

This seems to be what I've been hanging a whole bunch of presumptions
on. What exactly does this imply?

And: Unless there is an implied session (by a single HTTP request, a
SID cookie, a single TCP connection, or something similar), what is
the domain of the id field? That is, among which messages does it have
to be unique?

Isn't the fact that a request has been made with a specific id, and no
response has been received with the same id, to be considered a state?
If it is, and we require the protocol itself to be stateless (for any
useful meaning of the word), the response has to be sent in the same
message (HTTP connection or the like).

[RedHog]

Actually, I should add that part of my impression of the RESTishness
comes from the discussion on batch mode and the interpretation of Null
as id expressed in various discussions (not in the 2.0 document):
http://groups.google.no/group/json-rpc/browse_thread/thread/ae7be68476b6c235?hl=nn
At least in that discussion people seem to presume a RESTfull semantic
where each call is paired with a response in the same HTTP connection.

[Matt (MPCM)]

I know this is the json-rpc over http thread, but we had thought in
the past that it was important to separate the json-rpc rules/behavior
and the transports. The 2.0 spec was put together to talk about
behaviors and data structures, leaving the specifics of dealing with a
transport to the users own best-practices which may or may not get
published. 2.0 aims to transport agnostic for lots of reasons...

You might be doing it over http and expect a 1 request to 1 response
for one connection. You might use comet or polling and have messages
coming in and going out over different connections and possibly
transports. There are sockets to be considered. There is XHR and
iframes. HTML5 talked of WebSockets... there could be no transport if
you are running json-rpc client and server within modules within the
same language execution scopes.

In my mind this underlines need for the devision of client and server
roles, as the client is the keeper of its outstanding request ids.

Any assumptions over how to use it with a specific transport are
currently mostly undefined, and outside of the scope of the core spec.
So none of the posts thus far are really wrong, or right... these are
things that just have not been well defined by the community yet.

The question is how do you use or want to use json-rpc over a specific
transport. What makes sense for that transport... which is the purpose
of this thread in the case of http.

--
Matt (MPCM)

[Matt (MPCM)]

> In my mind this underlines need for the devision of client and server

Division would be good also. :)

--
Matt (MPCM)

[Alexandre Morgaut]

> You might be doing it over http and expect a 1 request to 1 response
for one connection.

Just in case some people forgot or ignore it :

HTTP allow persistent connection with keep-alive parameters, meaning
that several JSON-RPC request can be sent over HTTP to a single TCP
connection

[Alexandre Morgaut]

Reflexions about JSON-RPC over HTTP GET
(base64 encoding, batch, HTML forms)


Base64 encoding & HTML forms :

I know this spec and the previous 1.0 and 1.1 versions from quite a
time

I was first a bit surprised to see the new version requiring base64
encoding for parameters in the URL but didn't go forward immediately
as the first main change which hit me, even if I understood it, was
the embedding of all the parameters in a single params GET variable in
the query string
(cf: http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html)

My main problem is that there is no way left to generate a HTML form
doing a valid JSON-RPC request without JavaScript (unless the method
doesn't require any parameter), but this allow to specify any
parameter complex values (object, arrays..) as you might want instead
of being limited to scalar values

So, as far as I can see, any valid JSON value set to params in the
POST version should be safely URL encoded in the Query String without
the need of base64.
If this choice was done for obfuscation, it looks even more useless
than when its done in the HTTP basic authentication (where it might be
needed as there is no URL encoding)

Hopefully, there is some public JavaScript base64 libraries, but its a
pity to loose precious time encoding and decoding base64 when we try
to improve performance using the cachability of the GET HTTP method




Batch :

Batch request are easy to send over the GET method and can be useful
to receive cachable set of values from a single HTTP request
All we have to do looks to be :
http://<end point>?batch=<encoded JSON-RPC batch array>

And it should work also with or without the base64 encoding

The problem is JSON Hijacking. If a hackers puts in an evil.com page
<script src="http://<other domain JSON-RPC url>?batch=<encoded JSON-
RPC batch array>"></script>
the browser will parse the response as JavaScript code and call the
Array constructor which as been overloaded by the hacker

Browsers preserve the HTTP authentication and cookies for other
domains request, so any JSON-RPC batch request made from this tag in
evil.com will work if the visitors is connected on the JSON-RPC
provider website
a first security would be the check of the Accept HTTP header field,
but if the hacker do this :
<script src="http://<other domain JSON-RPC url>?batch=<encoded JSON-
RPC batch array>" type="application/json-rpc"></script>
some stupid browsers will set the HTTP header but will still parse the
result with the JavaScript parser

So, to secure this security hole and still provide GET support for
batch, we have two solution :

- embed the array batch results in a JSON object :

--> [ {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id":
"1"},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
{"jsonrpc": "2.0", "method": "subtract", "params": [42,23],
"id": "2"},
{"foo": "boo"},
{"jsonrpc": "2.0", "method": "foo.get", "params": {"name":
"myself"}, "id": "5"},
{"jsonrpc": "2.0", "method": "get_data", "id": "9"} ]

URL encoded in the Query String of the GET request


<-- {"no-hijack":[ {"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "result": 19, "id": "2"},
{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid
Request."}, "id": null},
{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method
not found."}, id: "5"},
{"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"} ]}

response when the request is done by a GET HTTP request


- check a specific HTTP header that can't be done by the HTML script
tag like "X-Json-Hijack: false":

GET /rpc?batch=<encoded JSON-RPC batch array> HTTP/1.1
Host: http://rpcserver.com
X-Json-Hijack: false


- check the referrer HTTP header field value (might be too
restrictive in soma cases)

[Max Kanat-Alexander]

* Why does the GET specification require Base64-encoding of params?
I'm an implementer on the client and server side, and in JavaScript
clients, not only is base64 encoding difficult, it's unnecessarily
time-consuming and adds complexity. Why not just urlencode the params?

* The mapping of errors to HTTP status codes seems like an unnecessary
complexity from both the client and server implementation viewpoint.
One part of XML-RPC that I've never had a problem with is that it
always returns a 200 unless there is a significant underlying error,
and the RPC client deals with the error by the error code in the RPC
protocol.

* The requirement to specify an id in a GET adds complexity for
consumers of an API. The *essential* data that a server needs in order
to formulate a response is just the "method" and "params", and the id
is nice, but not actually necessary except for the existence of
"notifications" in the base JSON-RPC spec. Perhaps notifications
should be indicated via an HTTP client header instead, or by the
client simply choosing to ignore the return value.

-Max

[Derrell Lipman]

On Thu, Jun 3, 2010 at 21:53, Max Kanat-Alexander <mka...@bugzilla.org> wrote:

* The requirement to specify an id in a GET adds complexity for
consumers of an API. The *essential* data that a server needs in order
to formulate a response is just the "method" and "params", and the id
is nice, but not actually necessary except for the existence of
"notifications" in the base JSON-RPC spec. Perhaps notifications
should be indicated via an HTTP client header instead, or by the
client simply choosing to ignore the return value.

More than one JSON-RPC request can be outstanding at one time. If the client issues two requests, and the first one takes longer for the server to process than the second one, the response to the second will be returned to the client before the response to the first one. The id values that was passed to the server in the request is passed back to the client in the response. The client is then able to associate which request the received response applies to. Without the id value, the client wouldn't know which request the response is in response to.

Derrell

[Erik Nedwidek aka Raycaster]

On Thu, Jun 3, 2010 at 9:53 PM, Max Kanat-Alexander <mka...@bugzilla.org> wrote:

* Why does the GET specification require Base64-encoding of params?
I'm an implementer on the client and server side, and in JavaScript
clients, not only is base64 encoding difficult, it's unnecessarily
time-consuming and adds complexity. Why not just urlencode the params?

They are base64 encoded and then url encoded if I'm reading the spec right. Base64 would make for smaller payloads when doing binary data. Nine bytes of verbotten characters would be 27 bytes in url encoding or 12 in base64 (plus bytes for any url encoding that needs to be done). I don't know the history of the this decision, so the original idea may be different. There are plenty of libraries for each language for encoding and decoding so you shouldn't need to do the heavy lifting yourself. Granted I've had to write encoders and decoders for JavaScript, Java, Perl, Ruby, and PHP because the company at the time wouldn't even think of using even MIT or BSD licensed code. It's not horrible, but you're right it isn't a cake walk.
 

* The mapping of errors to HTTP status codes seems like an unnecessary
complexity from both the client and server implementation viewpoint.
One part of XML-RPC that I've never had a problem with is that it
always returns a 200 unless there is a significant underlying error,
and the RPC client deals with the error by the error code in the RPC
protocol.

 
My understanding is that the mapping is important to someone creating a generic client library that can connect to an http endpoint. If the server responds with something other than 200, the client is going to need to create a JSON-RPC error object. Mapping makes the errors transport agnostic. XML-RPC is always over HTTP by their spec. Therefore no need to be agnostic.

* The requirement to specify an id in a GET adds complexity for
consumers of an API. The *essential* data that a server needs in order
to formulate a response is just the "method" and "params", and the id
is nice, but not actually necessary except for the existence of
"notifications" in the base JSON-RPC spec. Perhaps notifications
should be indicated via an HTTP client header instead, or by the
client simply choosing to ignore the return value.

Darryl amply explained this one. The spec allows batch requests and the server to do returns out of order.

One thing to remember is that the "over HTTP" is for JSON-RPC 1.2. Once 2.0 is finalized the plan I believe is to revisit 'over HTTP'. So keep bring up things to think about. I've seen this community to be incredibly receptive.


--
Erik Nedwidek

The beauty of PHP is that it is so simple even an idiot can program with it. The problem with PHP is that so many idiots do choose to program in it.

- "Code Monkey think maybe manager would like to write god damned login page himself", Code Monkey by Jonathan Coulton.

- I USHERED SOULS INTO THE NEXT WORLD. I WAS THE GRAVE OF ALL HOPE. I WAS THE ULTIMATE REALITY. I WAS THE ASSASSIN AGAINST WHOM NO LOCK WOULD HOLD.
- "Yes, point taken, but do you have any particular skills?"
     -- Death consults a job broker (Terry Pratchett, Mort)

[Max Kanat-Alexander]

On 06/04/2010 04:07 AM, Derrell Lipman wrote:
> More than one JSON-RPC request can be outstanding at one time. [snip]

> Without the id value, the client wouldn't know which request the
response is in response to.

Ah, yeah, sorry, I should have been clearer. I did know that this was
one of the purposes of the "id" field. I was just pointing out that it's
not *strictly* necessary, and so it shouldn't be *required*.

On 06/04/2010 08:54 AM, Erik Nedwidek aka Raycaster wrote:
> They are base64 encoded and then url encoded if I'm reading the spec
> right. Base64 would make for smaller payloads when doing binary data.

> [snip]

Yes, that's correct. "Make for smaller payloads" in a *specification*
sounds like a premature optimization, though. Also, normal JSON encoders
usually already encode binary data as base64, so you'd just be
double-encoding in the binary case.

> There are plenty of libraries for each language for encoding
> and decoding so you shouldn't need to do the heavy lifting yourself.

Yes, but it's not strictly necessary, so it probably shouldn't be in
the specification. Just because something is *possible* for an
implementer to do doesn't mean that it's a good idea to add that
additional complexity. If an implementation feels the need to optimize
in that way, then it can specify that in its API docs. Or you could do
an extension spec that specifies params64, or params_encoding, even.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

[Rasjid Wilcox]

On 4 June 2010 11:53, Max Kanat-Alexander <mka...@bugzilla.org> wrote:
> * The requirement to specify an id in a GET adds complexity for
> consumers of an API. The *essential* data that a server needs in order
> to formulate a response is just the "method" and "params", and the id
> is nice, but not actually necessary except for the existence of
> "notifications" in the base JSON-RPC spec. Perhaps notifications
> should be indicated via an HTTP client header instead, or by the
> client simply choosing to ignore the return value.

Pushing the notification indication into the http header would be
pushing a core part of the spec into the transport layer. This goes
against one of the core tenets of the spec which is that it is
transport agnostic. Also, not all transports have a 'header' that
such a flag could be pushed into.

Cheers,

Rasjid.

[idleSun]

Max made good and important points. I added my thoughts on each one
here:

On Jun 3, 6:53 pm, Max Kanat-Alexander <mka...@bugzilla.org> wrote:
> * Why does the GET specification require Base64-encoding of params?
> I'm an implementer on the client and server side, and in JavaScript
> clients, not only is base64 encoding difficult, it's unnecessarily
> time-consuming and adds complexity. Why not just urlencode the params?
>

I agree. Actually, I believe that base64 encoding should not be there
at all because it is for transporting binary data in text stream and
JSON is basically text. Only exception is for a specific param that
holds binary data. However even in that case, base64 encoding should
be applied to the specific param value only. Another reason why base64
encoding is removed is that many HTTP tools take care of URLencoding
automatically but not base64. So, it you want to use tools like SoapUI
for testing or anything else, you can not take full advantage of the
tools because of unnecessary base64 encoding.

> * The mapping of errors to HTTP status codes seems like an unnecessary
> complexity from both the client and server implementation viewpoint.
> One part of XML-RPC that I've never had a problem with is that it
> always returns a 200 unless there is a significant underlying error,
> and the RPC client deals with the error by the error code in the RPC
> protocol.
>

I agree. One of key characteristic of JSON-RPC is Transport-agnostic.
If client needs to handle HTTP status code than it will make the
implementation transport-dependent. I want to have same error handling
code implementation regardless of my transport so that I can use the
same code when the transport is switched something else like
WebSocket.

> * The requirement to specify an id in a GET adds complexity for
> consumers of an API. The *essential* data that a server needs in order
> to formulate a response is just the "method" and "params", and the id
> is nice, but not actually necessary except for the existence of
> "notifications" in the base JSON-RPC spec. Perhaps notifications
> should be indicated via an HTTP client header instead, or by the
> client simply choosing to ignore the return value.
>

Client may not need id because request and response are paired in HTTP
so you don't need to check id. However, from simplicity and
consistency perspective, it make sense to put the first level elements
(jsonrpc, method, params, and id) altogether in the url as query
argument.
Whether client really use it or not can be left out as implementation-
specific. And if client doesn't really need id then it can set it to
one fixed value and use this argument as the flag for request type
message (Notification type message will have no id as per JSON-RPC).
Server wouldn't care because it will just copy the id value blindly
and that is perfect from JSON-RPC spec perspective. Again, my point is
this type of transport specific conversion should be logically simple
and consistent, like all first level elements or whole JSON-RPC
message like POST way.

[Matt (MPCM)]

I'm putting this message here so that people can notice that using
json-rpc with get over HTTP has caused lots of conversations in this
thread. This document can no longer be edit, only deleted due to
changes on google groups. So, read through the other posts on this
subject, because questions and concerns with json-rpc over HTTP with
GET come up a lot. - Matt (MPCM)

[Gordon Freeman]

Слыш, мужики, да вы заебали хуйню писать! Хоть бы кто из вас (по идее,
с большой бувы надо бы, да некого) попытался идею. Хер с ней
спецификацией, вы саму задуску бы воплотили, а то все приложится. Чего
же выы чепуху всякую пишите сюда, тпа высокие материи и т.п.???
Давайте реально задвинем, раскатем пару литров, канистру у меня, к
примеру, оформим. И спеки потом выдинем такие, что пендосы офигеют и
подавятся соплями.

> --
> 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.
>