Description: ------------ I'm going through the existing examples for Pear SOAP, specifically the files "client.php" and "example_server.php". At the point when the client tries to call the divide method using '0' divisor, the server returns a SOAP_Fault. However, the response received by the client contains an error message saying "Invalid HTTP Response", not the actual SOAP Fault.

Me too!

Me too!

I've traced this problem and it's due to attempting to serialize a self referencing array. The problem is here: SOAP/Fault.php line:81 if (isset($this->backtrace)) { $params[] = new SOAP_Value('detail', 'string', $this->backtrace); The $this->backtrace parameter is a self referencing array. The code attempts to serialize it, goes into an infinite recursion loop and eventually dies when the recurse limit is hit. The reason for the Invalid HTTP Response is because the server returns nothing (after dying) and the client correctly interprets this as HTTP failure. The workaround (and I believe correct behaviour) is just to remove the backtrace code. The method should be as follows: function message($encoding = SOAP_DEFAULT_ENCODING) { $msg = new SOAP_Base(); $params = array(); $params[] = new SOAP_Value('faultcode', 'QName', 'SOAP-ENV:' . $this->code); $params[] = new SOAP_Value('faultstring', 'string', $this->message); $params[] = new SOAP_Value('faultactor', 'anyURI', $this->error_message_prefix); $params[] = new SOAP_Value('detail', 'string', $this->userinfo); $methodValue = new SOAP_Value('{' . SOAP_ENVELOP . '}Fault', 'Struct', $params); $headers = null; return $msg->makeEnvelope($methodValue, $headers, $encoding); } Supplying a backtrace to a remote client is a bad security practice.

I am running into this same issue and agree that removing the backtrace from the error message is the correct fix.

The workaround I have put in for now is to disable PEAR from generating backtraces, which avoids changing any of the PEAR SOAP code: $skiptrace = &PEAR::getStaticProperty('PEAR_Error', 'skiptrace'); $skiptrace = true;

mmm. I don't suppose you can try this in a newer version of php and the package? I'm leaning towards it being not a bug, bug a change request to suppress backtraces ; alternatively, to better design architecture to avoid such huge backtraces...

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.