PEAR Bug Search Results

XML_RPC2: Bug 16301 [Verified] Invalid XML response from server will crash PHP

soryu2 at gmail dot com — 2009-06-08T05:02:40+00:00

XML_RPC2 Bug
Reported by soryu2
2009-06-07T12:48:05+00:00
PHP: 5.2.9 OS: Mac OX X.5.7 Package Version: 1.0.5

Description:
------------
PHP Backend of xmlrpc client does not check for valid XML response. It 
uses simplexml_load_string($body) in RPC2/Backend/PHP/Client.php line 
114 and passes the result unchecked to 
XML_RPC2_Backend_Php_Response::decode which access the argument 
as an object. But simplexml_load_string may return FALSE in which case 
PHP bellies up and just plain exits without any error or exception.
Using the xmlrpc ext backend works (it does not crash/exit PHP) but is 
not an option for me as it garbles multibyte characters.

Real life errors that could cause this behaviour is the PHP crashing on the 
server (because of a bug in call handler code or otherwise) or Memory 
limit exceeded.

Test script:
---------------
Client: http://pastie.textmate.org/503464
Server: http://pastie.textmate.org/503465

Expected result:
----------------
Print: Done

Actual result:
--------------
PHP stops execution in RPC2/Backend/PHP/Reponse.php line 127 when 
trying to execute method `xpath` on `false`

XML_RPC2: Feature/Change Request 16300 [Open] Encoding of NULL values

soryu2 at gmail dot com — 2009-06-07T12:24:01+00:00

XML_RPC2 Feature/Change Request
Reported by soryu2
2009-06-07T12:24:01+00:00
PHP: 5.2.9 OS: Mac OX X.5.7 Package Version: 1.0.5

Description:
------------
The PHP backend cannot encode NULL values, which the xmlrpc ext 
backend apparently can.

(I cannot use the xmlrpc ext backend because it garbles multibyte 
characters, and I'm using UTF-8).

Anyway, if the non-support of NULL values is a strict interpretation of the 
xmlrpc spec, maybe there could be a configuration switch so that NULL 
values would be interpreted as empty strings?

Test script:
---------------
method(array('a' => null));
}
catch (Exception $e)
{
	print "EXCEPTION:".$e->getMessage();
}
?>

Expected result:
----------------
No output

Actual result:
--------------
EXCEPTION:Impossible to encode value '' from type 'NULL'. No analogous 
type in XML_RPC.
#0 /usr/local/php5/lib/php/XML/RPC2/Backend/Php/Value/Struct.php(107): 
XML_RPC2_Backend_Php_Value::createFromNative(NULL)

XML_RPC2: Feature/Change Request 15855 [Open] Mock out unit tests

daniel dot oconnor at gmail dot com — 2009-02-03T14:20:57+00:00

XML_RPC2 Feature/Change Request
Reported by doconnor
2009-02-01T10:36:55+00:00
PHP: 5.2.6 OS:  Package Version: CVS

Description:
------------
A lot of tests are failing because the servers they hit don't exist any more, ie; time.xmlrpc.com

Simply swapping to HTTP_Request2 (if possible, its php5 only) will get you an E_STRICT HTTP_Request package which is easy to mock with.

XML_RPC2: Feature/Change Request 15633 [Open] Add timeout

lars at legestue dot net — 2009-01-14T10:19:40+00:00

XML_RPC2 Feature/Change Request
Reported by lsolesen
2009-01-14T10:19:40+00:00
PHP: 5.2.8 OS: N/A Package Version: 

Description:
------------
When a service is failing or dns cannot be resolved, it will try calling for a long time. It would be neat if it was possible to set a timeout.

XML_RPC2: Feature/Change Request 15068 [Open] Use HTTP_Request2 rather than cURL

borz_off at cs dot msu dot su — 2009-07-25T09:17:33+00:00

XML_RPC2 Feature/Change Request
Reported by avb
2008-11-18T13:30:49+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 1.0.5

