Help - Search - Members - Calendar
Full Version: xmlrpc error handling
Movable Type Community Forum > Other Product Discussion > Bugs and Odd Behavior
btrott
Thanks, I'll check it out... mt-xmlrpc.cgi is not really controlling the return code, though. It's just die-ing, then letting XMLRPC::Lite wrap that into a Fault to be returned to the client. So... are you suggesting that this is a problem in XMLRPC::Lite, then?
mprewitt
I'm using mt-xmlrpc.cgi to enter posts from a script and am trying to give my script some better error handling.  I've found, however, that it looks like mt-xmlrpc.cgi is sending a server error code 500 in some cases where it shouldn't.  For example, when sending a bad login password, a 500 is sent along with the fault message.  Frontier::Client won't show the fault code unless the server return code is a 2xx.  RPC::XML treats the return as an error instead of a fault and again doesn't give access to the error message.  XMLRPC::Lite seems to be the only client which 'ignores' the result code and allows you to look at the fault.  

However, XMLRPC::Lite is the 'heaviest' of all the 3 clients I've tried.  I believe that mt-xmlrpc.cgi should not be sending a 500 on fault, but rather a 200 to indicate the the request succeeded but that the result may contain a fault.

Here's some code that tests all 3 scenarios:

CODE
#!/usr/local/bin/perl
#
#  send a log entry to mt-xmlrpc.cgi
#
use strict;

use Getopt::Long;

my $title;
my $content;
my $publish = 1;
my $debug;

my $server_url = 'http://internal.wssource.com/cgi-bin/mt/mt-xmlrpc.cgi';
my $appkey = 0;
my $blogid = 2;
my $command = 'blogger.newPost';

my $username = 'mprewitt';
my $password = 'wrong_password';

GetOptions(
   'title=s'     => \$title,
   'content=s'   => \$content,
   'password:s'  => \$password,
   'user:s'      => \$username,
   'url:s'       => \$server_url,
   'blogid:i'    => \$blogid,
   'debug!'      => \$debug,
) or die Usage();

#
# Send message to mt-xmlrpc
#
# Parameters: String appkey, String blogid, String username, String password,
#  String, title, String content, String more_content, String excerpt, boolean publish
#

#----------------------------------------------------------------------
# XMLRPC::Lite
#  
#  bad password: fault handling works fine
#
print STDERR "\nUsing XMLRPC::Lite\n";
use XMLRPC::Lite;
my $soap =  XMLRPC::Lite->proxy($server_url);
my $som = $soap->call( $command,
   $appkey, $blogid, $username, $password, $title, $content, $publish);
if ($som->fault)  {
   warn $som->faultcode, ": ", $som->faultstring;
}

#----------------------------------------------------------------------
# RPC::XML
#
#  bad password: gets a server error, not fault and therefore no helpful
#  message can be sent to the user
#
#  i'm guessing that if a 20x response code is sent that the bad password
#  will be handled as a fault rather than an error.
#
print STDERR "\nUsing RPC::XML\n";
use RPC::XML;
use RPC::XML::Client;

sub handle_error {
   my $text = shift;
   warn "Error: $text\n";
   return $text;
}

sub handle_fault {
   my $fault = shift;
   warn "Fault: [", $fault->code, "] ", $fault->string, "\n";
   return $fault;
}

my $cli = RPC::XML::Client->new($server_url);
$cli->error_handler(\&handle_error);
$cli->fault_handler(\&handle_fault);
my $resp = $cli->send_request($command,
   $appkey, $blogid, $username, $password, $title, $content, $publish);

#----------------------------------------------------------------------
#
#  bad password: gets server error, no helpful messages.
#  from looking at the Frontier code, if a 20x response is sent,
#  it looks like they will still pick up the fault
#
print STDERR "\nUsing Frontier::Client\n";
use Frontier::Client;
my $server = Frontier::Client->new(url=>$server_url);
eval {
   my $result = $server->call($command,
       $appkey, $blogid, $username, $password, $title, $content, $publish);
};
warn $@ if $@;

exit(0);

sub Usage {
   return "lc --title {title} --content {content} [--[no]publish] [--debug]\n";
}
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.