XML-RPC introspection protocol is broken

There are a couple of problems I identified, one in the the system core XML-RPC library implementation, and the other in the services module XML-RPC server. The bad news is that this might not be a “bug” in either. But the good news is that it’s easy to fix.

The core XML-RPC library provides two ways for servers to report their services: one allows for introspection support, the other produces half-broken support. Specifically, it supports system.listMethods for all methods, but returns “System Error” when system.methodSignature is invoked for methods from servers that don’t support it. In the latter case, the “works as designed” response from core designers might be that you shouldn't be calling introspection methods on servers that don’t support it. Unfortunately, the core XML-RPC library doesn’t let you know which ones do or don’t support introspection other than through the error. It’s definitely not in agreement with the de facto standard XML-RPC introspection protocol.

The problem in the services module is that it doesn't really have any support for XML-RPC introspection and so its XML-RPC server uses the interface into the XML-RPC library that produces broken responses when someone attempts to use introspection on it.

The good news is that the attached patch provides the necessary support in the XML-RPC server. Mind you that I really don’t know much about XML-RPC other than what I’ve learned over the last couple of hours studying this problem and I don’t have a thorough way of testing this patch, so please tread lightly.

There may be security issues that I haven’t considered. Without this patch, a limited client can only see the method names. This patch reveals the method input types, parameter names, return types and the help text for each method.

IMHO this is a core bug. The interface that produces half-broken support should instead result in “I don’t know” responses when system.methodSignature is invoked. It’s moot for this server with this patch, but here’s the issue I submitted against core:

#897142: XML-RPC introspection protocol breaks for servers that don’t provide signatures

I’ll leave this particular item marked as a bug so that the patch gets submitted and I’ll otherwise leave it to the project maintainers to decide whether or not it’s their “bug” and/or whether they otherwise want to include this patch as a feature improvement.

Please let me know how it works for you.

Fix format

I was close, but I see that core doesn't support multiple signatures. This patch uses only the first one calculated.

Bumping version

There are plenty of PHP implementation of XMLRPC to look at as reference http://www.xmlrpc.com/directory/1568/implementations

Just writing this link here in order not to forget about it :) I believe our XMLRPC really needs a lot of improvements.

+ $signatures = xmlrpc_server_method_signatures($method);
+ $callbacks[] = array(
+ $method['method'],
+ 'xmlrpc_server_call_wrapper',
+ is_array($signatures)?$signatures[0]:$signatures,
+ $method['help']
+ );

This part failed for me. I went with this instead: (apologies for styling - feel free to correct. My editor was being silly). This allows XMLRPC to revert to previous approach if applying signature (say as it does with all of the internal systems).
I suspect there's a problem with the other part to even identify the signature - it really doesn't match how data's organized from what I've read, but am not sure how to correct it.

+ $signatures = xmlrpc_server_method_signatures($method);
+ if ($signatures) {
+ $callbacks[] = array(
+ $method['method'],
+ 'xmlrpc_server_call_wrapper',
+ is_array($signatures)?$signatures[0]:$signatures,
+ $method['help']
+ );
+ } else {
+ $callbacks[$method['method']] = 'xmlrpc_server_call_wrapper';
+ }