base64.decodestring or xmlrpc (in zope) is truncating strings

[Craig Dunigan]

If anyone knows of any problems with base64 or xmlrpc, or has experienced
any similar behavior, I'd really like to hear from you!

I am extending a zope/xmlrpc client on Win32 that was written by a much
brighter programmer than me.  Basically, it uses xmlrpc to call external
methods on the zope server, and synchronizes a local web tree with a users
remote tree.  It makes its rpc call to an external method on the server
(RedHat 7, Zope 2.3) containing this bit of code (it returns file contents
from the zodb):

  meta_type = fileObject.meta_type
  if meta_type == 'DTML Document':
    return ("OK", base64.encodestring(fileObject.document_src()))
  elif meta_type == 'File':
    return ("OK", base64.encodestring(fileObject.data))
  elif meta_type == 'Image':
    return ("OK", base64.encodestring(fileObject.data))
  else:
    return ("FAIL", 'Unsupported meta_type')


This is the client's method to receive the file contents:

  def getFile(self, pathSpec, fileName):
    parms = {
      'relativePathSpec':pathSpec,
      'fileName': fileName
    }
    retval = None
    try:
      retval = eval("self.serverObject.getConnection()." +
self.remoteBasePathSpec + ".EWSyncGetFile(parms)")
      # EWSyncGetFile is the remote method that contains the snippet above
    except:
      raise "ZopeFileSystemException", "type: %s\nvalue: %s" %
(sys.exc_type, sys.exc_value)
    if retval[0] != "OK":
      raise "ZopeFileSystemException", "Failure from EWSyncGetFile()\n  %s"
% retval[1]
    return base64.decodestring(retval[1])

I've put in some debug code to spit print statements to the console, then
run the client window and server console side by side, and visually verified
that string lengths of the server's return after encode and the client's
retval[1] prior to decode are identical, meaning we're receiving the encode
string unchanged.  I've also compared the pre-encode string length on the
server to the decode string length immediately after the base64.decodestring
in the client, and they aren't the same in about a third of my test
documents.  Of course, the received file contents (the calling object of
"getFile" does a write to the local filesystem) are corrupt and unusable.
I've done a compare of the original files and the corrupted ones in a hex
editor, and in every case the corrupted file simply stops somewhere in the
middle.  There doesn't appear to be a set length that it fails at, since the
received corrupted files vary in byte size from ~80KB to ~120KB.  Larger
files have also come through unchanged.  The files that get truncated are MS
PowerPoint and Adobe PDF, which are the bulk of what this site will contain
(of course!).  Some PowerPoint and PDF files come through just fine, and
I've been unable to determine what the difference is between the files that
work and the ones that don't.

If anyone can make any suggestions, I'd be extremely grateful!