responses are much like requests, with a few extra twists. if the response is successful - the procedure was found, executed correctly, and returned results - then the xml-rpc response will look much like a request, except that the methodcall element is replaced by a methodresponse element and there is no methodname element:

<?xml version="1.0"?>
<methodresponse>
   <params>
      <param>
         <value><double>18.24668429131</double></value>
      </param>
   </params>
</methodresponse>

• an xml-rpc response can only contain one parameter.

• that parameter may be an array or a struct, so it is possible to return multiple values.

• it is always required to return a value in response. a "success value" - perhaps a boolean set to true (1).

like requests, responses are packaged in http and have http headers. all xml-rpc responses use the 200 ok response code, even if a fault is contained in the message. headers use a common structure similar to that of requests, and a typical set of headers might look like:

http/1.1 200 ok
date: sat, 06 oct 2001 23:20:04 gmt
server: apache.1.3.12 (unix)
connection: close
content-type: text/xml
content-length: 124

• xml-rpc only requires http 1.0 support, but http 1.1 is compatible.

• the content-type must be set to text/xml.

• the content-length header specifies the length of the response in bytes.

a complete response, with both headers and a response payload, would look like:

http/1.1 200 ok
date: sat, 06 oct 2001 23:20:04 gmt
server: apache.1.3.12 (unix)
connection: close
content-type: text/xml
content-length: 124

<?xml version="1.0"?>
<methodresponse>
   <params>
      <param>
         <value><double>18.24668429131</double></value>
      </param>
   </params>
</methodresponse>

after the response is delivered from the xml-rpc server to the xml-rpc client, the connection is closed. follow-up requests need to be sent as separate xml-rpc connections.