Skip Menu |
 

This queue is for tickets about the RPC-XML CPAN distribution.

Report information
The Basics
Id: 42298
Status: open
Priority: 0/
Queue: RPC-XML

People
Owner: rjray [...] blackperl.com
Requestors: mkanat [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Allow RPC::XML::Server to run in a mod_cgi environment
Download (untitled) / with headers
text/plain 665b
I am one of the primary maintainers of a web application (Bugzilla) that can run under both mod_cgi and mod_perl. We have to provide an XML-RPC interface in both circumstances. Right now RPC::XML::Server::process request does everything we'd need, but it's dependent upon having an HTTP::Daemon::ClientConn object--something we'll never have, running in a web app. Everything it needs out of $conn could be read from a CGI object just as easily, as far as I can see, but I don't want to copy the entirety of process_request into my code and modify it downstream. Any chance of getting an RPC::XML::Server that can run in a standard (non-mod_perl) CGI environment?
Download (untitled) / with headers
text/plain 107b
I'd like to be rid of my dependency on HTTP::Daemon::ClientConn, too. I will see how cleanly I can do this.
Subject: Re: [rt.cpan.org #42298] Allow RPC::XML::Server to run in a mod_cgi environment
Date: Sun, 12 Jul 2009 18:03:23 +0200
To: bug-RPC-XML [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.4k
Hi, Show quoted text
> Any chance of getting an RPC::XML::Server that can run in a standard > (non-mod_perl) CGI environment?
I think that it is possible even now - for example with a cgi script like this (tested with Apache + mod_cgi but should work with any CGI ready web server): ---- #!/usr/bin/perl -w use warnings; use strict; use RPC::XML::Server; my $parser = RPC::XML::Parser->new(); my $server = RPC::XML::Server->new(no_http => 1); ### at this point add whatever methods you want to publish over XMLRPC #$server->add_method(...); my $http_headers = $server->response->headers_as_string("\r\n"); my $request = $parser->parse(<STDIN>); my $result; if ((ref $request) && ($request->isa('RPC::XML::request'))) { $result = $server->dispatch($request); } else { $result = RPC::XML::response->new( RPC::XML::fault->new(200, "XML parse error: $request") ); } *STDOUT->syswrite($http_headers . "\r\n" . $result->as_string); ---- In attached archive you can find also a sample fastcgi script (you will need Apache + mod_fastcgi or mod_fcgid) that should be much better for production use (mostly for performance reasons). The question is whether it is necessary to implement some [Fast]CGI support directly in RPC::XML::Server. In my opinion it could be enough (at least as a first step) to mention in doc the possibility of running RPC::XML::Server via external web server as CGI/FastCGI (maybe providing sample scripts). -- kmx
Download sample_scripts.zip
application/octet-stream 982b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 684b
On Sun Jul 12 12:03:48 2009, kmx@volny.cz wrote: Show quoted text
> I think that it is possible even now - for example with a cgi script > like this (tested with Apache + mod_cgi but should work with any CGI > ready web server): > [snip]
Okay, I'm actually working on implementing this now. The script that you provided works well enough, but I don't get all the functionality of process_request, such as compression support, HEAD support, the built-in errors sent with send_error during parse failures, temp file support for responses, and everything else that process_request does. It would be nice if the request processing stuff could be separated from the existence of HTTP::Daemon.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.