[sr-dev] xmlrcp request takes very long time

[Andrei Pelinescu-Onciul]

On Jul 06, 2009 at 23:41, Juha Heinanen <jh at tutpro.com> wrote:
> i may be wrong, but it is hard for me to believe that python xmlrpclib
> would be badly broken, because it is very widely used.

The parser is not broken, it works. The problem is how it uses the
transport by default. It looks like it waits for the remote close before
it starts parsing the reply, which is wrong.

If one changes the transport (like in the example I've sent or in
ser_ctl), then it works perfectly. One has only to create a new
Transport class and then import it in all his code and instead of:

c=xmlrpclib.ServerProxy("http://" + XMLRPC_SERVER+ ":" +
str(XMLRPC_PORT))

use

transport=Transport()
c=xmlrpclib.ServerProxy("http://" + XMLRPC_SERVER+ ":" +
str(XMLRPC_PORT), transport)

(this will removes the wait for the remote close() and it will work also
 with mi_xmlrpc)

Anyway IMHO for more complex applications the default transport should
be changed anyway if there's any need for some sort of security (and for
that a look at ser_ctl will really pay off: you can authenticate the
HTML requests using the transport class defined there and all you need
to do on ser side is to add a www_authorize/challenge in the xmlrpc
 route).

> 
> if i look more closely at body of sr response:
> 

[...]

> 
> i notice that each body line is terminated only by one char (cr or lf)
> and the last line is not terminated by any char.  content-length 108
> seems to verify this.
> 
> i don't know if it is ok that lines end with only one char and that the
> last line does not end with anything.

The separator doesn't matter as long as it's some kind of whitespace.
We can even get rid of all of them (everything on one line) and it
should still work.
> 
> for comparison, mi xmlrpc module terminates each body line (including
> the last) with both cr and lf:
> 

Try the latest sr version and add at the end of the xmlrpc route
 a return -1 or drop -1 (e.g.: route[XMLRPC]{dispatch_rpc(); drop -1; })
and it should close the connection after sending a reply.
(I've come to the conclusion that is faster to implement it then
answering to emails :-)).
You could even do the return -1 only if the user agent is xmlrpclib.py
(so that non-broken clients would still be able to keep 1 open
connection and send xmlrpc requests on it).


Andrei