A bug... but where?

["Nikolai Devereaux" <Nikolai at ucsd.edu>]

xmlBlaster uses the Helma xmlrpc tool on their server end to receive
procedure calls sent to them via clients.  That's why I'm cc:ing them this
email.  I don't know if this bug is in their code or in Helma.  I'm pretty
sure it's in Helma.  However, if it is an old bug that was fixed, perhaps
xmlBlaster should get a newer copy of Helma in with their distribution.

Enough jibber jabber.  Here's my problem:  =)

The xmlrpc spec says that byte arrays must be base64 encoded and passed as a
<base64>blablablabla</base64> tag from a client, and the server must decode
that data and put it back into a byte[] array.

I'm developing a COM object that sends messages back and forth using
xmlBlaster.  I've had to write my own driver for this connection using
xml-rpc to perform the needed login, subscribe, publish, etc...  There was a
COM xml-rpc client that I tried to use originally, by Steve Ivy and Joe
Massey.  However, their base64 encoder didn't work properly so I had to
ditch that and just use a separate base64 encoder/decoder library and create
all my procedure call XML by hand.

Everything worked all fine and dandy until I tried to send a message that
was longer than 56 chars or so.  I encode the message and make an xmlrpc
call to "publish()", which promptly returns the error that the content
length was miscalculated.

It turns out that the base64 encoder I use follows the spec found at
http://www.cis.ohio-state.edu/htbin/rfc/rfc1521.html for Base64
Content-Transfer-Encoding, on page 21.  This spec says that all encoded
messages should be no longer than 76 characters in length, and all line
breaks and other characters not found in the base64 alphabet must be ignored
by decoding software.

Therefore, any messages that are longer than 76 characters when decoded are
broken up by linebreaks.  Helma seems to have a problem with this.  When I
manually search for and remove linebreak characters from encoded messages
before sending them to Helma, the procedure calls work just fine.

Take care,

Nik