[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