Edit report at http://bugs.php.net/bug.php?id=36629&edit=1
ID: 36629
Comment by: leon at fun4me dot demon dot nl
Reported by: ilya at iponweb dot net
Summary: SoapServer::handle() exits on SOAP faults
Status: Closed
Type: Bug
Package: SOAP related
Operating System: Debian Linux (testing)
PHP Version: 5CVS-2006-03-06 (snap)
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
I am still having this problem.
I don't think this is solved
I am using
PHP/5.3.3-1ubuntu9.3
When using SoapServer in WSDL-mode and let it handle a request which
does not match the wsdl I get a SOAP-ENV:Fault directly in my
soap-client (AND sometimes a stack-trace! which is really problematic).
I am not able to intercept this fault-response (let alone the
stacktrace) in php (with try/catch and ob_get_clean)
class SoapServerAdapter implements SoapProcessor
{
/**
* The soapServer instance
*
* @var SoapServer
*/
protected $soapServer;
/**
* @param SoapServer $soapServer
*/
public function __construct(SoapServer $soapServer)
{
$this->soapServer = $soapServer;
}
/*
* Call the configured soap server, return the generated response.
*/
public function process(sfWebRequest $request)
{
ob_start();
$this->soapServer->handle($request->getContent());
$responseMessage = ob_get_clean();
return 'intercepted with ob_get: '.$responseMessage;
}
}
public function handle(sfWebRequest $request)
{
$soapServer = new SoapServer($this->wsdl);
$soapProcessor = new SoapProcessor($soapServer);
try
{
$response = $soapProcessor->process($request);
echo $response;
}
catch (Exception $e)
{
// TODO: handle errors, like 404
die('unforntunately I never get here!);
}
}
Previous Comments:
------------------------------------------------------------------------
[2010-03-19 03:13:24] druidmatrix at yahoo dot com
I am still having this problem on Fedora Core 10. PHP is:
[csit@fc10-test webservices]$ php -v
PHP 5.2.11 (cli) (built: Jan 4 2010 23:45:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
I am not able to catch the SoapFault on the server side at all - not
even by using a try-catch around $server->handle(). It looks like the
server is immediately generating the SoapFault and returning it to the
client; control never advances beyond the handle() call on the server
side.
------------------------------------------------------------------------
[2006-03-10 12:49:31] [email protected]
Fixed in CVS HEAD and PHP_5_1.
------------------------------------------------------------------------
[2006-03-06 13:50:13] ilya at iponweb dot net
Description:
------------
When calling SoapServer::handle() it exits after processing the SOAP
request if request handler returns a SoapFault object. It makes
impossible to do any work on the SOAP server side after processing
requests if they result in SoapFault.
I belive exactly the same issue was reported in bug report #31993 but
for some reason it was closed without actually fixing the problem in the
soap extension. I could reproduce the problem with PHP 5.1.1 and with
PHP snapshot 5.1-200603061130.
The test code demostrates this problem. It is a simple soap server with
two remotly callable functions: test1 and test2. The first of them
simply returns a string, the second returns a soap fault object. The
server is supposed to write a string to a log file after processing a
request. If you call remotly test1 function then you can see the string
in the log, if you call remotly test2 function then the log file is
empty.
Reproduce code:
---------------
<?php
$server = new SoapServer(null, array('uri' => "http://test-uri/";));
$h = fopen("/tmp/soap.log", "w");
$server->addFunction(array('test1', 'test2'));
$server->handle();
fputs($h, 'TEST');
fclose($h);
function test1() {
return "test1";
}
function test2() {
return new SoapFault("test2", "test2");
}
?>
Expected result:
----------------
A log message in file /tmp/soap.log
Actual result:
--------------
Nothing when calling remotly 'test2' function.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=36629&edit=1
