Re: Getting xml-rpc and w.bloggar to work

On Wed, 2003-08-13 at 23:04, will wrote:
> Hmmm...  seems really fishy to me.  Basically you're saying that flush
> doesn't do anything for stdout.  Why is this an issue only with xmlrpc
> stuff?  Theoretically, this should affect everything that uses cgi, right?

Yes, but somehow, without content-length, the client program seems to
wait until the connection is closed and gathered all the data.

> I suspect the issue is something else.  Are you sure the Content-Length is
> set correctly?  When I look at the code it seems that you set the
> Content-Length to the size of the response, but then send the response and
> an extra CR.  Are you sure it's not an off-by-one issue?  Where did you
> put the sys.stdout.flush()?

Like I said in the earlier mail, I tried a lot of things, even to
setting content-length to len(response) * 2, wait I get is a delayed
action from w.bloggar, and 1/2 of the time, the response will be
rejected, either with lots of tags not there at all, or missing last
character, even with flush() before and after the print.

Other numbers I tried with len(response) is to +1, -1, +2, -2, +5,
removed the \n at the end of that print statement, removed print and
used sys.stdout.write() instead, even used time.sleep(5), and even with
that, you can see that w.bloggar waited for 5 seconds until the
connection is closed, but you still get corrupted results.

The thing is, with putty's raw mode, I get everything, but with
telnet.exe, I get the response in full at half of the time, why?
telnet.exe should not even care about content-length. I would get
something like '</methodRes*&' at the end of the request (with
telnet.exe) and *& represents corrupted high ascii characters in place
of 'nc', even though ethereal says otherwise.

And why don't I face any problem at all when I used python's xmlrpclib,
or when I used Jericho, all with the same failing xmlrpc.cgi, that
telnet.exe or w.bloggar seems to report.

The problem is not unlike what I sometimes encounter between php(unix)
and IE together, although that does not involved corrupted bits.

Really Will, I've tried so many options, and wasted time until Abe told
me about '-u' yesterday, and I only tried '-u' as a last resort. I can
tell you that at least 8 hours (on and off) is spent in the last few
days debugging this, why won't you just accept that sys.stdout.flush()
don't work (even in PHP with my work stuff). The problem is something
else and I'm just happy to tell people to use '-u'.

If you'd like to see the problem for yourself you can try to use the
xmlrpc.cgi on Windows, and try your own methods of debugging this issue,
and I'd be happy to take note of other possible solutions.