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