ZF-5704: SoapServer->fault() will not correct encode the exception-message

Description

Setting up an SoapServer with another encoding as UTF-8 - for example ISO-8859-1 - SoapServer->fault() will not correct encode the message. By throwing a SoapFault with an message, the encoding will be done correctly, but SoapServer->fault() does not.

To suppress this php error (I reported that bug to php.net), I run an internal encoding. mb_convert_encoding($string, 'UTF-8', $this->getEncoding());

Reproduce code:

All code listed here is part of a complex class hierarchy.


SERVER-CODE



$server = new Zend_Soap_Server('http://xxx.de/?wsdl', array('encoding' => 'ISO-8859-1'));
$server->setClass('SoapFaultTest');
$server->registerFaultException(array('Exception'));
$server->handle();

CLIENT-CODE


try {
    $client = new SoapClient('http://xxx.de/?wsdl', array('encoding' => 'ISO-8859-1'));
    echo $client->test();
}
catch (SoapFault $fault) {
    echo 'error: ' . $fault->getMessage();
}

SERVICE-CLASS SoapFaultTest


class SoapFaultTest
{
    public function test() {
        throw new Exception('Exception with some special chars: Äßö');
    }
}

IMPROVEMENT FOR Zend_Soap_Server on line 941 (SVN)


return new SoapFault($code, $this->_convertEncoding($message));

/**
 * Converts non UTF-8 characters to UTF-8 charachters.
 * That is essential, otherwise PHPs Soap Extension will throw a SoapFault
 * SOAP-ERROR: Encoding: string '...' is not a valid utf-8 string
 * 
 * @param string String to encode
 * @return string correct Encoded String
 */
protected function _convertEncoding($string) {
    return 0 === strlen($this->getEncoding() || 'utf-8' === strtolower($this->getEncoding())) ? $string : mb_convert_encoding($string, 'UTF-8', $this->getEncoding());
}

So by throwing exceptions the exception-message will be converted correctly and the php bug can be circumvented.

Comments

thanks for the report, i'll look into it.

the problem, why i can't use your solution is the mbstring extension, which is not allowed in ZF components without a fallback. But iconv should be doing roughly good too :-)

I do wait for this bug to be confirmed on bugs.php.net (link: http://bugs.php.net/bug.php?id=47273), then i will implement a workaround.

The underlying PHP bug has been fixed, so this is marked as non-issue.