[PHP-DEV] Bug #14521 Updated: XMLRPC extension: wrong results?

2001-12-18 Thread danda

ID: 14521
Updated by: danda
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: XMLRPC-EPI related
Operating System: Debian Linux 2.4.6-pre6
PHP Version: 4.1.0
New Comment:

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.

Previous Comments:


[2001-12-14 12:51:06] [EMAIL PROTECTED]

[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 h1Request/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 h1Result/h1;
echo xmp;
var_dump($response);
echo /xmp;

xmlrpc_server_destroy($server);

?






Edit this bug report at http://bugs.php.net/?id=14521edit=1


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14521 Updated: XMLRPC extension: wrong results?

2001-12-18 Thread cmv

ID: 14521
Updated by: cmv
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: XMLRPC-EPI related
Operating System: Debian Linux 2.4.6-pre6
PHP Version: 4.1.0
New Comment:

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


Previous Comments:


[2001-12-18 14:35:52] [EMAIL PROTECTED]

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-14 12:51:06] [EMAIL PROTECTED]

[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 h1Request/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 h1Result/h1;
echo xmp;
var_dump($response);
echo /xmp;

xmlrpc_server_destroy($server);

?






Edit this bug report at http://bugs.php.net/?id=14521edit=1


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]