[sr-dev] xmlrcp request takes very long time

[Raúl Alexis Betancor Santana]

On Monday 06 July 2009 22:13:27 Andrei Pelinescu-Onciul wrote:
> 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)

Umm, re-checking your example and the responses that Juha pasted ... you are 
wrong, I explain myself ...

xmlrpc responses are sended as HTTP/1.0 transport, SO AS PER HTTP/1.0 RFC, 
only ONE request/response per conection are allowed so xmlrpclib is waiting 
for the remote end to close the conection because it see HTTP/1.0 on the 
headers.

Could someone try to check what happens if transport is HTTP/1.1 instead of 
HTTP/1.0 ? 
I think that will run without having to change "transport" on the python 
script.

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

I use twisted when developing that kind of apps, so transport and security 
it's covered by the framework.

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

It matter for the headers/body boundary and for the body/endDoc boundary, you 
are right saying that you could send the response in one line if you want, 
XML-spec's allows that, BUT not for the HTTP transport

-- 
Raúl Alexis Betancor Santana
Dimensión Virtual