php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #37746 Incorrect encoding of PHP associative arrays in XML-RPC response.
Submitted: 2006-06-08 14:02 UTC Modified: 2007-11-28 01:09 UTC
Votes:16
Avg. Score:4.0 ± 1.2
Reproduced:13 of 14 (92.9%)
Same Version:2 (15.4%)
Same OS:1 (7.7%)
From: glideraerobatics at hotmail dot com Assigned:
Status: Wont fix Package: XMLRPC-EPI related
PHP Version: 5.1.4 OS: FreeBSD 6.1
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2006-06-08 14:02 UTC] glideraerobatics at hotmail dot com
Description:
------------
I've noticed that when a key of a hash begins with a digit between 1 and 9 that the resulting XML-RPC response will contain an empty key.

This array:
$result = array('666' => 'me', '007' => 'Bond');

will be returned as this which is obviously wrong:
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
 <param>
  <value>
   <struct>
    <member>
     <name/>
     <value>
      <string>me</string>
     </value>
    </member>
    <member>
     <name>007</name>
     <value>
      <string>bond</string>
     </value>
    </member>
   </struct>
  </value>
 </param>
</params>
</methodResponse>


Clearly the xmlrpc module has correctly detected that the result is a hash and has therefore made a 'struct'. What it didn't do correctly for some strange reason is treat all keys of the hash as strings (they even really are strings - ask gettype()).


Reproduce code:
---------------
function debug_getHash($method_name, $params, $app_data) {
  $key1 = '666';
  $key2 = '007';
  $result = array(
    $key1   => 'key1 is a ' . gettype($key1),
    $key2   => 'key2 is a ' . gettype($key2),
  );
  return $result;
}
xmlrpc_server_register_method($xmlrpc_server, 'debug.getHash', 'debug_getHash');

Expected result:
----------------
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
 <param>
  <value>
   <struct>
    <member>
     <name>666</name>
     <value>
      <string>key1 is a string</string>
     </value>
    </member>
    <member>
     <name>007</name>
     <value>
      <string>key2 is a string</string>
     </value>
    </member>
   </struct>
  </value>
 </param>
</params>
</methodResponse>


Actual result:
--------------
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
 <param>
  <value>
   <struct>
    <member>
     <name/>
     <value>
      <string>key1 is a string</string>
     </value>
    </member>
    <member>
     <name>007</name>
     <value>
      <string>key2 is a string</string>
     </value>
    </member>
   </struct>
  </value>
 </param>
</params>
</methodResponse>


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-06-08 14:16 UTC] glideraerobatics at hotmail dot com
By the way, a quick workaround to the problem is to append a NULL byte to the keys:

$key1 = '666' . chr(0x00);

This way the hash is returned as a correct xml-rpc response without the NULL bytes.
 [2006-06-08 15:02 UTC] lars dot maes at gmail dot com
I confirm this bug on Debian 3.1a sarge with php4 version 4.3.10

The chr(0x00) solution also works
 [2006-06-19 08:20 UTC] mike@php.net
It's been that way since the very first release, if the array contains numeric indices only.

 [2006-06-21 01:36 UTC] glideraerobatics at hotmail dot com
I'm confused. Is "It's been that way since the very first release" the reason why it won't be fixed?
I'm glad Microsoft didn't think that way otherwise I'ld still be seeing multiple BSOD's every day.
 [2006-06-21 08:19 UTC] mike@php.net
Well, 4 years with an unknown amount of people relying on it.

mike@honeybadger:~$ cli -r 'var_dump(xmlrpc_get_type(array(123=>123)), xmlrpc_get_type(array("a"=>123)), xmlrpc_get_type(array(123=>123,"a"=>123)));'
string(5) "array"
string(6) "struct"
string(5) "mixed"

 [2006-06-21 13:35 UTC] glideraerobatics at hotmail dot com
Ok, but then the question:
Could a 'mixed' array be of any use in xmlrpc communication if the numeric keys are being lost? I can't (yet) see how anybody could be relying on that because the xmlrpc response is useless/invalid in such cases.
 [2007-11-28 01:09 UTC] yunosh@php.net
I can't see how fixing this is going to break existing code. With the current implementation, using array keys from xmlrpc result sets is useless, because they don't have a meaning.
So people will either use structs, or loop through the arrays ignoring the keys completely.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Mon Apr 21 02:02:11 2014 UTC