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

Bug #987 XML Character entities are duplicated in decode
Submitted: 2004-03-10 03:36 UTC
From: marthom at nortelnetworks dot com Assigned: danielc
Status: Closed Package: XML_RPC
PHP Version: 5.0.0b4 (beta4) OS:
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 34 - 12 = ?

 
 [2004-03-10 03:36 UTC] marthom at nortelnetworks dot com
Description: ------------ When decoding a message that contains a character entity (an ampersand for instance), the final value contains both the full expansion and the decoded value. What happens is that the default handler (XML_RPC_dh) receives the expanded entity '&' and the character handler (XML_RPC_cd) receives the character '&'. Both append the string to the accumulator. I think that I have solved this problem by removing the default handler from the equation entirely. I can't see how this handler would be needed - XML RPC is sufficiently simple that it doesn't need to understand <!DOCTYPE or any other special tags. Change the call to xml_set_default_handler: - xml_set_default_handler($parser, "XML_RPC_dh"); + xml_set_default_handler($parser, false); Reproduce code: --------------- #server - add the usual stuff as well function echo($params) { $ret = new XML_RPC_Value($params->getParam(0), 'string'); return new XML_RPC_Response($ret); } # client $params = array(new XML_RPC_Value("<&>", "string")); $msg = new XML_RPC_Message("echo", $params); $client = new XML_RPC_Client("/RPC2", "localhost", 8080); $response = $client->send($msg); print($response->value()); Expected result: ---------------- The value that comes out should be the same as the value that went in: "<&>". Actual result: -------------- The returned string should just contain the request parameter. Instead the value returned is "<<&&>>".

Comments

 [2004-03-15 13:47 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!
 [2004-03-15 21:58 UTC] marthom at nortelnetworks dot com
Hi, I am still seeing the same problem with the latest files from CVS. It doesn't look like the code specific to the problem has changed between versions 1.11 and 1.21 of RPC.php. If I use a PHP server, the problem is compounded, since both ends exhibit the same problem. For example, for a simple 'echo' command, if I send the string 'hello&', I get a response of 'hello&&&&'. It is possible that the version of xmllib/libxml2 affects this, I have version 2.6.4 installed. Regards, Martin
 [2004-10-08 17:46 UTC] amir dot laher at complinet dot com
Hi, I'm using the following regex cludge in the method 'parseResponse' (XML_RPC_Message object) ... RPC.inc line 738, after 'xml_parser_free($parser);': $data= $XML_RPC_xh[$parser]['st']; $data= ereg_replace("<<","<",$data); $data= ereg_replace(">>",">",$data); $data= ereg_replace("&&","&",$data); $data= ereg_replace('"','',$data); $XML_RPC_xh[$parser]['st']= $data; It seems to work for now... Cheers Amir
 [2004-10-08 17:49 UTC] amir dot laher at complinet dot com
ps. The extra characters seem to appear during 'xml_parse' in the 'xml_set_character_data_handler function', 'XML_RPC_cd' It's definitely a bit complicated!
 [2004-12-30 19:27 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!