[sr-dev] xmlrcp request takes very long time

Raúl Alexis Betancor Santana rabs at dimension-virtual.com
Tue Jul 7 00:16:14 CEST 2009


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.

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

> Juha meant only the xml body. All the HTTP header lines are CRLF
> terminated.

And boundary between headers and body ?

> It's true only for the headers. How the body looks depends on what does
> it carry. For the case of xmlrpc it's xml which is quite free-form (you
>  can have the whole xml part on one line if you want to).

Yes, but I was not telling that body must follow cr+lf spec .. I told that 
response should be:

HTTP/1.0
header: value<cr><lf>
<cr><lf>
{xml response(no matter if one line or more)}<cr><lf>
<cr><lf>

It should be easy to check, I don't use xmlrpc on s-r so I could not check it 
by now

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



More information about the sr-dev mailing list