[sr-dev] xmlrcp request takes very long time

Jan Janak jan at iptel.org
Tue Jul 14 14:05:37 CEST 2009


On 06-07 22:46, Raúl Alexis Betancor Santana wrote:
> 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.

I tend to disagree. The RFC you refer to says that if the response carries
Content-Length header field then the value of the header field determines the
end of the reply. If there is no Content-Length header field in the reply then
the reply is complete when the server closes the connection. Even for HTTP/1.0
requests and responses.

This really is a bug in the xmlrpc client library, because it ignores the
Content-Length header field. Unfortunately it is not triggered by most other
servers because they close the connection immediately.

> Could someone try to check what happens if transport is HTTP/1.1 instead of 
> HTTP/1.0 ? 

Nothing, in fact the xmlrpc module returns in reply whatever the client sent
in the request.

   Jan.



More information about the sr-dev mailing list