Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.5

Bug #4726 XML_RPC_Response not properly creating as fault when fault has been parsed
Submitted: 2005-07-01 19:36 UTC
From: ckohnert at yahoo dot com Assigned: danielc
Status: No Feedback Package: XML_RPC
PHP Version: 4.3.10 OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2005-07-01 19:36 UTC] ckohnert at yahoo dot com
Description: ------------ When constructing an XML_RPC_Response with a non-numeric fault code, it treats it as a normal (successful) response, even though it's being constructed as a fault (and hence, application code relying on that fault check will not catch it). Reproduce code: --------------- $res = new XML_RPC_Response("foo", "Client", "Method not found"); if( $res->faultCode() ) die; //---- Patch fixing the above problem. ---- // Change the integer test in the constructor // to a null/isset() test. function XML_RPC_Response($val, $fcode = null, $fstr = '') { if (isset($fcode)) { $this->fn = $fcode; $this->fs = htmlspecialchars($fstr); } else { $this->xv = $val; } } Expected result: ---------------- The above code should die, since it properly parsed the fault generated by the perl package SOAP::Lite when a method was not found. SOAP::Lite does not send a numeric faultCode for some reason (it sends "Client" in this setup), but it does so in a properly constructed fault message. Hence, the XML_RPC_Response, rather than treat it like a valid response, should construct as a fault (even though the faultCode is non-numeric). Actual result: -------------- It treats the response as a normal (successful) call, even though it was parsed correctly as a fault.

Comments

 [2005-07-01 19:39 UTC] ckohnert at yahoo dot com
Added "XML_" to create full class name in bug summary.
 [2005-07-14 01:58 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2005-08-04 12:15 UTC] markus at fischer dot name
I'm using 1.3.3 and it doesn't seem to be fixed here . The problem is if the faultCode from the server is e.g. 0. The method 'faultCode' has the following code: function faultCode() { if (isset($this->fn)) { return $this->fn; } else { return 0; } } It's not possible that way to make a distinction between a fault or not. There *is* a way to detect a fault with errorCode by getting the response->value, decoding it and checking for faultString/faultCode. But I think this is not in the spirit how error handling should work here. A new method, isFault(), should give back a clear intication whether a fault was or not; independent from the faultCode. A suggestion: A separate flag inside the class XML_RPC_Response stores whether a fault response was received or not. This flag is returned with the isFault() method.
 [2005-08-14 21:29 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2005-09-07 04:59 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!