xmlrpc::transport::http(3)
NAME
XMLRPC::Transport::HTTP - Server/Client side HTTP support
for XMLRPC::Lite
SYNOPSIS
Client
use XMLRPC::Lite
proxy => 'http://localhost/',
# proxy => 'http://localhost/cgi-bin/xmlrpc.cgi', #
local CGI server
# proxy => 'http://localhost/', #
local daemon server
# proxy => 'http://login:password@localhost/cgibin/xmlrpc.cgi', # local CGI server with authentication
;
print getStateName(1);
CGI server
use XMLRPC::Transport::HTTP;
my $server = XMLRPC::Transport::HTTP::CGI
-> dispatch_to('methodName')
-> handle
;
Daemon server
use XMLRPC::Transport::HTTP;
my $daemon = XMLRPC::Transport::HTTP::Daemon
-> new (LocalPort => 80)
-> dispatch_to('methodName')
;
print "Contact to XMLRPC server at ", $daemon->url,
"0;
$daemon->handle;
DESCRIPTION
This class encapsulates all HTTP related logic for a XML
RPC server, independent of what web server it's attached
to. If you want to use this class you should follow sim
ple guideline mentioned above.
PROXY SETTINGS
- You can use any proxy setting you use with LWP::UserAgent
modules: - XMLRPC::Lite->proxy('http://endpoint.server/',
proxy => ['http' =>'http://my.proxy.server']);
- or
$xmlrpc->transport->proxy('http' =>- 'http://my.proxy.server');
- should specify proxy server for you. And if you use
"HTTP_proxy_user" and "HTTP_proxy_pass" for proxy autho
rization SOAP::Lite should know how to handle it properly. - COOKIE-BASED AUTHENTICATION
use HTTP::Cookies;- my $cookies = HTTP::Cookies->new(ignore_discard => 1);
# you may also add 'file' if you want to keep them between sessions
- my $xmlrpc = XMLRPC::Lite->proxy('http://localhost/');
$xmlrpc->transport->cookie_jar($cookies); - Cookies will be taken from response and provided for
request. You may always add another cookie (or extract
what you need after response) with HTTP::Cookies inter
face. - You may also do it in one line:
$xmlrpc->proxy('http://localhost/',cookie_jar => HTTP::Cookies->new(ignore_discard => 1));- COMPRESSION
- XMLRPC::Lite provides you option for enabling compression
on wire (for HTTP transport only). Both server and client
should support this capability, but this logic should be
absolutely transparent for your application. Server will
respond with encoded message only if client can accept it
(client sends Accept-Encoding with 'deflate' or '*' val
ues) and client has fallback logic, so if server doesn't
understand specified encoding (Content-Encoding: deflate)
and returns proper error code (415 NOT ACCEPTABLE) client
will repeat the same request not encoded and will store
this server in per-session cache, so all other requests
will go there without encoding. - Having options on client and server side that let you
specify threshold for compression you can safely enable
this feature on both client and server side. - Compression will be enabled on client side IF: threshold
is specified AND size of current message is bigger than
threshold AND module Compress::Zlib is available. Client
will send header 'Accept-Encoding' with value 'deflate' if
threshold is specified AND module Compress::Zlib is avail
able. - Server will accept compressed message if module Com
press::Zlib is available, and will respond with compressed
message ONLY IF: threshold is specified AND size of cur
rent message is bigger than threshold AND module Com
press::Zlib is available AND header 'Accept-Encoding' is
presented in request.
DEPENDENCIES
- Crypt::SSLeay for HTTPS/SSL
HTTP::Daemon for XMLRPC::Trans - port::HTTP::Daemon
Apache, Apache::Constants for XMLRPC::Trans - port::HTTP::Apache
SEE ALSO
- See ::CGI, ::Daemon and ::Apache for implementation de
- tails.
See examples/XMLRPC/* for examples.
COPYRIGHT
Copyright (C) 2000-2001 Paul Kulchenko. All rights
reserved.
This library is free software; you can redistribute it
and/or modify it under the same terms as Perl itself.
AUTHOR
- Paul Kulchenko (paulclinger@yahoo.com)