php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14521 XMLRPC extension: wrong results?
Submitted: 2001-12-14 12:51 UTC Modified: 2001-12-18 16:29 UTC
From: cmv@php.net Assigned:
Status: Not a bug Package: XMLRPC-EPI related
PHP Version: 4.1.0 OS: Debian Linux 2.4.6-pre6
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: cmv@php.net
New email:
PHP Version: OS:

 

 [2001-12-14 12:51 UTC] cmv@php.net
[This is a copy of email sent to xmlrpc-epi mailing list, which hasn't been answered yet.]

First off, I'm using PHP 4.1.0 with the built in XMLRPC extension (which I assume is pretty much the same as what's documented at http://xmlrpc-epi.sourceforge.net/)

I made a simple server which basically echo's back the same params that are passed to it (see the script below).

It works when I send an integer, or a string, or an associative array. However, it fails on a non-indexed array.

Am I doing something wrong, or is this a bug in the extension?  I hope it's me, because this extension is pretty damn cool. :)

- Colin


The script:

<?php

function method_echo($method, $params) {
    $foo = array_pop($params);
    return $foo;
}

/* this is the test data to send */

$data = array('bob','kim');

echo "<h1>Request</h1>";
echo "<xmp>";
var_dump($data);
echo "</xmp>";

$server = xmlrpc_server_create();
xmlrpc_server_register_method($server, 'method_echo', 'method_echo');
$request_xml = xmlrpc_encode_request('method_echo', $data );
$response = xmlrpc_server_call_method($server, $request_xml, NULL,
    array(
        'output_type' => 'php'
    )
);

echo "<h1>Result</h1>";
echo "<xmp>";
var_dump($response);
echo "</xmp>";

xmlrpc_server_destroy($server);

?>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-18 14:35 UTC] danda@php.net
working as designed.

the working as designed.

the $data array he is passing in is actually the xmlrpc top level params list.

If he wishes to pass the array as the first argument (as the receiving method seems to want) then he should create a wrapper array, eg:

$params = array(array('bob', 'kim'));

Note also that if the receiving function simply prints params instead of the first param, then it will print the array as passed.$data array he is passing in is actually the xmlrpc top level params list.

If he wishes to pass the array as the first argument (as the receiving method seems to want) then he should create a wrapper array, eg:

$params = array(array('bob', 'kim'));

Note also that if the receiving function simply prints params instead of the first param, then it will print the array as passed.
 [2001-12-18 16:29 UTC] cmv@php.net
I should have explained it better, I think ...

In my example, if I pass it:

    $data = array('bob','kim');

I get back: 'bob'  ... which makes sense.  However, if I pass it:

    $data = array('name1'=>'bob', 'name2'=>'kim');

I get back: array('name1'=>'bob', 'name2'=>'kim')  ... which doesn't make sense to me.

It's maybe easier to understand if you change the method function to this:

    function method_echo($method, $params) {
        return $params;   /* i.e. return exactly what you get */
    }

If I then make a request, I would expect the response to be identical to whatever $data I send.  And in the case of the simple array('bob', 'kim'), this is true.  However, if the data I send is anything other than a one-dimensional, non-indexed array, my response is equal to array($data), i.e. it gets wrapped inside an array.

That doesn't seem too intuitive to me.  Shouldn't you always get back exactly what you send?

- Colin

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 26 05:01:30 2024 UTC