[sr-dev] xmlrcp request takes very long time

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


On 06-07 23:16, Raúl Alexis Betancor Santana wrote:
> On Monday 06 July 2009 22:50:38 Andrei Pelinescu-Onciul wrote:
> > On Jul 06, 2009 at 22:37, Ra?l Alexis Betancor Santana 
> <rabs at dimension-virtual.com> wrote:
> > > On Monday 06 July 2009 21:41:40 Juha Heinanen 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.
> > >
> > > I also doub that xmlrpclib it's the problem
> >
> > Being standard HTTP, the xmlrpc client should close the connection after
> > receiving the answer (if it doesn't want a connection persistent mode)
> > and not the reverse.
> 
> But server is sending a response not ended by CR+LF, so client doesn't know 
> that it must close the connection and also as serving HTTP/1.0 resquest 
> server MUST close the connection when it send its response.

Where in the RFC do you see the MUST? The closest thing that I can find in the
HTTP/1.0 RFC is that "except for experimental setups, current practise
requires that the server closes the connection after sending the response".

And further in the text, it is said that if Content-Length is present in the
reply, the header field is used to determine the end of the reply, not the end
of the connection. 

> What I see is that server is sending out HTTP/1.0 responses so you could NEVER 
> have a client that could wait for persistent connections because if it does, 
> it will be breaking HTTP/1.0 RFC

Not true.

   Jan.



More information about the sr-dev mailing list