{
"mode": "perldoc",
"parameter": "SOAP::Lite",
"section": "",
"url": "https://www.chedong.com/phpMan.php/perldoc/SOAP%3A%3ALite/json",
"generated": "2026-06-14T12:49:36Z",
"sections": {
"NAME": {
"content": "SOAP::Lite - Perl's Web Services Toolkit\n",
"subsections": []
},
"DESCRIPTION": {
"content": "SOAP::Lite is a collection of Perl modules which provides a simple and lightweight interface to\nthe Simple Object Access Protocol (SOAP) both on client and server side.\n",
"subsections": []
},
"PERL VERSION WARNING": {
"content": "As of version SOAP::Lite version 1.05, no perl versions before 5.8 will be supported.\n\nSOAP::Lite 0.71 will be the last version of SOAP::Lite running on perl 5.005\n\nFuture versions of SOAP::Lite will require at least perl 5.6.0\n\nIf you have not had the time to upgrade your perl, you should consider this now.\n",
"subsections": []
},
"OVERVIEW OF CLASSES AND PACKAGES": {
"content": "lib/SOAP/Lite.pm\nSOAP::Lite - Main class provides all logic\n\nSOAP::Transport - Transport backend\n\nSOAP::Data - Data objects\n\nSOAP::Header - Header Data Objects\n\nSOAP::Serializer - Serializes data structures to SOAP messages\n\nSOAP::Deserializer - Deserializes SOAP messages into SOAP::SOM objects\n\nSOAP::SOM - SOAP Message objects\n\nSOAP::Constants - Provides access to common constants and defaults\n\nSOAP::Trace - Tracing facilities\n\nSOAP::Schema - Provides access and stub(s) for schema(s)\n\nSOAP::Schema::WSDL - WSDL implementation for SOAP::Schema\n\nSOAP::Server - Handles requests on server side\n\nSOAP::Server::Object - Handles objects-by-reference\n\nSOAP::Fault - Provides support for Faults on server side\n\nSOAP::Utils - A set of private and public utility subroutines\n\nlib/SOAP/Packager.pm\nSOAP::Packager - Provides an abstract class for implementing custom packagers.\n\nSOAP::Packager::MIME - Provides MIME support to SOAP::Lite\n\nSOAP::Packager::DIME - Provides DIME support to SOAP::Lite\n\nlib/SOAP/Transport/HTTP.pm\nSOAP::Transport::HTTP::Client - Client interface to HTTP transport\n\nSOAP::Transport::HTTP::Server - Server interface to HTTP transport\n\nSOAP::Transport::HTTP::CGI - CGI implementation of server interface\n\nSOAP::Transport::HTTP::Daemon - Daemon implementation of server interface\n\nSOAP::Transport::HTTP::Apache - modperl implementation of server interface\n\nlib/SOAP/Transport/POP3.pm\nSOAP::Transport::POP3::Server - Server interface to POP3 protocol\n\nlib/SOAP/Transport/MAILTO.pm\nSOAP::Transport::MAILTO::Client - Client interface to SMTP/sendmail\n\nlib/SOAP/Transport/LOCAL.pm\nSOAP::Transport::LOCAL::Client - Client interface to local transport\n\nlib/SOAP/Transport/TCP.pm\nSOAP::Transport::TCP::Server - Server interface to TCP protocol\n\nSOAP::Transport::TCP::Client - Client interface to TCP protocol\n\nlib/SOAP/Transport/IO.pm\nSOAP::Transport::IO::Server - Server interface to IO transport\n",
"subsections": []
},
"METHODS": {
"content": "All accessor methods return the current value when called with no arguments, while returning the\nobject reference itself when called with a new value. This allows the set-attribute calls to be\nchained together.\n",
"subsections": [
{
"name": "new",
"content": "$client = SOAP::Lite->new(proxy => $endpoint)\n\nConstructor. Many of the accessor methods defined here may be initialized at creation by\nproviding their name as a key, followed by the desired value. The example provides the value\nfor the proxy element of the client.\n"
},
{
"name": "transport",
"content": "$transp = $client->transport( );\n\nGets or sets the transport object used for sending/receiving SOAP messages.\n\nSee SOAP::Transport for details.\n"
},
{
"name": "serializer",
"content": "$serial = $client->serializer( )\n\nGets or sets the serializer object used for creating XML messages.\n\nSee SOAP::Serializer for details.\n"
},
{
"name": "packager",
"content": "$packager = $client->packager( )\n\nProvides access to the \"SOAP::Packager\" object that the client uses to manage the use of\nattachments. The default packager is a MIME packager, but unless you specify parts to send,\nno MIME formatting will be done.\n\nSee also: SOAP::Packager.\n"
},
{
"name": "proxy",
"content": "$client->proxy('http://soap.xml.info/ endPoint');\n\nThe proxy is the server or endpoint to which the client is going to connect. This method\nallows the setting of the endpoint, along with any extra information that the transport\nobject may need when communicating the request.\n\nThis method is actually an alias to the proxy method of SOAP::Transport. It is the same as\ntyping:\n\n$client->transport( )->proxy(...arguments);\n\nExtra parameters can be passed to proxy() - see below.\n\ncompressthreshold\nSee COMPRESSION in HTTP::Transport.\n\nAll initialization options from the underlying transport layer\nThe options for HTTP(S) are the same as for LWP::UserAgent's new() method.\n\nA common option is to create a instance of HTTP::Cookies and pass it as cookiejar\noption:\n\nmy $cookiejar = HTTP::Cookies->new()\n$client->proxy('http://www.example.org/webservice',\ncookiejar => $cookiejar,\n);\n\nFor example, if you wish to set the HTTP timeout for a SOAP::Lite client to 5 seconds, use\nthe following code:\n\nmy $soap = SOAP::Lite\n->uri($uri)\n->proxy($proxyUrl, timeout => 5 );\n\nSee LWP::UserAgent.\n"
},
{
"name": "endpoint",
"content": "$client->endpoint('http://soap.xml.info/ newPoint')\n\nIt may be preferable to set a new endpoint without the additional work of examining the new\naddress for protocol information and checking to ensure the support code is loaded and\navailable. This method allows the caller to change the endpoint that the client is currently\nset to connect to, without reloading the relevant transport code. Note that the proxy method\nmust have been called before this method is used.\n"
},
{
"name": "service",
"content": "$client->service('http://svc.perl.org/Svc.wsdl');\n\n\"SOAP::Lite\" offers some support for creating method stubs from service descriptions. At\npresent, only WSDL support is in place. This method loads the specified WSDL schema and uses\nit as the basis for generating stubs.\n"
},
{
"name": "outputxml",
"content": "$client->outputxml('true');\n\nWhen set to a true value, the raw XML is returned by the call to a remote method.\n\nThe default is to return a SOAP::SOM object (false).\n"
},
{
"name": "autotype",
"content": "$client->autotype(0);\n\nThis method is a shortcut for:\n\n$client->serializer->autotype(boolean);\n\nBy default, the serializer tries to automatically deduce types for the data being sent in a\nmessage. Setting a false value with this method disables the behavior.\n"
},
{
"name": "readable",
"content": "$client->readable(1);\n\nThis method is a shortcut for:\n\n$client->serializer->readable(boolean);\n\nWhen this is used to set a true value for this property, the generated XML sent to the\nendpoint has extra characters (spaces and new lines) added in to make the XML itself more\nreadable to human eyes (presumably for debugging). The default is to not send any additional\ncharacters.\n"
},
{
"name": "headerattr",
"content": "$obj->headerattr({ attr1 => 'value' });\n\nAllows for the setting of arbitrary attributes on the header object. Keep in mind the\nrequirement that any attributes not natively known to SOAP must be namespace-qualified. If\nusing $session->call ($method, $callData, $callHeader), SOAP::Lite serializes information as\n\n\n\nxxxxx\nyyyyy\n\n\n\n\n\n\n\n\nThe attributes, given to headerattr are placed into the Header as\n\n\n"
},
{
"name": "bodyattr",
"content": "$obj->bodyattr({ attr1 => 'value' });\n\nAllows for the setting of arbitrary attributes on the body object. Keep in mind the\nrequirement that any attributes not natively known to SOAP must be namespace-qualified. See\nheaderattr\n"
},
{
"name": "default_ns",
"content": "Sets the default namespace for the request to the specified uri. This overrides any previous\nnamespace declaration that may have been set using a previous call to \"ns()\" or\n\"defaultns()\". Setting the default namespace causes elements to be serialized without a\nnamespace prefix, like this:\n\n\n\n\n\n\n\n\n\nSome .NET web services have been reported to require this XML namespace idiom.\n"
},
{
"name": "ns",
"content": "Sets the namespace uri and optionally the namespace prefix for the request to the specified\nvalues. This overrides any previous namespace declaration that may have been set using a\nprevious call to \"ns()\" or \"defaultns()\".\n\nIf a prefix is not specified, one will be generated for you automatically. Setting the\nnamespace causes elements to be serialized with a declared namespace prefix, like this:\n\n\n\n\n\n\n\n\n"
},
{
"name": "use_prefix",
"content": "Deprecated. Use the \"ns()\" and \"defaultns\" methods described above.\n\nShortcut for \"serializer->useprefix()\". This lets you turn on/off the use of a namespace\nprefix for the children of the /Envelope/Body element. Default is 'true'.\n\nWhen useprefix is set to 'true', serialized XML will look like this:\n\n\n\n\n\n\n\nWhen useprefix is set to 'false', serialized XML will look like this:\n\n\n\n\n\n\n\nSome .NET web services have been reported to require this XML namespace idiom.\n"
},
{
"name": "soapversion",
"content": "$client->soapversion('1.2');\n\nIf no parameter is given, returns the current version of SOAP that is being used by the\nclient object to encode requests. If a parameter is given, the method attempts to set that\nas the version of SOAP being used.\n\nThe value should be either 1.1 or 1.2.\n"
},
{
"name": "envprefix",
"content": "$client->envprefix('env');\n\nThis method is a shortcut for:\n\n$client->serializer->envprefix(QName);\n\nGets or sets the namespace prefix for the SOAP namespace. The default is SOAP.\n\nThe prefix itself has no meaning, but applications may wish to chose one explicitly to\ndenote different versions of SOAP or the like.\n"
},
{
"name": "encprefix",
"content": "$client->encprefix('enc');\n\nThis method is a shortcut for:\n\n$client->serializer->encprefix(QName);\n\nGets or sets the namespace prefix for the encoding rules namespace. The default value is\nSOAP-ENC.\n\nWhile it may seem to be an unnecessary operation to set a value that isn't relevant to the\nmessage, such as the namespace labels for the envelope and encoding URNs, the ability to set\nthese labels explicitly can prove to be a great aid in distinguishing and debugging messages on\nthe server side of operations.\n"
},
{
"name": "encoding",
"content": "$client->encoding($soap12encodingURN);\n\nThis method is a shortcut for:\n\n$client->serializer->encoding(args);\n\nWhere the earlier method dealt with the label used for the attributes related to the SOAP\nencoding scheme, this method actually sets the URN to be specified as the encoding scheme\nfor the message. The default is to specify the encoding for SOAP 1.1, so this is handy for\napplications that need to encode according to SOAP 1.2 rules.\n\ntypelookup\n$client->typelookup;\n\nThis method is a shortcut for:\n\n$client->serializer->typelookup;\n\nGives the application access to the type-lookup table from the serializer object. See the\nsection on SOAP::Serializer.\n"
},
{
"name": "uri",
"content": "Deprecated - the \"uri\" subroutine is deprecated in order to provide a more intuitive naming\nscheme for subroutines that set namespaces. In the future, you will be required to use\neither the \"ns()\" or \"defaultns()\" subroutines instead of \"uri()\".\n\n$client->uri($serviceuri);\n\nThis method is a shortcut for:\n\n$client->serializer->uri(service);\n\nThe URI associated with this accessor on a client object is the service-specifier for the\nrequest, often encoded for HTTP-based requests as the SOAPAction header. While the names may\nseem confusing, this method doesn't specify the endpoint itself. In most circumstances, the\n\"uri\" refers to the namespace used for the request.\n\nOften times, the value may look like a valid URL. Despite this, it doesn't have to point to\nan existing resource (and often doesn't). This method sets and retrieves this value from the\nobject. Note that no transport code is triggered by this because it has no direct effect on\nthe transport of the object.\n"
},
{
"name": "multirefinplace",
"content": "$client->multirefinplace(1);\n\nThis method is a shortcut for:\n\n$client->serializer->multirefinplace(boolean);\n\nControls how the serializer handles values that have multiple references to them. Recall\nfrom previous SOAP chapters that a value may be tagged with an identifier, then referred to\nin several places. When this is the case for a value, the serializer defaults to putting the\ndata element towards the top of the message, right after the opening tag of the\nmethod-specification. It is serialized as a standalone entity with an ID that is then\nreferenced at the relevant places later on. If this method is used to set a true value, the\nbehavior is different. When the multirefinplace attribute is true, the data is serialized at\nthe first place that references it, rather than as a separate element higher up in the body.\nThis is more compact but may be harder to read or trace in a debugging environment.\n"
},
{
"name": "parts",
"content": "Used to specify an array of MIME::Entity's to be attached to the transmitted SOAP message.\nAttachments that are returned in a response can be accessed by \"SOAP::SOM::parts()\".\n\nself\n$ref = SOAP::Lite->self;\n\nReturns an object reference to the default global object the \"SOAP::Lite\" package maintains.\nThis is the object that processes many of the arguments when provided on the use line.\n\nThe following method isn't an accessor style of method but neither does it fit with the group\nthat immediately follows it:\n"
},
{
"name": "call",
"content": "$client->call($method => @arguments);\n\nAs has been illustrated in previous chapters, the \"SOAP::Lite\" client objects can manage\nremote calls with auto-dispatching using some of Perl's more elaborate features. call is\nused when the application wants a greater degree of control over the details of the call\nitself. The method may be built up from a SOAP::Data object, so as to allow full control\nover the namespace associated with the tag, as well as other attributes like encoding. This\nis also important for calling methods that contain characters not allowable in Perl function\nnames, such as A.B.C.\n\nThe next four methods used in the \"SOAP::Lite\" class are geared towards handling the types of\nevents than can occur during the message lifecycle. Each of these sets up a callback for the\nevent in question:\n"
},
{
"name": "on_action",
"content": "$client->onaction(sub { qq(\"$[0]\") });\n\nTriggered when the transport object sets up the SOAPAction header for an HTTP-based call.\nThe default is to set the header to the string, uri#method, in which URI is the value set by\nthe uri method described earlier, and method is the name of the method being called. When\ncalled, the routine referenced (or the closure, if specified as in the example) is given two\narguments, uri and method, in that order.\n\n.NET web services usually expect \"/\" as separator for \"uri\" and \"method\". To change\nSOAP::Lite's behaviour to use uri/method as SOAPAction header, use the following code:\n\n$client->onaction( sub { join '/', @ } );\n"
},
{
"name": "on_fault",
"content": "$client->onfault(sub { popupdialog($[1]) });\n\nTriggered when a method call results in a fault response from the server. When it is called,\nthe argument list is first the client object itself, followed by the object that\nencapsulates the fault. In the example, the fault object is passed (without the client\nobject) to a hypothetical GUI function that presents an error dialog with the text of fault\nextracted from the object (which is covered shortly under the SOAP::SOM methods).\n"
},
{
"name": "on_nonserialized",
"content": "$client->onnonserialized(sub { die \"$[0]?!?\" });\n\nOccasionally, the serializer may be given data it can't turn into SOAP-savvy XML; for\nexample, if a program bug results in a code reference or something similar being passed in\nas a parameter to method call. When that happens, this callback is activated, with one\nargument. That argument is the data item that could not be understood. It will be the only\nargument. If the routine returns, the return value is pasted into the message as the\nserialization. Generally, an error is in order, and this callback allows for control over\nsignaling that error.\n"
},
{
"name": "on_debug",
"content": "$client->ondebug(sub { print @ });\n\nDeprecated. Use the global +debug and +trace facilities described in SOAP::Trace\n\nNote that this method will not work as expected: Instead of affecting the debugging\nbehaviour of the object called on, it will globally affect the debugging behaviour for all\nobjects of that class.\n"
}
]
},
"WRITING A SOAP CLIENT": {
"content": "This chapter guides you to writing a SOAP client by example.\n\nThe SOAP service to be accessed is a simple variation of the well-known hello world program. It\naccepts two parameters, a name and a given name, and returns \"Hello $givenname $name\".\n\nWe will use \"Martin Kutter\" as the name for the call, so all variants will print the following\nmessage on success:\n\nHello Martin Kutter!\n\nSOAP message styles\nThere are three common (and one less common) variants of SOAP messages.\n\nThese address the message style (positional parameters vs. specified message documents) and\nencoding (as-is vs. typed).\n\nThe different message styles are:\n\n* rpc/encoded\n\nTyped, positional parameters. Widely used in scripting languages. The type of the arguments\nis included in the message. Arrays and the like may be encoded using SOAP encoding rules (or\nothers).\n\n* rpc/literal\n\nAs-is, positional parameters. The type of arguments is defined by some pre-exchanged\ninterface definition.\n\n* document/encoded\n\nSpecified message with typed elements. Rarely used.\n\n* document/literal\n\nSpecified message with as-is elements. The message specification and element types are\ndefined by some pre-exchanged interface definition.\n\nAs of 2008, document/literal has become the predominant SOAP message variant. rpc/literal and\nrpc/encoded are still in use, mainly with scripting languages, while document/encoded is hardly\nused at all.\n\nYou will see clients for the rpc/encoded and document/literal SOAP variants in this section.\n",
"subsections": [
{
"name": "Example implementations",
"content": "RPC/ENCODED\nRpc/encoded is most popular with scripting languages like perl, php and python without the use\nof a WSDL. Usual method descriptions look like this:\n\nMethod: sayHello(string, string)\nParameters:\nname: string\ngivenName: string\n\nSuch a description usually means that you can call a method named \"sayHello\" with two positional\nparameters, \"name\" and \"givenName\", which both are strings.\n\nThe message corresponding to this description looks somewhat like this:\n\n\nKutter\nMartin\n\n\nAny XML tag names may be used instead of the \"s-gensym01\" stuff - parameters are positional, the\ntag names have no meaning.\n\nA client producing such a call is implemented like this:\n\nuse SOAP::Lite;\nmy $soap = SOAP::Lite->new( proxy => 'http://localhost:81/soap-wsdl-test/helloworld.pl');\n$soap->defaultns('urn:HelloWorld');\nmy $som = $soap->call('sayHello', 'Kutter', 'Martin');\ndie $som->faultstring if ($som->fault);\nprint $som->result, \"\\n\";\n\nYou can of course use a one-liner, too...\n\nSometimes, rpc/encoded interfaces are described with WSDL definitions. A WSDL accepting \"named\"\nparameters with rpc/encoded looks like this:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe message corresponding to this schema looks like this:\n\n\nKutter\nMartin\n\n\nA web service client using this schema looks like this:\n\nuse SOAP::Lite;\nmy $soap = SOAP::Lite->service(\"file:sayhellorpcenc.wsdl\");\neval { my $result = $soap->sayHello('Kutter', 'Martin'); };\nif ($@) {\ndie $@;\n}\nprint $som->result();\n\nYou may of course also use the following one-liner:\n\nperl -MSOAP::Lite -e 'print SOAP::Lite->service(\"file:sayhellorpcenc.wsdl\")\\\n->sayHello('Kutter', 'Martin'), \"\\n\";'\n\nA web service client (without a service description) looks like this.\n\nuse SOAP::Lite;\nmy $soap = SOAP::Lite->new( proxy => 'http://localhost:81/soap-wsdl-test/helloworld.pl');\n$soap->defaultns('urn:HelloWorld');\nmy $som = $soap->call('sayHello',\nSOAP::Data->name('name')->value('Kutter'),\nSOAP::Data->name('givenName')->value('Martin')\n);\ndie $som->faultstring if ($som->fault);\nprint $som->result, \"\\n\";\n\nRPC/LITERAL\nSOAP web services using the document/literal message encoding are usually described by some Web\nService Definition. Our web service has the following WSDL description:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe XML message (inside the SOAP Envelope) look like this:\n\n\n\nKutter\nMartin\n\n\n\n\n\nHello Martin Kutter!\n\n\n\nThis is the SOAP::Lite implementation for the web service client:\n\nuse SOAP::Lite +trace;\nmy $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');\n\n$soap->onaction( sub { \"urn:HelloWorld#sayHello\" });\n$soap->autotype(0)->readable(1);\n$soap->defaultns('urn:HelloWorld');\n\nmy $som = $soap->call('sayHello', SOAP::Data->name('parameters')->value(\n\\SOAP::Data->value([\nSOAP::Data->name('name')->value( 'Kutter' ),\nSOAP::Data->name('givenName')->value('Martin'),\n]))\n);\n\ndie $som->fault->{ faultstring } if ($som->fault);\nprint $som->result, \"\\n\";\n\nDOCUMENT/LITERAL\nSOAP web services using the document/literal message encoding are usually described by some Web\nService Definition. Our web service has the following WSDL description:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe XML message (inside the SOAP Envelope) look like this:\n\n\nKutter\nMartin\n\n\n\nHello Martin Kutter!\n\n\nYou can call this web service with the following client code:\n\nuse SOAP::Lite;\nmy $soap = SOAP::Lite->new( proxy => 'http://localhost:80/helloworld.pl');\n\n$soap->onaction( sub { \"urn:HelloWorld#sayHello\" });\n$soap->autotype(0);\n$soap->defaultns('urn:HelloWorld');\n\nmy $som = $soap->call(\"sayHello\",\nSOAP::Data->name('name')->value( 'Kutter' ),\nSOAP::Data->name('givenName')->value('Martin'),\n);\n\ndie $som->fault->{ faultstring } if ($som->fault);\nprint $som->result, \"\\n\";\n"
},
{
"name": "Differences between the implementations",
"content": "You may have noticed that there's little difference between the rpc/encoded, rpc/literal and the\ndocument/literal example's implementation. In fact, from SOAP::Lite's point of view, the only\ndifferences between rpc/literal and document/literal that parameters are always named.\n\nIn our example, the rpc/encoded variant already used named parameters (by using two messages),\nso there's no difference at all.\n\nYou may have noticed the somewhat strange idiom for passing a list of named parameters in the\nrpc/literal example:\n\nmy $som = $soap->call('sayHello', SOAP::Data->name('parameters')->value(\n\\SOAP::Data->value([\nSOAP::Data->name('name')->value( 'Kutter' ),\nSOAP::Data->name('givenName')->value('Martin'),\n]))\n);\n\nWhile SOAP::Data provides full control over the XML generated, passing hash-like structures\nrequire additional coding.\n"
}
]
},
"WRITING A SOAP SERVER": {
"content": "See SOAP::Server, or SOAP::Transport.\n",
"subsections": []
},
"FEATURES": {
"content": "ATTACHMENTS\n\"SOAP::Lite\" features support for the SOAP with Attachments specification. Currently, SOAP::Lite\nonly supports MIME based attachments. DIME based attachments are yet to be fully functional.\n\nEXAMPLES\nClient sending an attachment\n\"SOAP::Lite\" clients can specify attachments to be sent along with a request by using the\n\"SOAP::Lite::parts()\" method, which takes as an argument an ARRAY of \"MIME::Entity\"'s.\n\nuse SOAP::Lite;\nuse MIME::Entity;\nmy $ent = build MIME::Entity\nType => \"image/gif\",\nEncoding => \"base64\",\nPath => \"somefile.gif\",\nFilename => \"saveme.gif\",\nDisposition => \"attachment\";\nmy $som = SOAP::Lite\n->uri($SOMENAMESPACE)\n->parts([ $ent ])\n->proxy($SOMEHOST)\n->somemethod(SOAP::Data->name(\"foo\" => \"bar\"));\n\nClient retrieving an attachment\nA client accessing attachments that were returned in a response by using the\n\"SOAP::SOM::parts()\" accessor.\n\nuse SOAP::Lite;\nuse MIME::Entity;\nmy $soap = SOAP::Lite\n->uri($NS)\n->proxy($HOST);\nmy $som = $soap->foo();\nforeach my $part (${$som->parts}) {\nprint $part->stringify;\n}\n\nServer receiving an attachment\nServers, like clients, use the SOAP::SOM module to access attachments transmitted to it.\n\npackage Attachment;\nuse SOAP::Lite;\nuse MIME::Entity;\nuse strict;\nuse vars qw(@ISA);\n@ISA = qw(SOAP::Server::Parameters);\nsub someMethod {\nmy $self = shift;\nmy $envelope = pop;\nforeach my $part (@{$envelope->parts}) {\nprint \"AttachmentService: attachment found! (\".ref($part).\")\\n\";\n}\n# do something\n}\n\nServer responding with an attachment\nServers wishing to return an attachment to the calling client need only return \"MIME::Entity\"\nobjects along with SOAP::Data elements, or any other data intended for the response.\n\npackage Attachment;\nuse SOAP::Lite;\nuse MIME::Entity;\nuse strict;\nuse vars qw(@ISA);\n@ISA = qw(SOAP::Server::Parameters);\nsub someMethod {\nmy $self = shift;\nmy $envelope = pop;\nmy $ent = build MIME::Entity\n'Id' => \"<1234>\",\n'Type' => \"text/xml\",\n'Path' => \"some.xml\",\n'Filename' => \"some.xml\",\n'Disposition' => \"attachment\";\nreturn SOAP::Data->name(\"foo\" => \"blah blah blah\"),$ent;\n}\n\nDEFAULT SETTINGS\nThough this feature looks similar to autodispatch they have (almost) nothing in common. This\ncapability allows you specify default settings so that all objects created after that will be\ninitialized with the proper default settings.\n\nIf you wish to provide common \"proxy()\" or \"uri()\" settings for all \"SOAP::Lite\" objects in your\napplication you may do:\n\nuse SOAP::Lite\nproxy => 'http://localhost/cgi-bin/soap.cgi',\nuri => 'http://my.own.com/My/Examples';\n\nmy $soap1 = new SOAP::Lite; # will get the same proxy()/uri() as above\nprint $soap1->getStateName(1)->result;\n\nmy $soap2 = SOAP::Lite->new; # same thing as above\nprint $soap2->getStateName(2)->result;\n\n# or you may override any settings you want\nmy $soap3 = SOAP::Lite->proxy('http://localhost/');\nprint $soap3->getStateName(1)->result;\n\nAny \"SOAP::Lite\" properties can be propagated this way. Changes in object copies will not affect\nglobal settings and you may still change global settings with \"SOAP::Lite->self\" call which\nreturns reference to global object. Provided parameter will update this object and you can even\nset it to \"undef\":\n\nSOAP::Lite->self(undef);\n\nThe \"use SOAP::Lite\" syntax also lets you specify default event handlers for your code. If you\nhave different SOAP objects and want to share the same \"onaction()\" (or \"onfault()\" for that\nmatter) handler. You can specify \"onaction()\" during initialization for every object, but you\nmay also do:\n\nuse SOAP::Lite\nonaction => sub {sprintf '%s#%s', @};\n\nand this handler will be the default handler for all your SOAP objects. You can override it if\nyou specify a handler for a particular object. See t/*.t for example of onfault() handler.\n\nBe warned, that since \"use ...\" is executed at compile time all \"use\" statements will be\nexecuted before script execution that can make unexpected results. Consider code:\n\nuse SOAP::Lite proxy => 'http://localhost/';\nprint SOAP::Lite->getStateName(1)->result;\n\nuse SOAP::Lite proxy => 'http://localhost/cgi-bin/soap.cgi';\nprint SOAP::Lite->getStateName(1)->result;\n\nBoth SOAP calls will go to 'http://localhost/cgi-bin/soap.cgi'. If you want to execute \"use\" at\nrun-time, put it in \"eval\":\n\neval \"use SOAP::Lite proxy => 'http://localhost/cgi-bin/soap.cgi'; 1\" or die;\n\nOr alternatively,\n\nSOAP::Lite->self->proxy('http://localhost/cgi-bin/soap.cgi');\n\nSETTING MAXIMUM MESSAGE SIZE\nOne feature of \"SOAP::Lite\" is the ability to control the maximum size of a message a SOAP::Lite\nserver will be allowed to process. To control this feature simply define\n$SOAP::Constants::MAXCONTENTSIZE in your code like so:\n\nuse SOAP::Transport::HTTP;\nuse MIME::Entity;\n$SOAP::Constants::MAXCONTENTSIZE = 10000;\nSOAP::Transport::HTTP::CGI\n->dispatchto('TemperatureService')\n->handle;\n\nIN/OUT, OUT PARAMETERS AND AUTOBINDING\n\"SOAP::Lite\" gives you access to all parameters (both in/out and out) and also does some\nadditional work for you. Lets consider following example:\n\n\nname1\nname2\nname3\n\n\nIn that case:\n\n$result = $r->result; # gives you 'name1'\n$paramout1 = $r->paramsout; # gives you 'name2', because of scalar context\n$paramout1 = ($r->paramsout)[0]; # gives you 'name2' also\n$paramout2 = ($r->paramsout)[1]; # gives you 'name3'\n\nor\n\n@paramsout = $r->paramsout; # gives you ARRAY of out parameters\n$paramout1 = $paramsout[0]; # gives you 'res2', same as ($r->paramsout)[0]\n$paramout2 = $paramsout[1]; # gives you 'res3', same as ($r->paramsout)[1]\n\nGenerally, if server returns \"return (1,2,3)\" you will get 1 as the result and 2 and 3 as out\nparameters.\n\nIf the server returns \"return [1,2,3]\" you will get an ARRAY reference from \"result()\" and\n\"undef\" from \"paramsout()\".\n\nResults can be arbitrary complex: they can be an array references, they can be objects, they can\nbe anything and still be returned by \"result()\" . If only one parameter is returned,\n\"paramsout()\" will return \"undef\".\n\nFurthermore, if you have in your output parameters a parameter with the same signature\n(name+type) as in the input parameters this parameter will be mapped into your input\nautomatically. For example:\n\nServer Code:\n\nsub mymethod {\nshift; # object/class reference\nmy $param1 = shift;\nmy $param2 = SOAP::Data->name('myparam' => shift() * 2);\nreturn $param1, $param2;\n}\n\nClient Code:\n\n$a = 10;\n$b = SOAP::Data->name('myparam' => 12);\n$result = $soap->mymethod($a, $b);\n\nAfter that, \"$result == 10 and $b->value == 24\"! Magic? Sort of.\n\nAutobinding gives it to you. That will work with objects also with one difference: you do not\nneed to worry about the name and the type of object parameter. Consider the \"PingPong\" example\n(examples/My/PingPong.pm and examples/pingpong.pl):\n\nServer Code:\n\npackage My::PingPong;\n\nsub new {\nmy $self = shift;\nmy $class = ref($self) || $self;\nbless {num=>shift} => $class;\n}\n\nsub next {\nmy $self = shift;\n$self->{num}++;\n}\n\nClient Code:\n\nuse SOAP::Lite +autodispatch =>\nuri => 'urn:',\nproxy => 'http://localhost/';\n\nmy $p = My::PingPong->new(10); # $p->{num} is 10 now, real object returned\nprint $p->next, \"\\n\"; # $p->{num} is 11 now!, object autobinded\n\nSTATIC AND DYNAMIC SERVICE DEPLOYMENT\nLet us scrutinize the deployment process. When designing your SOAP server you can consider two\nkind of deployment: static and dynamic. For both, static and dynamic, you should specify\n\"MODULE\", \"MODULE::method\", \"method\" or \"PATH/\" when creating \"use\"ing the SOAP::Lite module.\nThe difference between static and dynamic deployment is that in case of 'dynamic', any module\nwhich is not present will be loaded on demand. See the \"SECURITY\" section for detailed\ndescription.\n\nWhen statically deploying a SOAP Server, you need to know all modules handling SOAP requests\nbefore.\n\nDynamic deployment allows extending your SOAP Server's interface by just installing another\nmodule into the dispatchto path (see below).\n\nSTATIC DEPLOYMENT EXAMPLE\nuse SOAP::Transport::HTTP;\nuse My::Examples; # module is preloaded\n\nSOAP::Transport::HTTP::CGI\n# deployed module should be present here or client will get\n# 'access denied'\n-> dispatchto('My::Examples')\n-> handle;\n\nFor static deployment you should specify the MODULE name directly.\n\nYou should also use static binding when you have several different classes in one file and want\nto make them available for SOAP calls.\n\nDYNAMIC DEPLOYMENT EXAMPLE\nuse SOAP::Transport::HTTP;\n# name is unknown, module will be loaded on demand\n\nSOAP::Transport::HTTP::CGI\n# deployed module should be present here or client will get 'access denied'\n-> dispatchto('/Your/Path/To/Deployed/Modules', 'My::Examples')\n-> handle;\n\nFor dynamic deployment you can specify the name either directly (in that case it will be\n\"require\"d without any restriction) or indirectly, with a PATH. In that case, the ONLY path that\nwill be available will be the PATH given to the dispatchto() method). For information how to\nhandle this situation see \"SECURITY\" section.\n\nSUMMARY\ndispatchto(\n# dynamic dispatch that allows access to ALL modules in specified directory\nPATH/TO/MODULES\n# 1. specifies directory\n# -- AND --\n# 2. gives access to ALL modules in this directory without limits\n\n# static dispatch that allows access to ALL methods in particular MODULE\nMODULE\n# 1. gives access to particular module (all available methods)\n# PREREQUISITES:\n# module should be loaded manually (for example with 'use ...')\n# -- OR --\n# you can still specify it in PATH/TO/MODULES\n\n# static dispatch that allows access to particular method ONLY\nMODULE::method\n# same as MODULE, but gives access to ONLY particular method,\n# so there is not much sense to use both MODULE and MODULE::method\n# for the same MODULE\n);\n\nIn addition to this \"SOAP::Lite\" also supports an experimental syntax that allows you to bind a\nspecific URL or SOAPAction to a CLASS/MODULE or object.\n\nFor example:\n\ndispatchwith({\nURI => MODULE, # 'http://www.soaplite.com/' => 'My::Class',\nSOAPAction => MODULE, # 'http://www.soaplite.com/method' => 'Another::Class',\nURI => object, # 'http://www.soaplite.com/obj' => My::Class->new,\n})\n\n\"URI\" is checked before \"SOAPAction\". You may use both the \"dispatchto()\" and \"dispatchwith()\"\nmethods in the same server, but note that \"dispatchwith()\" has a higher order of precedence.\n\"dispatchto()\" will be checked only after \"URI\" and \"SOAPAction\" has been checked.\n\nSee also: EXAMPLE APACHE::REGISTRY USAGE, \"SECURITY\"\n\nCOMPRESSION\n\"SOAP::Lite\" provides you option to enable transparent compression over the wire. Compression\ncan be enabled by specifying a threshold value (in the form of kilobytes) for compression on\nboth the client and server sides:\n\n*Note: Compression currently only works for HTTP based servers and clients.*\n\nClient Code\n\nprint SOAP::Lite\n->uri('http://localhost/My/Parameters')\n->proxy('http://localhost/', options => {compressthreshold => 10000})\n->echo(1 x 10000)\n->result;\n\nServer Code\n\nmy $server = SOAP::Transport::HTTP::CGI\n->dispatchto('My::Parameters')\n->options({compressthreshold => 10000})\n->handle;\n\nFor more information see COMPRESSION in HTTP::Transport.\n",
"subsections": []
},
"SECURITY": {
"content": "For security reasons, the existing path for Perl modules (@INC) will be disabled once you have\nchosen dynamic deployment and specified your own \"PATH/\". If you wish to access other modules in\nyour included package you have several options:\n\n1 Switch to static linking:\n\nuse MODULE;\n$server->dispatchto('MODULE');\n\nWhich can also be useful when you want to import something specific from the deployed\nmodules:\n\nuse MODULE qw(importlist);\n\n2 Change \"use\" to \"require\". The path is only unavailable during the initialization phase. It\nis available once more during execution. Therefore, if you utilize \"require\" somewhere in\nyour package, it will work.\n\n3 Wrap \"use\" in an \"eval\" block:\n\neval 'use MODULE qw(importlist)'; die if $@;\n\n4 Set your include path in your package and then specify \"use\". Don't forget to put @INC in a\n\"BEGIN{}\" block or it won't work. For example,\n\nBEGIN { @INC = qw(mydirectory); use MODULE }\n",
"subsections": []
},
"INTEROPERABILITY": {
"content": "",
"subsections": [
{
"name": "Microsoft .NET client with SOAP::Lite Server",
"content": "In order to use a .NET client with a SOAP::Lite server, be sure you use fully qualified names\nfor your return values. For example:\n\nreturn SOAP::Data->name('myname')\n->type('string')\n->uri($MYNAMESPACE)\n->value($output);\n\nIn addition see comment about default encoding in .NET Web Services below.\n\nSOAP::Lite client with a .NET server\nIf experiencing problems when using a SOAP::Lite client to call a .NET Web service, it is\nrecommended you check, or adhere to all of the following recommendations:\n\nDeclare a proper soapAction in your call\nFor example, use \"onaction( sub { 'http://www.myuri.com/WebService.aspx#someMethod'; } )\".\n\nDisable charset definition in Content-type header\nSome users have said that Microsoft .NET prefers the value of the Content-type header to be\na mimetype exclusively, but SOAP::Lite specifies a character set in addition to the\nmimetype. This results in an error similar to:\n\nServer found request content type to be 'text/xml; charset=utf-8',\nbut expected 'text/xml'\n\nTo turn off this behavior specify use the following code:\n\nuse SOAP::Lite;\n$SOAP::Constants::DONOTUSECHARSET = 1;\n# The rest of your code\n\nUse fully qualified name for method parameters\nFor example, the following code is preferred:\n\nSOAP::Data->name(Query => 'biztalk')\n->uri('http://tempuri.org/')\n\nAs opposed to:\n\nSOAP::Data->name('Query' => 'biztalk')\n\nPlace method in default namespace\nFor example, the following code is preferred:\n\nmy $method = SOAP::Data->name('add')\n->attr({xmlns => 'http://tempuri.org/'});\nmy @rc = $soap->call($method => @parms)->result;\n\nAs opposed to:\n\nmy @rc = $soap->call(add => @parms)->result;\n# -- OR --\nmy @rc = $soap->add(@parms)->result;\n\nDisable use of explicit namespace prefixes\nSome user's have reported that .NET will simply not parse messages that use namespace\nprefixes on anything but SOAP elements themselves. For example, the following XML would not\nbe parsed:\n\n\n\n\n\n\n\nSOAP::Lite allows users to disable the use of explicit namespaces through the \"useprefix()\"\nmethod. For example, the following code:\n\n$som = SOAP::Lite->uri('urn:MyURI')\n->proxy($HOST)\n->useprefix(0)\n->myMethod();\n\nWill result in the following XML, which is more palatable by .NET:\n\n\n\n\n\n\n\nModify your .NET server, if possible\nStefan Pharies :\n\nSOAP::Lite uses the SOAP encoding (section 5 of the soap 1.1 spec), and the default for .NET\nWeb Services is to use a literal encoding. So elements in the request are unqualified, but\nyour service expects them to be qualified. .Net Web Services has a way for you to change the\nexpected message format, which should allow you to get your interop working. At the top of\nyour class in the asmx, add this attribute (for Beta 1):\n\n[SoapService(Style=SoapServiceStyle.RPC)]\n\nAnother source said it might be this attribute (for Beta 2):\n\n[SoapRpcService]\n\nFull Web Service text may look like:\n\n<%@ WebService Language=\"C#\" Class=\"Test\" %>\nusing System;\nusing System.Web.Services;\nusing System.Xml.Serialization;\n\n[SoapService(Style=SoapServiceStyle.RPC)]\npublic class Test : WebService {\n[WebMethod]\npublic int add(int a, int b) {\nreturn a + b;\n}\n}\n\nAnother example from Kirill Gavrylyuk :\n\n\"You can insert [SoapRpcService()] attribute either on your class or on operation level\".\n\n<%@ WebService Language=CS class=\"DataType.StringTest\"%>\n\nnamespace DataType {\n\nusing System;\nusing System.Web.Services;\nusing System.Web.Services.Protocols;\nusing System.Web.Services.Description;\n\n[SoapRpcService()]\npublic class StringTest: WebService {\n[WebMethod]\n[SoapRpcMethod()]\npublic string RetString(string x) {\nreturn(x);\n}\n}\n}\n\nExample from Yann Christensen :\n\nusing System;\nusing System.Web.Services;\nusing System.Web.Services.Protocols;\n\nnamespace Currency {\n[WebService(Namespace=\"http://www.yourdomain.com/example\")]\n[SoapRpcService]\npublic class Exchange {\n[WebMethod]\npublic double getRate(String country, String country2) {\nreturn 122.69;\n}\n}\n}\n\nSpecial thanks goes to the following people for providing the above description and details on\n.NET interoperability issues:\n\nPetr Janata ,\n\nStefan Pharies ,\n\nBrian Jepson , and others\n"
}
]
},
"TROUBLESHOOTING": {
"content": "SOAP::Lite serializes \"18373\" as an integer, but I want it to be a string!\nSOAP::Lite guesses datatypes from the content provided, using a set of common-sense rules.\nThese rules are not 100% reliable, though they fit for most data.\n\nYou may force the type by passing a SOAP::Data object with a type specified:\n\nmy $proxy = SOAP::Lite->proxy('http://www.example.org/soapservice');\nmy $som = $proxy->myMethod(\nSOAP::Data->name('foo')->value(12345)->type('string')\n);\n\nYou may also change the precedence of the type-guessing rules. Note that this means fiddling\nwith SOAP::Lite's internals - this may not work as expected in future versions.\n\nThe example above forces everything to be encoded as string (this is because the string test\nis normally last and always returns true):\n\nmy @list = qw(-1 45 foo bar 3838);\nmy $proxy = SOAP::Lite->uri($uri)->proxy($proxyUrl);\nmy $lookup = $proxy->serializer->typelookup;\n$lookup->{string}->[0] = 0;\n$proxy->serializer->typelookup($lookup);\n$proxy->myMethod(\\@list);\n\nSee SOAP::Serializer for more details.\n\n\"+autodispatch\" doesn't work in Perl 5.8\nThere is a bug in Perl 5.8's \"UNIVERSAL::AUTOLOAD\" functionality that prevents the\n\"+autodispatch\" functionality from working properly. The workaround is to use\n\"dispatchfrom\" instead. Where you might normally do something like this:\n\nuse Some::Module;\nuse SOAP::Lite +autodispatch =>\nuri => 'urn:Foo'\nproxy => 'http://...';\n\nYou would do something like this:\n\nuse SOAP::Lite dispatchfrom(Some::Module) =>\nuri => 'urn:Foo'\nproxy => 'http://...';\n\nProblems using SOAP::Lite's COM Interface\n\nCan't call method \"server\" on undefined value\nYou probably did not register Lite.dll using \"regsvr32 Lite.dll\"\n\nFailed to load PerlCtrl Runtime\nIt is likely that you have install Perl in two different locations and the location of\nActiveState's Perl is not the first instance of Perl specified in your PATH. To rectify,\nrename the directory in which the non-ActiveState Perl is installed, or be sure the path\nto ActiveState's Perl is specified prior to any other instance of Perl in your PATH.\n\nDynamic libraries are not found\nIf you are using the Apache web server, and you are seeing something like the following in\nyour webserver log file:\n\nCan't load '/usr/local/lib/perl5/siteperl/.../XML/Parser/Expat/Expat.so'\nfor module XML::Parser::Expat: dynamic linker: /usr/local/bin/perl:\nlibexpat.so.0 is NEEDED, but object does not exist at\n/usr/local/lib/perl5/.../DynaLoader.pm line 200.\n\nThen try placing the following into your httpd.conf file and see if it fixes your problem.\n\n\nPassEnv LDLIBRARYPATH\n\n\nSOAP client reports \"500 unexpected EOF before status line seen\nSee \"Apache is crashing with segfaults\"\n\nApache is crashing with segfaults\nUsing \"SOAP::Lite\" (or XML::Parser::Expat) in combination with modperl causes random\nsegmentation faults in httpd processes. To fix, try configuring Apache with the following:\n\nRULEEXPAT=no\n\nIf you are using Apache 1.3.20 and later, try configuring Apache with the following option:\n\n./configure --disable-rule=EXPAT\n\nSee http://archive.covalent.net/modperl/2000/04/0185.xml for more details and lot of thanks\nto Robert Barta for explaining this weird behavior.\n\nIf this doesn't address the problem, you may wish to try \"-Uusemymalloc\", or a similar\noption in order to instruct Perl to use the system's own \"malloc\".\n\nThanks to Tim Bunce .\n\nCGI scripts do not work under Microsoft Internet Information Server (IIS)\nCGI scripts may not work under IIS unless scripts use the \".pl\" extension, opposed to\n\".cgi\".\n\nJava SAX parser unable to parse message composed by SOAP::Lite\nIn some cases SOAP messages created by \"SOAP::Lite\" may not be parsed properly by a\nSAX2/Java XML parser. This is due to a known bug in \"org.xml.sax.helpers.ParserAdapter\".\nThis bug manifests itself when an attribute in an XML element occurs prior to the XML\nnamespace declaration on which it depends. However, according to the XML specification, the\norder of these attributes is not significant.\n\nhttp://www.megginson.com/SAX/index.html\n\nThanks to Steve Alpert (SteveAlpert@idx.com) for pointing on it.\n",
"subsections": []
},
"PERFORMANCE": {
"content": "Processing of XML encoded fragments\n\"SOAP::Lite\" is based on XML::Parser which is basically wrapper around James Clark's expat\nparser. Expat's behavior for parsing XML encoded string can affect processing messages that\nhave lot of encoded entities, like XML fragments, encoded as strings. Providing low-level\ndetails, parser will call char() callback for every portion of processed stream, but\nindividually for every processed entity or newline. It can lead to lot of calls and\nadditional memory manager expenses even for small messages. By contrast, XML messages which\nare encoded as base64Binary, don't have this problem and difference in processing time can\nbe significant. For XML encoded string that has about 20 lines and 30 tags, number of call\ncould be about 100 instead of one for the same string encoded as base64Binary.\n\nSince it is parser's feature there is NO fix for this behavior (let me know if you find\none), especially because you need to parse message you already got (and you cannot control\ncontent of this message), however, if your are in charge for both ends of processing you can\nswitch encoding to base64 on sender's side. It will definitely work with SOAP::Lite and it\nmay work with other toolkits/implementations also, but obviously I cannot guarantee that.\n\nIf you want to encode specific string as base64, just do \"SOAP::Data->type(base64 =>\n$string)\" either on client or on server side. If you want change behavior for specific\ninstance of SOAP::Lite, you may subclass \"SOAP::Serializer\", override \"asstring()\" method\nthat is responsible for string encoding (take a look into \"asbase64Binary()\") and specify\nnew serializer class for your SOAP::Lite object with:\n\nmy $soap = new SOAP::Lite\nserializer => My::Serializer->new,\n..... other parameters\n\nor on server side:\n\nmy $server = new SOAP::Transport::HTTP::Daemon # or any other server\nserializer => My::Serializer->new,\n..... other parameters\n\nIf you want to change this behavior for all instances of SOAP::Lite, just substitute\n\"asstring()\" method with \"asbase64Binary()\" somewhere in your code after \"use SOAP::Lite\"\nand before actual processing/sending:\n\n*SOAP::Serializer::asstring = \\&SOAP::XMLSchema2001::Serializer::asbase64Binary;\n\nBe warned that last two methods will affect all strings and convert them into base64\nencoded. It doesn't make any difference for SOAP::Lite, but it may make a difference for\nother toolkits.\n",
"subsections": []
},
"BUGS AND LIMITATIONS": {
"content": "* No support for multidimensional, partially transmitted and sparse arrays (however arrays of\narrays are supported, as well as any other data structures, and you can add your own\nimplementation with SOAP::Data).\n\n* Limited support for WSDL schema.\n\n* XML::Parser::Lite relies on Unicode support in Perl and doesn't do entity decoding.\n\n* Limited support for mustUnderstand and Actor attributes.\n",
"subsections": []
},
"PLATFORM SPECIFICS": {
"content": "MacOS\nInformation about XML::Parser for MacPerl could be found here:\n\nhttp://bumppo.net/lists/macperl-modules/1999/07/msg00047.html\n\nCompiled XML::Parser for MacOS could be found here:\n\nhttp://www.perl.com/CPAN-local/authors/id/A/AS/ASANDSTRM/XML-Parser-2.27-bin-1-MacOS.tgz\n",
"subsections": []
},
"RELATED MODULES": {
"content": "",
"subsections": [
{
"name": "Transport Modules",
"content": "SOAP::Lite allows one to add support for additional transport protocols, or server handlers, via\nseparate modules implementing the SOAP::Transport::* interface. The following modules are\navailable from CPAN:\n\n* SOAP-Transport-HTTP-Nginx\n\nSOAP::Transport::HTTP::Nginx provides a transport module for nginx ()\n"
}
]
},
"AVAILABILITY": {
"content": "You can download the latest version SOAP::Lite for Unix or SOAP::Lite for Win32 from the\nfollowing sources:\n\n* CPAN: http://search.cpan.org/search?dist=SOAP-Lite\n\nYou are welcome to send e-mail to the maintainers of SOAP::Lite with your comments, suggestions,\nbug reports and complaints.\n",
"subsections": []
},
"ACKNOWLEDGEMENTS": {
"content": "Special thanks to Randy J. Ray, author of *Programming Web Services with Perl*, who has\ncontributed greatly to the documentation effort of SOAP::Lite.\n\nSpecial thanks to O'Reilly publishing which has graciously allowed SOAP::Lite to republish and\nredistribute the SOAP::Lite reference manual found in Appendix B of *Programming Web Services\nwith Perl*.\n\nAnd special gratitude to all the developers who have contributed patches, ideas, time, energy,\nand help in a million different forms to the development of this software.\n",
"subsections": []
},
"HACKING": {
"content": "Latest development takes place on GitHub.com. Come on by and fork it.\n\ngit@github.com:redhotpenguin/perl-soaplite.git\n\nAlso see the HACKING file.\n\nActively recruiting maintainers for this module. Come and get it on!\n",
"subsections": []
},
"REPORTING BUGS": {
"content": "Please use rt.cpan.org or github to report bugs. Pull requests are preferred.\n",
"subsections": []
},
"COPYRIGHT": {
"content": "Copyright (C) 2000-2007 Paul Kulchenko. All rights reserved.\n\nCopyright (C) 2007-2008 Martin Kutter\n\nCopyright (C) 2013 Fred Moyer\n",
"subsections": []
},
"LICENSE": {
"content": "This library is free software; you can redistribute it and/or modify it under the same terms as\nPerl itself.\n\nThis text and all associated documentation for this library is made available under the Creative\nCommons Attribution-NoDerivs 2.0 license. http://creativecommons.org/licenses/by-nd/2.0/\n",
"subsections": []
},
"AUTHORS": {
"content": "Paul Kulchenko (paulclinger@yahoo.com)\n\nRandy J. Ray (rjray@blackperl.com)\n\nByrne Reese (byrne@majordojo.com)\n\nMartin Kutter (martin.kutter@fen-net.de)\n\nFred Moyer (fred@redhotpenguin.com)\n",
"subsections": []
}
},
"summary": "SOAP::Lite - Perl's Web Services Toolkit",
"flags": [],
"examples": [],
"see_also": []
}