7 Jul
2009
7 Jul
'09
3:46 a.m.
On Monday 06 July 2009 22:50:38 Andrei Pelinescu-Onciul wrote:
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
On Jul 06, 2009 at 22:37, Ra?l Alexis Betancor Santana
<rabs(a)dimension-virtual.com> wrote:
On Monday 06
July 2009 21:41:40 Juha Heinanen wrote:
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. 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 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