{
    "mode": "perldoc",
    "parameter": "SOAP::Transport",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/SOAP%3A%3ATransport/json",
    "generated": "2026-07-05T13:44:13Z",
    "sections": {
        "NAME": {
            "content": "SOAP::Transport - an abstract class extended by more specialized transport modules\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Objects of the SOAP::Transport class manage two roles: they manage both the parameters related\nto transport as set through the containing SOAP::Lite object, and they abstract the selection\nand loading of an appropriate transport module. This is done with an AUTOLOAD function within\nthe class that intercepts all methods beyond the two defined next and reroutes them to the\nunderlying transport implementation code.\n",
            "subsections": []
        },
        "METHODS": {
            "content": "new\n$trans = SOAP::Transport->new;\n\nThis is the constructor, which isn't usually called by an application directly. An\napplication can use this to create a fresh new SOAP::Transport object, which may be\ninstalled using the SOAP::Lite->transport method defined earlier. No arguments are\nrecognized.\n",
            "subsections": [
                {
                    "name": "proxy",
                    "content": "$trans->proxy('http://www.blackperl.com/SOAP');\n\nGets or sets the proxy (endpoint). This method must be called before any other methods are\ncalled. The proper transport code is loaded based on the scheme specified by the URL itself\n(http, jabber, etc.). Until this method is called the first time with a URL string, the\nunderlying code has yet to be loaded, and the methods aren't available. When getting the\ncurrent proxy (calling with no parameters), the returned value is a reference to the client\nobject created from the protocol class that matched the endpoint, not the endpoint itself.\n\nSOAP Transport Sub-Classes\nBecause the bulk of the work is done within the \"SOAP::Lite\" module itself, many of the\ntransport-level modules are very simple in their implementations. Transport modules are expected\nto define both client and server classes within their files. If a module defines only one of the\ntypes, it is assumed that the transport protocol itself supports only that side of the\nconversation. An example is SOAP::Transport::FTP, which provides only a\n\"SOAP::Transport::FTP::Client\" class.\n\n\"SOAP::Transport::FTP\" - Client class only\n\n\"SOAP::Transport::HTTP\" - Client, and server classes for CGI, FCGI, Daemon and modperl\n\n\"SOAP::Transport::IO\" - Server class only\n\n\"SOAP::Transport::JABBER\" - Server and Client classes\n\n\"SOAP::Transport::LOCAL\" - Client class only\n\n\"SOAP::Transport::MAILTO\" - Client class only\n\n\"SOAP::Transport::MQ\" - Server and Client classes\n\n\"SOAP::Transport::POP3\" - Server class only\n\n\"SOAP::Transport::TCP\" - Server and Client classes\n\nMETHODS\nEach SOAP::Transport sub-class is expected to define (or inherit, if it is subclassing another\ntransport class) at least two methods. Any newly developed transport classes are also expected\nto adhere to this interface. Clients are expected to implement the \"new\" and \"sendreceive\"\nmethods, and servers are expected to implement the \"new\" and \"handle\" methods. Here they are:\n"
                },
                {
                    "name": "new",
                    "content": "$object = $class->new(%params);\n\nCreates a new object instance and returns it. Like the constructors for both \"SOAP::Lite\"\nand SOAP::Server classes, all arguments passed in are treated as key/value pairs, where the\nkey is expected to be one of the methods the class supports, and the value is the argument\n(or list reference of arguments) to the method.\n"
                },
                {
                    "name": "send_receive",
                    "content": "$client->sendrecieve(%hashtable);\n\n(Required for client classes only) When the SOAP::Lite objects attempt to send out requests,\nthe means for doing so is to attempt to call this method on the object held within the\nSOAP::Transport object contained within the client itself. All clients are expected to\nprovide this, and the call to this method always passes four values for the hash keys:\n\naction\nThe URI specifying the action being performed, usually the result from the onaction\nhook on the client object.\n\nencoding\nThe URI of the encoding scheme that governs the message being sent.\n\nendpoint\nThe URI specifying the endpoint to which the message is being sent.\n\nenvelope\nThe XML content of the message to be sent. It is generally the return value of the\nenvelope method from the SOAP::Serializer object instance that the client object\nmaintains.\n\nparts\nAttachments to add to the request. Currently this only supports an array of MIME::Entity\nobjects, but in theory could support attachments of any format.\n\nhandle\n$server->handle;\n\n(Required for server classes only.) This method is the central point for the various server\nclasses to provide an interface to handling requests. The exact set and nature of parameters\ngenerally varies based on the classes themselves.\n\nSOAP::Transport::HTTP\nThe most commonly used transport module is the HTTP implementation. This is loaded whenever an\nendpoint is given that starts with the characters, http:// or https://. This is also the most\ninvolved of the transport modules, defining not only a client class but several different server\nclasses as well.\n\nHTTP PROXY SETTINGS\nBecause \"SOAP::Client\" inherits from \"LWP::UserAgent\", you can use any of \"LWP::UserAgent\"'s\nproxy settings. For example:\n\nSOAP::Lite->proxy(\"http://endpoint.server/\",\nproxy => [\"http\" => \"http://my.proxy.server\"]);\n\nor\n\n$soap->transport->proxy(\"http\" => \"http://my.proxy.server\");\n\nThe above code samples should specify a proxy server for you. And should you use\n\"HTTPproxyuser\" and \"HTTPproxypass\" for proxy authorization, \"SOAP::Lite\" will handle it\nproperly.\n\nHTTP BASIC AUTHENTICATION\nHTTP Basic authentication is accomplished by overriding the getbasiccredentials subroutine in\n\"LWP::UserAgent\" (which \"SOAP::Transport::HTTP::Client\" is a subclass):\n\nBEGIN {\nsub SOAP::Transport::HTTP::Client::getbasiccredentials {\nreturn 'username' => 'password';\n}\n}\n\nCOOKIE-BASED AUTHENTICATION\nuse HTTP::Cookies;\nmy $cookies = HTTP::Cookies->new(ignorediscard => 1);\n# you may also add 'file' if you want to keep them between sessions\nmy $soap = SOAP::Lite->proxy('http://localhost/');\n$soap->transport->cookiejar($cookies);\n\nOr, alternatively, you can do the above on a single line:\n\n$soap->proxy('http://localhost/',\ncookiejar => HTTP::Cookies->new(ignorediscard => 1));\n\nCookies will be taken from the response and provided to the request. You may access and\nmanipulate cookies received, as well as add cookies of your own by using the \"HTTP::Cookies\"\ninterfaces.\n\nSSL CERTIFICATE AUTHENTICATION\nThe default SSL implementation for the HTTP client library LWP::UserAgent used by SOAP::Lite is\nIO::Socket::SSL.\n\nTo enable certificate based authentication, you'll have to pass your certificate and key as\nadditional options to the proxy() method like this:\n\n$soap->proxy( $url, sslopts => {\nSSLcertfile => 'client-cert.pem',\nSSLkeyfile  => 'client-key.pem'\n});\n\nOr you can set them later like this:\n\n$soap->transport->sslopts(\nSSLcertfile => 'client-cert.pem',\nSSLkeyfile  => 'client-key.pem'\n);\n\nIf you're using Crypt::SSLeay, the following applies:\n\nTo get certificate authentication working you need to set three environment variables:\n\"HTTPSCERTFILE\", \"HTTPSKEYFILE\", and optionally \"HTTPSCERTPASS\". This can be done either\nthrough the command line, or directly within your Perl script using the $ENV variable:\n\n$ENV{HTTPSCERTFILE} = 'client-cert.pem';\n$ENV{HTTPSKEYFILE}  = 'client-key.pem';\n\nThese settings are referenced by \"Crypt::SSLeay\". Other options (e.g. CA peer verification) can\nbe specified in a similar way. See Crypt::SSLeay documentation for more information.\n\nPlease note that you probably should not be using Crypt::SSLeay because it does not perform\nhostname verification; LWP::UserAgent uses IO::Socket::SSL by default. See also\n<https://metacpan.org/pod/Crypt::SSLeay#DO-YOU-NEED-Crypt::SSLeay>.\n\nThose who would like to use encrypted keys may find the following thread in the SOAP::Lite\nnewsgroup helpful:\n\nhttp://groups.yahoo.com/group/soaplite/message/729\n\nCOMPRESSION\nSOAP::Lite provides you with the option for enabling compression over the wire using HTTP *only*\nin both the server and client contexts, provided that you have Compress::Zlib installed.\nCompression and decompression is done transparently to your application.\n\nA server will respond with an encoded/compressed message only if the client has asserted that it\ncan accept it (indicated by client sending an \"Accept-Encoding\" HTTP header with a 'deflate' or\n'*' value).\n\n\"SOAP::Lite\" clients all have fallback logic implemented so that if a server doesn't understand\nthe specified encoding (i.e. \"Content-Encoding: deflate\") and returns the proper HTTP status\ncode (415 NOT ACCEPTABLE), the client will repeat the request without using\nencoding/compression. The client will then store this server in a per-session cache, so that all\nsubsequent requests to that server will be transmitted without encoding.\n\nCompression is enabled on the client side by specifying the \"compressthreshold\" option, and if\nthe size of the current request exceeds that threshold.\n\nClient Code Sample\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\nServers will respond with a compressed message if the \"compressthreshold\" option has been\nspecified, if the size of the current response exceeds that threshold, and if the calling client\ntransmitted the proper \"Accept-Encoding\" HTTP Header.\n\nServer Code Sample\n\nmy $server = SOAP::Transport::HTTP::CGI\n->dispatchto('My::Parameters')\n->options({compressthreshold => 10000})\n->handle;\n\nSee also: Compress::Zlib\n\nSOAP::Transport::HTTP::Client\nInherits from: SOAP::Client, LWP::UserAgent (from the LWP package).\n\nWith this class, clients are able to use HTTP for sending messages. This class provides just the\nbasic new and sendreceive methods. Objects of this class understand the compressthreshold\noption and use it if the server being communicated to also understands it.\n\nCHANGING THE DEFAULT USERAGENT CLASS\nBy default, \"SOAP::Transport::HTTP::Client\" extends \"LWP::UserAgent\". But under some\ncircumstances, a user may wish to change the default UserAgent class with their in order to\nbetter handle persist connections, or to \"LWP::UserAgent::ProxyAny\", for example, which has\nbetter Win32/Internet Explorer interoperability.\n\nOne can use the code below as an example of how to change the default UserAgent class.\n\nuse SOAP::Lite;\nuse SOAP::Transport::HTTP;\n$SOAP::Transport::HTTP::Client::USERAGENTCLASS = \"My::UserAgent\";\nmy $client = SOAP::Lite->proxy(..)->uri(..);\nmy $som = $client->myMethod();\n\nThere is one caveat, however. The UserAgent class you use, *MUST* also be a subclass of\n\"LWP::UserAgent\". If it is not, then \"SOAP::Lite\" will issue the following error: \"Could not\nload UserAgent class <USERAGENT CLASS>.\"\n\nHTTP-KEEP-ALIVE, TIMEOUTS, AND MORE\nBecause \"SOAP::Transport::HTTP::Client\" extends \"LWP::UserAgent\", all methods available\n\"LWP::UserAgent\" are also available to your SOAP Clients. For example, using \"LWP::UserAgent\"\nHTTP keep alive's are accomplished using the following code:\n\nmy $ua = LWP::UserAgent->new(\nkeepalive => 1,\ntimeout    => 30\n);\n\nTherefore, the same initialization parameters you would pass to \"LWP::UserAgent\" can also be\npassed to your SOAP::Lite client's \"proxy\" subroutine like so:\n\nmy $soap = SOAP::Lite\n->uri($uri)\n->proxy($proxyUrl,\ntimeout => 30,\nkeepalive => 1,\n);\n\nThis is true for all initialization parameters and methods of \"LWP::UserAgent\".\n\nMETHODS\nhttprequest\nThis method gives you access to a prototype of the HTTP Request object that will be\ntransmitted to a SOAP::Server. The actual request used is a copy of that object.\n\nDo not use this method for anything else than setting prototypic behaviour for the client\nobject.\n\nhttpresponse\nThis method gives you access to the HTTP Response object that will be, or was transmitted to\na SOAP Server. It returns a HTTP::Response object.\n\nSOAP::Transport::HTTP::Server\nInherits from: SOAP::Server.\n\nThis is the most basic of the HTTP server implementations. It provides the basic methods, new\nand handle. The handle method's behavior is defined here, along with other methods specific to\nthis class. The role of this class is primarily to act as a superclass for the other HTTP-based\nserver classes.\n\nhandle\n$server->handle;\n\nExpects the request method to have been used to associate a HTTP::Request object with the\nserver object prior to being called. This method retrieves that object reference to get at\nthe request being handled.\n"
                },
                {
                    "name": "request",
                    "content": "$server->request($reqobject)\n\nGets or sets the HTTP::Request object reference that the server will process within the\nhandle method.\n"
                },
                {
                    "name": "response",
                    "content": "$server->response(HTTP::Response->new(...));\n\nGets or sets the HTTP::Response object reference that the server has prepared for sending\nback to the client.\n"
                },
                {
                    "name": "make_response",
                    "content": "$server->makeresponse(200, $bodyxml);\n\nConstructs and returns an object of the HTTP::Response class, using the response code and\ncontent provided.\n"
                },
                {
                    "name": "make_fault",
                    "content": "$server->response($server->makefault(@data));\n\nCreates a HTTP::Response object reference using a predefined HTTP response code to signify\nthat a fault has occurred. The arguments are the same as those for the makefault method of\nthe SOAP::Server class.\n\nproducttokens\nThis method takes no arguments and simply returns a string identifying the elements of the\nserver class itself. It is similar to the producttokens methods in the HTTP::Daemon and\nApache classes.\n\nSOAP::Transport::HTTP::CGI\nInherits from: SOAP::Transport::HTTP::Server.\n\nThis class is a direct subclass of SOAP::Transport::HTTP::Server and defines no additional\nmethods. It includes logic in its implementation of the handle method that deals with the\nrequest headers and parameters specific to a CGI environment.\n\nEXAMPLE CGI\nThe following code sample is a CGI based Web Service that converts celsius to fahrenheit:\n\n#!/usr/bin/perl\nuse SOAP::Transport::HTTP;\nSOAP::Transport::HTTP::CGI\n->dispatchto('C2FService')\n->handle;\nBEGIN {\npackage C2FService;\nuse vars qw(@ISA);\n@ISA = qw(Exporter SOAP::Server::Parameters);\nuse SOAP::Lite;\nsub c2f {\nmy $self = shift;\nmy $envelope = pop;\nmy $temp = $envelope->dataof(\"//c2f/temperature\");\nreturn SOAP::Data->name('convertedTemp' => (((9/5)*($temp->value)) + 32));\n}\n}\n\nEXAMPLE APACHE::REGISTRY USAGE\nUsing a strictly CGI based Web Service has certain performance drawbacks. Running the same CGI\nunder the Apache::Registery system has certain performance gains.\n\nhttpd.conf\n\nAlias /modperl/ \"/Your/Path/To/Deployed/Modules\"\n<Location /modperl>\nSetHandler perl-script\nPerlHandler Apache::Registry\nPerlSendHeader On\nOptions +ExecCGI\n</Location>\n\nsoap.cgi\n\nuse SOAP::Transport::HTTP;\n\nSOAP::Transport::HTTP::CGI\n->dispatchto('/Your/Path/To/Deployed/Modules', 'Module::Name', 'Module::method')\n->handle;\n\n*WARNING: Dynamic deployments with \"Apache::Registry\" will fail because the module will be only\nloaded dynamically the first time. Subsequent calls will produce \"denied access\" errors because\nonce the module is already in memory \"SOAP::Lite\" will bypass dynamic deployment. To work around\nthis, simply specify both the full PATH and MODULE name in \"dispatchto()\" and the module will\nbe loaded dynamically, but will then work as if under static deployment. See\nexamples/server/soap.modcgi as an example.*\n\nSOAP::Transport::HTTP::Daemon\nInherits from: SOAP::Transport::HTTP::Server.\n\nThe SOAP::Transport::HTTP::Daemon class encapsulates a reference to an object of the\nHTTP::Daemon class (from the LWP package). The class catches methods that aren't provided\nlocally or by the superclass and attempts to call them on the HTTP::Daemon object. Thus, all\nmethods defined in the documentation for that class are available to this class as well. Any\nthat conflict with methods in SOAP::Transport::HTTP::Server (such as producttokens) go to the\nsuperclass. Additionally, the behavior of the handle method is specific to this class:\n\nhandle\nWhen invoked, this method enters into the typical accept loop in which it waits for a\nrequest on the socket that the daemon object maintains and deals with the content of the\nrequest. When all requests from the connection returned by the accept method of the\nHTTP::Daemon object have been processed, this method returns.\n\nREUSING SOCKETS ON RESTART\nOften when implementing an HTTP daemon, sockets will get tied up when you try to restart the\ndaemon server. This prevents the server from restarting. Often users will see an error like\n\"Cannot start server: port already in use.\" To circumvent this, instruct SOAP::Lite to reuse\nopen sockets using \"Reuse => 1\":\n\nmy $daemon = SOAP::Transport::HTTP::Daemon\n-> new (LocalPort => 80000, Reuse => 1)\n\nEXAMPLE DAEMON SERVER\nuse SOAP::Transport::HTTP;\n# change LocalPort to 81 if you want to test it with soapmark.pl\nmy $daemon = SOAP::Transport::HTTP::Daemon\n-> new (LocalAddr => 'localhost', LocalPort => 80)\n# specify list of objects-by-reference here\n-> objectsbyreference(qw(My::PersistentIterator My::SessionIterator My::Chat))\n# specify path to My/Examples.pm here\n-> dispatchto('/Your/Path/To/Deployed/Modules', 'Module::Name', 'Module::method')\n;\nprint \"Contact to SOAP server at \", $daemon->url, \"\\n\";\n$daemon->handle;\n\nSOAP::Transport::HTTP::Apache\nInherits from: SOAP::Transport::HTTP::Server.\n\nThis class provides an integration of the SOAP::Server base class with the modperl extension\nfor Apache. To work as a location handler, the package provides a method called handler, for\nwhich handle is made an alias. The new method isn't functionally different from the superclass.\nHere are the other methods provided by this class:\n"
                },
                {
                    "name": "handler",
                    "content": "$server->handler($r)\n\nDefines the basis for a location handler in the modperl fashion. The method expects an\nApache request object as the parameter, from which it pulls the body of the request and\ncalls the superclass handle method.\n\nNote that in this class, the local method named handle is aliased to this method.\n"
                },
                {
                    "name": "configure",
                    "content": "$server->configure(Apache->request);\n\nPer-location configuration information can be provided to the server object using the Apache\nDirConfig directive and calling this method on the object itself. When invoked, the method\nreads the directory configuration information from Apache and looks for lines of the form:\n\nmethod => param\n\nEach line that matches the pattern is regarded as a potential method to call on the server\nobject, with the remaining token taken as the parameter to the method. Methods that take\nhash references as arguments may be specified as:\n\nmethod => key => param, key => param\n\nThe key/value pairs will be made into a hash reference on demand. If the server object\ndoesn't recognize the named method as valid, it ignores the line.\n\nEXAMPLE APACHE MODPERL SERVER\nSee examples/server/Apache.pm and Apache::SOAP for more information.\n\nhttpd.conf\n\n<Location /soap>\nSetHandler perl-script\nPerlHandler SOAP::Apache\nPerlSetVar options \"compressthreshold => 10000\"\n</Location>\n\nSOAP::Apache.pm\n\npackage SOAP::Apache;\nuse SOAP::Transport::HTTP;\nmy $server = SOAP::Transport::HTTP::Apache\n->dispatchto('/Your/Path/To/Deployed/Modules', 'Module::Name', 'Module::method');\nsub handler { $server->handler(@) }\n1;\n\nSee also Apache::SOAP.\n\nSOAP::Transport::HTTP::FCGI\nInherits from: SOAP::Transport::HTTP::CGI.\n\nThis is an extension of the SOAP::Transport::HTTP::CGI that implements the differences needed\nfor the FastCGI protocol. None of the methods are functionally different.\n\nSOAP::Transport::IO\nThe SOAP::Transport::IO-based class allows for a sort of I/O proxying by allowing the\napplication to configure what files or filehandles are used. This module supplies only a server\nclass.\n\nSOAP::Transport::IO::Server\nInherits from: SOAP::Server.\n\nThe server class defined here inherits all methods from SOAP::Server, and adds two additional\nmethods specific to the nature of the class:\n\nin\n$server->in(IO::File->new($file));\n\nGets or sets the current filehandle being used as the input source.\n\nout\n$server->out(\\*STDERR);\n\nGets or sets the filehandle being used as the output destination.\n\nSOAP::Transport::LOCAL\nThe SOAP::Transport::LOCAL module is designed to provide a no-transport client class for tracing\nand debugging communications traffic. It links SOAP::Client and SOAP::Server so that the same\nobject that \"sends\" the request also \"receives\" it.\n\nSOAP::Transport::LOCAL::Client\nInherits from: SOAP::Client, SOAP::Server. The implementations of the new and sendreceive\nmethods aren't noticeably different in their interface. Their behavior warrants description,\nhowever:\n\nnew When the constructor creates a new object of this class, it sets up a few things beyond the\nusual SOAP::Client layout. The issuccess method is set to a default value of 1. The\ndispatchto method inherited from SOAP::Server is called with the current value of the\nglobal array @INC, allowing the client to call any methods that can be found in the current\nvalid search path. And as with most of the constructors in this module, the optional\nkey/value pairs are treated as method names and parameters.\n\nsendreceive\nThe implementation of this method simply passes the envelope portion of the input data to\nthe handle method of SOAP::Server. While no network traffic results (directly) from this, it\nallows for debug signals to be sent through the SOAP::Trace facility.\n\nSOAP::Transport::MAILTO\nThis transport class manages SMTP-based sending of messages from a client perspective. It\ndoesn't provide a server class. The class gets selected when a client object passes a URI to\nproxy or endpoint that starts with the characters, mailto:.\n\nSOAP::Transport::MAILTO::Client\nInherits from: SOAP::Client.\n\nThe client class for this protocol doesn't define any new methods. The constructor functions in\nthe same style as the others class constructors. The functionality of the sendreceive method is\nslightly different from other classes, however.\n\nWhen invoked, the sendreceive method uses the MIME::Lite package to encapsulate and transmit\nthe message. Because mail messages are one-way communications (the reply being a separate\nprocess), there is no response message to be returned by the method. Instead, all the\nstatus-related attributes (code, message, status, issuccess) are set, and no value is\nexplicitly returned.\n\nSOAP::Transport::POP3\nPOP3 support is limited to a server implementation. Just as the MAILTO class detailed earlier\noperates by sending requests without expecting to process a response, the server described here\naccepts request messages and dispatches them without regard for sending a response other than\nthat which POP3 defines for successful delivery of a message.\n\nSOAP::Transport::POP3::Server\nInherits from: SOAP::Server.\n\nThe new method of this class creates an object of the Net::POP3 class to use internally for\npolling a specified POP3 server for incoming messages. When an object of this class is created,\nit expects an endpoint to be specified with a URI that begins with the characters pop:// and\nincludes user ID and password information as well as the hostname itself.\n\nThe handle method takes the messages present in the remote mailbox and passes them (one at a\ntime) to the superclass handle method. Each message is deleted after being routed. All messages\nin the POP3 mailbox are presumed to be SOAP messages.\n\nMethods for the Net::POP3 object are detected and properly routed, allowing operations such as\n$server->ping( ).\n\nThis means that the endpoint string doesn't need to provide the user ID and password because the\nlogin method from the POP3 API may be used directly.\n"
                }
            ]
        },
        "ACKNOWLEDGEMENTS": {
            "content": "Special thanks to O'Reilly publishing which has graciously allowed SOAP::Lite to republish and\nredistribute large excerpts from *Programming Web Services with Perl*, mainly the SOAP::Lite\nreference found in Appendix B.\n",
            "subsections": []
        },
        "COPYRIGHT": {
            "content": "Copyright (C) 2000-2004 Paul Kulchenko. All rights reserved.\n\nThis library is free software; you can redistribute it and/or modify it under the same terms as\nPerl itself.\n",
            "subsections": []
        },
        "AUTHORS": {
            "content": "Paul Kulchenko (paulclinger@yahoo.com)\n\nRandy J. Ray (rjray@blackperl.com)\n\nByrne Reese (byrne@majordojo.com)\n",
            "subsections": []
        }
    },
    "summary": "SOAP::Transport - an abstract class extended by more specialized transport modules",
    "flags": [],
    "examples": [],
    "see_also": []
}