Description:
------------
A new E_STRICT-compatible version of HTTP_Request package [1] has been released, please consider using it instead of relying on cURL extension.

If HTTP_Request2 is not yet ready for your package's needs, do not hesitate to open requests for missing features.

[1] http://pear.php.net/package/HTTP_Request2/

XML_RPC2: Feature/Change Request 14958 [Open] Make it easy to define error messages so they are shown in docs

lars at legestue dot net — 2008-11-04T15:07:22+00:00

XML_RPC2 Feature/Change Request
Reported by lsolesen
2008-11-04T15:07:22+00:00
PHP: 5.2.6 OS: Xubuntu Package Version: 1.0.5

Description:
------------
Make it easy to define error messages so they are shown in docs. As there is no standard error messages, these are an important part of the documentation for an xmlrpc-service, so it would be nice with an easy way to define these directly in the class.

XML_RPC2: Bug 12884 [Assigned] Bogus User-agent header

borz_off at cs dot msu dot su — 2008-10-09T06:08:07+00:00

XML_RPC2 Bug
Reported by avb
2008-01-11T14:51:19+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 1.0.5

Description:
------------
Current XML_RPC2 sends the following header:
'User-Agent: PEAR_XML_RCP2/0.0.x'

There is an obvious typo in a package name, and 0.0.x version is completely bogus. I suggest changing this to maybe:
'User-Agent: PEAR::XML_RPC2/@package_version@'
and setting up a replacement for @package_version@ in HTTPRequest.php file via package2.xml

XML_RPC2: Bug 12562 [Verified] Support 64-bit integer datatype i8

nevans at dsl dot net — 2007-12-05T12:08:44+00:00

XML_RPC2 Bug
Reported by nevans
2007-12-01T20:18:21+00:00
PHP: 5.1.2 OS: x86 Ubuntu GNU/Linux 6.06 Package Version: 1.0.2

Description:
------------
In version 1.07 of the XML-RPC for C/C++ library, its developers added a 64-bit integer datatype to the library[1]. 

From what I can gather, i8 is not part of the XML-RPC spec, but an extension introduced by the Apache foundation[2]. I'm not sure if that disqualifies it from stuff PEAR::XML-RPC2 wants to support, but for what it's worth, our Perl counterpart[3] 'supports' it.

rTorrent's XML-RPC interface uses this 64bit integer, and if I get a response with i8, PEAR::XML-RPC2 throws an exception with a note about an unknown datatype. 

