See http://bugs.php.net/bug.php?id=45244&edit=2

Zend_XmlRpc_Server appears to rely on serialized objects being converted to a "displayable" as opposed to "storeable" form. When an object with protected properties is serialized, serialize() inserts NULL characters before the representation of the protected property.

For an object of a class defined thus:

class Task {

public $_id;
protected $_name;
protected $_description;
protected $_key;
public function setName($name) {$this->_name = $name;}
public function setId($description) {$this->_description = $description;}
public function setKey($key) {$this->_key = $key;}

}

serialize() generates the following:

O:4:"Task":5:{s:3:"key";s:0:"";s:6:"_id";s:1:"1";s:8:"_name";s:6:"Task 1";s:15:"*_description";s:21:"This is my first task";s:7:"*_key";s:0:"";}

What's not clear from above is that the property definition for _id is actually : s:6:"[NULL]*[NULL]_id";s:1:"1";

Some part of XmlRpc_Server appears to be using string methods which determine a NULL character to be the end of a string, so the NULLs in the above serialised string cause the server to break when packaging it into a response.

So when XmlRpc_Server->handle() is called and the above is returned, it dispatches the following to the client within the response payload:

O:4:"Task":5:{s:3:"key";s:0:"";s:6:"

The client then can't call unserialize() on this value as much of the object definition is missing.