ZF-3947: Zend_XmlRpc_Value ignores empty strings as struct values


I have a Java based XMLRPC server which sends back a struct from a method call. In this struct there can be many key/value pairs where the value is a blank string.

These blank strings don't get added to the returned struct (array). The check 'empty($member->value)' is catching this case and preventing the value from being added to the struct. From reading the spec this is perfectly valid. An example XML (part) output is


which should be valid because if no type is defined in between then string is assumed. (Similar discussion

The relavent code is Zend/XmlRpc/Value.php:371

               // Parse all the memebers of the struct from the XML string
               // (simple xml element) to Zend_XmlRpc_Value objects
               foreach ($value->member as $member) {
                   // @todo? If a member doesn't have a  tag, we don't add it to the struct
                   // Maybe we want to throw an exception here ?
                   if ((!$member->value instanceof SimpleXMLElement) || empty($member->value)) {
                       //throw new Zend_XmlRpc_Value_Exception('Member of the '. self::XMLRPC_TYPE_STRUCT .' XML-RPC native type must contain a VALUE tag');
                   $values[(string)$member->name] = self::_xmlStringToNativeXmlRpc($member->value);


It seems these two issues are somehow related.

After upgrading to 1.7 I would like to revisit this bug report. This bug still exist and really should be fixed as it causes the silent removal of data returned in a xmlrpc query. The use of "empty" not only discards a empty string (which is valid) but also discards a string with the value "0" (that's a zero)

The @todo needs to be removed because it is incorrect and the "|| empty($member->value)" needs to be removed. This ensures that we still have valid XML (value tag inside a member tag) but correct values are still added to the struct.

I also don't know why this issue has been listed as dependant on issue ZF-3862 as it is not related.

I have raised this to critical because the bug is silently dropping data from a return result which is valid.

Fixed in trunk with r12720 and in 1.7 release branch with r12721.