I have a patch to add 64-bit integer support. It uses the double's datatype instead of an int because (at least on 32-bit systems), PHP's int is an unsigned 32-bit number, and double goes higher (I don't know how high...but if it's not perfect, it's closer to what I needed).

[1] http://xmlrpc-c.sourceforge.net/change.html
[2] http://ws.apache.org/xmlrpc/types.html
[3] http://search.cpan.org/~giraffed/RPC-Xmlrpc_c-1.02/Value/Value.pm#RPC::Xmlrpc_c::Value-%3EnewI8($)

XML_RPC2: Bug 11314 [Verified] Following codesniffer standards param docs mess up

lars at legestue dot net — 2007-12-05T11:53:47+00:00

XML_RPC2 Bug
Reported by lsolesen
2007-06-13T11:37:37+00:00
PHP: 5.2.2 OS: ir Package Version: 1.0.1

Description:
------------
When following codesniffer standards and aligning the params in the codeblocks XML_RPC2 messes up the descriptions. It happens when the variable type is different lengths.

Test script:
---------------
Using this server:


 * @copyright 2007 Lars Olesen
 * @license   GPL http://www.opensource.org/licenses/gpl-license.php
 * @version   @package-version@
 * @link      http://pear.php.net/package/XML_RPC2
 */
require_once 'XML/RPC2/Server.php';

/**
 * The implementation
 *
 * @category  XML
 * @package   XML_RPC2
 * @author    Lars Olesen 
 * @copyright 2007 Lars Olesen
 * @license   GPL http://www.opensource.org/licenses/gpl-license.php
 * @version   @package-version@
 * @link      http://pear.php.net/package/XML_RPC2
 */
class DocumentationServer {

    /**
     * returns something
     *
     * @param array   $something     A description
     * @param string  $another_thing A description of another thing
     * @param boolean $return        Whether to return nothing - server doesn't care though
     *
     * @return string An international string
     */
    public static function getSomething($something, $another_thing, $credentials) {
        return 'nothing interesting';
    }

}

$options = array(
    'prefix' => 'test.',
    'encoding' => 'ISO-8859-1'
);

$server = XML_RPC2_Server::create('DocumentationServer', $options);
$server->handleCall();
?>

With this test:

--TEST--
Following codesniffer standards docs should still be correct
--FILE--

--EXPECT--


  
    
    Available XMLRPC methods for this server
    
  
  
    Available XMLRPC methods for this server
    Index
    
      test.getSomething()
    
    Details
    
      (string) test.getSomething((array) something, (string) another_thing, (boolean) credentials)
      Description :
      
        returns something
      
      Parameters : 
      
        Type Name Documentation
        array something        A description
        string another_thing   A description of another thing
        boolean credentials    Whether to return nothing - server doesn't care though
      
      (return to index)
    
  



Expected result:
----------------
Test should pass.

Actual result:
--------------
Test fails because the server takes one character from the variable name and adds it to the description also.

XML_RPC2: Bug 11177 [Analyzed] Encoding is not correct

lars at legestue dot net — 2007-12-05T11:42:05+00:00

XML_RPC2 Bug
Reported by lsolesen
2007-05-29T18:19:29+00:00
PHP: 5.2.1 OS: Windows Vista Package Version: 1.0.1

Description:
------------
Using Danish letters the server does not handle the encoding. I have supplied a test script and a test server, so you can review the problem.



Test script:
---------------
Using this server: 

 'test.',
    'encoding' => 'iso-8859-1'
);

// Let's build the server object with the name of the Echo class
$server = XML_RPC2_Server::create('EncodingServer', $options);
$server->handleCall();
?>

And this test script:

--TEST--
Server should handle encoding
--FILE--
 'test.',
    'encoding' => 'iso-8859-1'
);

$client = XML_RPC2_Client::create('http://localhost/EncodingServer.php', $options);

try {
    $result = $client->getInternationalString();
    print_r($result);
} catch (XML_RPC2_FaultException $e) {
    die('Exception #' . $result->getFaultCode() . ' : ' . $e->getFaultString());
} catch (Exception $e) {
    die('Exception : ' . $e->getMessage());
}
?>
--EXPECT--
Ã¦Ã¸Ã¥

Expected result:
----------------
Test should not fail

Actual result:
--------------
Test fails

XML_RPC2: Feature/Change Request 11023 [Verified] use php://input instead of $GLOBALS['HTTP_RAW_POST_DATA']

kael at crocobox dot org — 2007-12-05T12:10:31+00:00

XML_RPC2 Feature/Change Request
Reported by kael
2007-05-12T15:36:48+00:00
PHP: 5.2.1 OS: ArchLinux Package Version: 1.0.1

Description:
------------
Maybe XMLRPC2 should read POST data using php://input instead of GLOBALS['HTTP_RAW_POST_DATA'] ?

We can read in the manual :
"""
 always_populate_raw_post_data  boolean

    Always populate the $HTTP_RAW_POST_DATA containing the raw POST data. Otherwise, the variable is populated only with unrecognized MIME type of the data. However, the preferred method for accessing the raw POST data is php://input. $HTTP_RAW_POST_DATA is not available with enctype="multipart/form-data".
"""

php://input seems to be the preferred way to read XMLRPC request content

Type	Name	Documentation
array	something	A description
string	another_thing	A description of another thing
boolean	credentials	Whether to return nothing - server doesn't care though