Move to asciidoc as principal documentation format
[plcapi.git] / doc / manual / phpxmlrpc_manual.adoc
1 = XML-RPC for PHP
2 :revision: 4.0.0
3 :keywords: xml, rpc, xmlrpc, webservices, http
4 :toc: left
5 :imagesdir: images
6
7 [preface]
8 == Introduction
9
10 XML-RPC is a format devised by link:$$http://www.userland.com/$$[Userland Software] for achieving
11     remote procedure call via XML using HTTP as the transport. XML-RPC has its
12     own web site, link:$$http://www.xmlrpc.com/$$[www.xmlrpc.com]
13
14 This collection of PHP classes provides a framework for writing
15     XML-RPC clients and servers in PHP.
16
17 Main goals of the project are ease of use, flexibility and
18     completeness.
19
20 The original author is Edd Dumbill of link:$$http://usefulinc.com/$$[Useful Information Company]. As of the
21     1.0 stable release, the project was opened to wider involvement and moved
22     to link:$$http://phpxmlrpc.sourceforge.net/$$[SourceForge]; later, to link:$$https://github.com/gggeek/phpxmlrpc$$[Github]
23
24 A list of XML-RPC implementations for other languages such as Perl
25     and Python can be found on the link:$$http://www.xmlrpc.com/$$[www.xmlrpc.com] site.
26
27 === Acknowledgements
28
29 Daniel E. Baumann
30
31 James Bercegay
32
33 Leon Blackwell
34
35 Stephane Bortzmeyer
36
37 Daniel Convissor
38
39 Geoffrey T. Dairiki
40
41 Stefan Esser
42
43 James Flemer
44
45 Ernst de Haan
46
47 Tom Knight
48
49 Axel Kollmorgen
50
51 Peter Kocks
52
53 Daniel Krippner
54
55 {empty}S. Kuip
56
57 {empty}A. Lambert
58
59 Frederic Lecointre
60
61 Dan Libby
62
63 Arnaud Limbourg
64
65 Ernest MacDougal Campbell III
66
67 Lukasz Mach
68
69 Kjartan Mannes
70
71 Ben Margolin
72
73 Nicolay Mausz
74
75 Justin Miller
76
77 Jan Pfeifer
78
79 Giancarlo Pinerolo
80
81 Peter Russel
82
83 Jean-Jacques Sarton
84
85 Viliam Simko
86
87 Idan Sofer
88
89 Douglas Squirrel
90
91 Heiko Stübner
92
93 Anatoly Techtonik
94
95 Tommaso Trani
96
97 Eric van der Vlist
98
99 Christian Wenz
100
101 Jim Winstead
102
103 Przemyslaw Wroblewski
104
105 Bruno Zanetti Melotti
106
107
108 [[requirements]]
109 == System Requirements
110
111 The library has been designed with goals of scalability and backward
112     compatibility. As such, it supports a wide range of PHP installs. Note
113     that not all features of the lib are available in every
114     configuration.
115
116 The __minimum supported__ PHP version is
117     5.3.
118
119 If you wish to use HTTPS or HTTP 1.1 to communicate with remote
120     servers, you need the "curl" extension compiled into your PHP
121     installation.
122
123 The "xmlrpc" native extension is not required to be compiled into
124     your PHP installation, but if it is, there will be no interference with
125     the operation of this library.
126
127
128 [[manifest]]
129 == Files in the distribution
130
131 lib/xmlrpc.inc::
132    the XML-RPC classes. include() this in
133           your PHP files to use the classes.
134
135 lib/xmlrpcs.inc::
136    the XML-RPC server class. include() this
137           in addition to xmlrpc.inc to get server functionality
138
139 lib/xmlrpc_wrappers.php::
140    helper functions to "automagically" convert plain php
141           functions to xmlrpc services and vice versa
142
143 demo/server/proxy.php::
144    a sample server implementing xmlrpc proxy
145           functionality.
146
147 demo/server/server.php::
148    a sample server hosting various demo functions, as well as a
149           full suite of functions used for interoperability testing. It is
150           used by testsuite.php (see below) for unit testing the library, and
151           is not to be copied literally into your production servers
152
153 demo/client/client.php, demo/client/agesort.php,
154         demo/client/which.php::
155    client code to exercise some of the functions in server.php,
156           including the interopEchoTests.whichToolkit
157           method.
158
159 demo/client/wrap.php::
160    client code to illustrate 'wrapping' of remote methods into
161           php functions.
162
163 demo/client/introspect.php::
164    client code to illustrate usage of introspection capabilities
165           offered by server.php.
166
167 demo/client/mail.php::
168    client code to illustrate usage of an xmlrpc-to-email gateway
169           using Dave Winer's XML-RPC server at userland.com.
170
171 demo/client/zopetest.php::
172    example client code that queries an xmlrpc server built in
173           Zope.
174
175 demo/vardemo.php::
176    examples of how to construct xmlrpcval types
177
178 demo/demo1.xml, demo/demo2.xml, demo/demo3.xml::
179    XML-RPC responses captured in a file for testing purposes (you
180           can use these to test the
181           xmlrpcmsg->parseResponse() method).
182
183 demo/server/discuss.php,
184         demo/client/comment.php::
185    Software used in the PHP chapter of <<jellyfish>> to provide a comment server and allow the
186           attachment of comments to stories from Meerkat's data store.
187
188 test/testsuite.php, test/parse_args.php::
189    A unit test suite for this software package. If you do
190           development on this software, please consider submitting tests for
191           this suite.
192
193 test/benchmark.php::
194    A (very limited) benchmarking suite for this software package.
195           If you do development on this software, please consider submitting
196           benchmarks for this suite.
197
198 test/phpunit.php, test/PHPUnit/*.php::
199    An (incomplete) version PEAR's unit test framework for PHP.
200           The complete package can be found at link:$$http://pear.php.net/package/PHPUnit$$[http://pear.php.net/package/PHPUnit]
201
202 test/verify_compat.php::
203    Script designed to help the user to verify the level of
204           compatibility of the library with the current php install
205
206 extras/test.pl, extras/test.py::
207    Perl and Python programs to exercise server.php to test that
208           some of the methods work.
209
210 extras/workspace.testPhpServer.fttb::
211    Frontier scripts to exercise the demo server. Thanks to Dave
212           Winer for permission to include these. See link:$$http://www.xmlrpc.com/discuss/msgReader$853$$[Dave's announcement of these.]
213
214 extras/rsakey.pem::
215    A test certificate key for the SSL support, which can be used
216           to generate dummy certificates. It has the passphrase "test."
217
218
219 [[bugs]]
220
221 == Known bugs and limitations
222
223 This started out as a bare framework. Many "nice" bits haven't been
224     put in yet. Specifically, very little type validation or coercion has been
225     put in. PHP being a loosely-typed language, this is going to have to be
226     done explicitly (in other words: you can call a lot of library functions
227     passing them arguments of the wrong type and receive an error message only
228     much further down the code, where it will be difficult to
229     understand).
230
231 dateTime.iso8601 is supported opaquely. It can't be done natively as
232     the XML-RPC specification explicitly forbids passing of timezone
233     specifiers in ISO8601 format dates. You can, however, use the <<iso8601encode>> and <<iso8601decode>> functions
234     to do the encoding and decoding for you.
235
236 Very little HTTP response checking is performed (e.g. HTTP redirects
237     are not followed and the Content-Length HTTP header, mandated by the
238     xml-rpc spec, is not validated); cookie support still involves quite a bit
239     of coding on the part of the user.
240
241 If a specific character set encoding other than US-ASCII, ISO-8859-1
242     or UTF-8 is received in the HTTP header or XML prologue of xml-rpc request
243     or response messages then it will be ignored for the moment, and the
244     content will be parsed as if it had been encoded using the charset defined
245     by <<xmlrpc-defencoding>>
246
247 Support for receiving from servers version 1 cookies (i.e.
248     conforming to RFC 2965) is quite incomplete, and might cause unforeseen
249     errors.
250
251
252 [[support]]
253
254 == Support
255
256
257 === Online Support
258
259 XML-RPC for PHP is offered "as-is" without any warranty or
260       commitment to support. However, informal advice and help is available
261       via the XML-RPC for PHP website and mailing list and from
262       XML-RPC.com.
263
264 * The __XML-RPC for PHP__ development is hosted
265           on link:$$https://github.com/gggeek/phpxmlrpc$$[github.com/gggeek/phpxmlrpc].
266           Bugs, feature requests and patches can be posted to the link:$$https://github.com/gggeek/phpxmlrpc/issues$$[project's website].
267
268 * The __PHP XML-RPC interest mailing list__ is
269           run by the author. More details link:$$http://lists.gnomehack.com/mailman/listinfo/phpxmlrpc$$[can be found here].
270
271 * For more general XML-RPC questions, there is a Yahoo! Groups
272           link:$$http://groups.yahoo.com/group/xml-rpc/$$[XML-RPC mailing list].
273
274 * The link:$$http://www.xmlrpc.com/discuss$$[XML-RPC.com] discussion
275           group is a useful place to get help with using XML-RPC. This group
276           is also gatewayed into the Yahoo! Groups mailing list.
277
278 [[jellyfish]]
279
280 === The Jellyfish Book
281
282 image::progxmlrpc.s.gif[The Jellyfish Book]
283 Together with Simon St.Laurent and Joe
284       Johnston, Edd Dumbill wrote a book on XML-RPC for O'Reilly and
285       Associates on XML-RPC. It features a rather fetching jellyfish on the
286       cover.
287
288 Complete details of the book are link:$$http://www.oreilly.com/catalog/progxmlrpc/$$[available from O'Reilly's web site.]
289
290 Edd is responsible for the chapter on PHP, which includes a worked
291       example of creating a forum server, and hooking it up the O'Reilly's
292       link:$$http://meerkat.oreillynet.com/$$[Meerkat] service in
293       order to allow commenting on news stories from around the Web.
294
295 If you've benefited from the effort that has been put into writing
296       this software, then please consider buying the book!
297
298
299 [[apidocs]]
300
301 == Class documentation
302
303 [[xmlrpcval]]
304
305 === xmlrpcval
306
307 This is where a lot of the hard work gets done. This class enables
308       the creation and encapsulation of values for XML-RPC.
309
310 Ensure you've read the XML-RPC spec at link:$$http://www.xmlrpc.com/stories/storyReader$7$$[http://www.xmlrpc.com/stories/storyReader$7]
311       before reading on as it will make things clearer.
312
313 The xmlrpcval class can store arbitrarily
314       complicated values using the following types: ++i4 int boolean string double dateTime.iso8601 base64 array struct++
315       ++null++. You should refer to the link:$$http://www.xmlrpc.com/spec$$[spec] for more information on
316       what each of these types mean.
317
318 ==== Notes on types
319
320 ===== int
321
322 The type i4 is accepted as a synonym
323           for int when creating xmlrpcval objects. The
324           xml parsing code will always convert i4 to
325           int: int is regarded
326           by this implementation as the canonical name for this type.
327
328 ===== base64
329
330 Base 64 encoding is performed transparently to the caller when
331           using this type. Decoding is also transparent. Therefore you ought
332           to consider it as a "binary" data type, for use when you want to
333           pass data that is not 7-bit clean.
334
335 ===== boolean
336
337 The php values ++true++ and
338           ++1++ map to ++true++. All other
339           values (including the empty string) are converted to
340           ++false++.
341
342 ===== string
343
344 Characters &lt;, &gt;, ', ", &amp;, are encoded using their
345           entity reference as &amp;lt; &amp;gt; &amp;apos; &amp;quot; and
346           &amp;amp; All other characters outside of the ASCII range are
347           encoded using their character reference representation (e.g.
348           &amp;#200 for é). The XML-RPC spec recommends only encoding
349           ++&lt; &amp;++ but this implementation goes further,
350           for reasons explained by link:$$http://www.w3.org/TR/REC-xml#syntax$$[the XML 1.0 recommendation]. In particular, using character reference
351           representation has the advantage of producing XML that is valid
352           independently of the charset encoding assumed.
353
354 ===== null
355
356 There is no support for encoding ++null++
357           values in the XML-RPC spec, but at least a couple of extensions (and
358           many toolkits) do support it. Before using ++null++
359           values in your messages, make sure that the responding party accepts
360           them, and uses the same encoding convention (see ...).
361
362 [[xmlrpcval-creation]]
363
364 ==== Creation
365
366 The constructor is the normal way to create an
367         xmlrpcval. The constructor can take these
368         forms:
369
370 xmlrpcvalnew
371             xmlrpcval xmlrpcvalnew
372             xmlrpcval string $stringVal xmlrpcvalnew
373             xmlrpcval mixed $scalarVal string$scalartyp xmlrpcvalnew
374             xmlrpcval array $arrayVal string $arraytyp The first constructor creates an empty value, which must be
375         altered using the methods addScalar,
376         addArray or addStruct before
377         it can be used.
378
379 The second constructor creates a simple string value.
380
381 The third constructor is used to create a scalar value. The
382         second parameter must be a name of an XML-RPC type. Valid types are:
383         "++int++", "++boolean++",
384         "++string++", "++double++",
385         "++dateTime.iso8601++", "++base64++" or
386         "null".
387
388 Examples:
389
390 [source, php]
391 ----
392
393 $myInt = new xmlrpcval(1267, "int");
394 $myString = new xmlrpcval("Hello, World!", "string");
395 $myBool = new xmlrpcval(1, "boolean");
396 $myString2 = new xmlrpcval(1.24, "string"); // note: this will serialize a php float value as xmlrpc string
397
398 ----
399
400 The fourth constructor form can be used to compose complex
401         XML-RPC values. The first argument is either a simple array in the
402         case of an XML-RPC array or an associative
403         array in the case of a struct. The elements of
404         the array __must be xmlrpcval objects themselves__.
405
406 The second parameter must be either "++array++"
407         or "++struct++".
408
409 Examples:
410
411 [source, php]
412 ----
413
414 $myArray = new xmlrpcval(
415   array(
416     new xmlrpcval("Tom"),
417     new xmlrpcval("Dick"),
418     new xmlrpcval("Harry")
419   ),
420   "array");
421
422 // recursive struct
423 $myStruct = new xmlrpcval(
424   array(
425     "name" => new xmlrpcval("Tom", "string"),
426     "age" => new xmlrpcval(34, "int"),
427     "address" => new xmlrpcval(
428       array(
429         "street" => new xmlrpcval("Fifht Ave", "string"),
430         "city" => new xmlrpcval("NY", "string")
431       ),
432       "struct")
433   ),
434   "struct");
435
436 ----
437
438 See the file ++vardemo.php++ in this distribution
439         for more examples.
440
441 [[xmlrpcval-methods]]
442
443 ==== Methods
444
445 ===== addScalar
446
447 int addScalarstring$stringValintaddScalarmixed$scalarValstring$scalartypIf $val is an empty
448           xmlrpcval this method makes it a scalar
449           value, and sets that value.
450
451 If $val is already a scalar value, then
452           no more scalars can be added and ++0++ is
453           returned.
454
455 If $val is an xmlrpcval of type array,
456           the php value $scalarval is added as its last
457           element.
458
459 If all went OK, ++1++ is returned, otherwise
460           ++0++.
461
462 ===== addArray
463
464 intaddArrayarray$arrayValThe argument is a simple (numerically indexed) array. The
465           elements of the array __must be xmlrpcval objects themselves__.
466
467 Turns an empty xmlrpcval into an
468           array with contents as specified by
469           $arrayVal.
470
471 If $val is an xmlrpcval of type array,
472           the elements of $arrayVal are appended to the
473           existing ones.
474
475 See the fourth constructor form for more information.
476
477 If all went OK, ++1++ is returned, otherwise
478           ++0++.
479
480 ===== addStruct
481
482 int addStructarray$assocArrayValThe argument is an associative array. The elements of the
483           array __must be xmlrpcval objects themselves__.
484
485 Turns an empty xmlrpcval into a
486           struct with contents as specified by
487           $assocArrayVal.
488
489 If $val is an xmlrpcval of type struct,
490           the elements of $arrayVal are merged with the
491           existing ones.
492
493 See the fourth constructor form for more information.
494
495 If all went OK, ++1++ is returned, otherwise
496           ++0++.
497
498 ===== kindOf
499
500 string kindOf Returns a string containing "struct", "array" or "scalar"
501           describing the base type of the value. If it returns "undef" it
502           means that the value hasn't been initialised.
503
504 ===== serialize
505
506 string serialize Returns a string containing the XML-RPC representation of this
507           value.
508
509
510 ===== scalarVal
511
512 mixed scalarVal If $val-&gt;kindOf() == "scalar", this
513           method returns the actual PHP-language value of the scalar (base 64
514           decoding is automatically handled here).
515
516 ===== scalarTyp
517
518 string scalarTyp If $val-&gt;kindOf() == "scalar", this
519           method returns a string denoting the type of the scalar. As
520           mentioned before, ++i4++ is always coerced to
521           ++int++.
522
523 ===== arrayMem
524
525 xmlrpcval arrayMem int $n If $val-&gt;kindOf() == "array", returns
526           the $nth element in the array represented by
527           the value $val. The value returned is an
528           xmlrpcval object.
529
530 [source, php]
531 ----
532
533 // iterating over values of an array object
534 for ($i = 0; $i < $val->arraySize(); $i++)
535 {
536   $v = $val->arrayMem($i);
537   echo "Element $i of the array is of type ".$v->kindOf();
538 }
539
540 ----
541
542 ===== arraySize
543
544 int arraySize If $val is an
545           array, returns the number of elements in that
546           array.
547
548 ===== structMem
549
550 xmlrpcval structMem string $memberName If $val-&gt;kindOf() == "struct", returns
551           the element called $memberName from the
552           struct represented by the value $val. The
553           value returned is an xmlrpcval object.
554
555 ===== structEach
556
557 array structEach Returns the next (key, value) pair from the struct, when
558           $val is a struct.
559           $value is an xmlrpcval itself. See also <<structreset>>.
560
561 [source, php]
562 ----
563
564 // iterating over all values of a struct object
565 $val->structreset();
566 while (list($key, $v) = $val->structEach())
567 {
568   echo "Element $key of the struct is of type ".$v->kindOf();
569 }
570
571 ----
572
573 [[structreset]]
574
575 ===== structReset
576
577 void structReset Resets the internal pointer for
578           structEach() to the beginning of the struct,
579           where $val is a struct.
580
581 [[structmemexists]]
582
583 ===== structMemExists
584
585 bool structMemExsists string $memberName Returns TRUE or
586           FALSE depending on whether a member of the
587           given name exists in the struct.
588
589 [[xmlrpcmsg]]
590
591 === xmlrpcmsg
592
593 This class provides a representation for a request to an XML-RPC
594       server. A client sends an xmlrpcmsg to a server,
595       and receives back an xmlrpcresp (see <<xmlrpc-client-send>>).
596
597 ==== Creation
598
599 The constructor takes the following forms:
600
601 xmlrpcmsgnew
602             xmlrpcmsgstring$methodNamearray$parameterArraynullWhere methodName is a string indicating
603         the name of the method you wish to invoke, and
604         parameterArray is a simple php
605         Array of xmlrpcval
606         objects. Here's an example message to the __US state name__ server:
607
608 [source, php]
609 ----
610
611 $msg = new xmlrpcmsg("examples.getStateName", array(new xmlrpcval(23, "int")));
612
613 ----
614
615 This example requests the name of state number 23. For more
616         information on xmlrpcval objects, see <<xmlrpcval>>.
617
618 Note that the parameterArray parameter is
619         optional and can be omitted for methods that take no input parameters
620         or if you plan to add parameters one by one.
621
622 ==== Methods
623
624
625 ===== addParam
626
627 bool addParam xmlrpcval $xmlrpcVal Adds the xmlrpcval
628           xmlrpcVal to the parameter list for this
629           method call. Returns TRUE or FALSE on error.
630
631 ===== getNumParams
632
633 int getNumParams Returns the number of parameters attached to this
634           message.
635
636 ===== getParam
637
638 xmlrpcval getParam int $n Gets the nth parameter in the message
639           (with the index zero-based). Use this method in server
640           implementations to retrieve the values sent by the client.
641
642 ===== method
643
644 string method string method string $methNameGets or sets the method contained in the XML-RPC
645           message.
646
647 ===== parseResponse
648
649 xmlrpcresp parseResponsestring $xmlString Given an incoming XML-RPC server response contained in the
650           string $xmlString, this method constructs an
651           xmlrpcresp response object and returns it,
652           setting error codes as appropriate (see <<xmlrpc-client-send>>).
653
654 This method processes any HTTP/MIME headers it finds.
655
656 ===== parseResponseFile
657
658 xmlrpcresp parseResponseFile file handle
659               resource$fileHandleGiven an incoming XML-RPC server response on the open file
660           handle fileHandle, this method reads all the
661           data it finds and passes it to
662           parseResponse.
663
664 This method is useful to construct responses from pre-prepared
665           files (see files ++demo1.xml, demo2.xml, demo3.xml++
666           in this distribution). It processes any HTTP headers it finds, and
667           does not close the file handle.
668
669 ===== serialize
670
671 string
672               serializeReturns the an XML string representing the XML-RPC
673           message.
674
675 [[xmlrpc-client]]
676
677 === xmlrpc_client
678
679 This is the basic class used to represent a client of an XML-RPC
680       server.
681
682 ==== Creation
683
684 The constructor accepts one of two possible syntaxes:
685
686 xmlrpc_clientnew
687             xmlrpc_clientstring$server_urlxmlrpc_clientnew
688             xmlrpc_clientstring$server_pathstring$server_hostnameint$server_port80string$transport'http'Here are a couple of usage examples of the first form:
689
690
691 [source, php]
692 ----
693
694 $client = new xmlrpc_client("http://phpxmlrpc.sourceforge.net/server.php");
695 $another_client = new xmlrpc_client("https://james:bond@secret.service.com:443/xmlrpcserver?agent=007");
696
697 ----
698
699 The second syntax does not allow to express a username and
700         password to be used for basic HTTP authorization as in the second
701         example above, but instead it allows to choose whether xmlrpc calls
702         will be made using the HTTP 1.0 or 1.1 protocol.
703
704 Here's another example client set up to query Userland's XML-RPC
705         server at __betty.userland.com__:
706
707 [source, php]
708 ----
709
710 $client = new xmlrpc_client("/RPC2", "betty.userland.com", 80);
711
712 ----
713
714 The server_port parameter is optional,
715         and if omitted will default to 80 when using HTTP and 443 when using
716         HTTPS (see the <<xmlrpc-client-send>> method
717         below).
718
719 The transport parameter is optional, and
720         if omitted will default to 'http'. Allowed values are either
721         'http', 'https' or
722         'http11'. Its value can be overridden with every call
723         to the send method. See the
724         send method below for more details about the
725         meaning of the different values.
726
727
728 ==== Methods
729
730 This class supports the following methods.
731
732 [[xmlrpc-client-send]]
733
734 ===== send
735
736 This method takes the forms:
737
738 xmlrpcresp send xmlrpcmsg $xmlrpc_message int $timeout string $transport array sendarray $xmlrpc_messages int $timeout string $transportxmlrpcrespsendstring$xml_payloadint$timeoutstring$transportWhere xmlrpc_message is an instance of
739           xmlrpcmsg (see <<xmlrpcmsg>>),
740           and response is an instance of
741           xmlrpcresp (see <<xmlrpcresp>>).
742
743 If xmlrpc_messages is an array of
744           message instances, ++responses++ will be an array of
745           response instances. The client will try to make use of a single
746           ++system.multicall++ xml-rpc method call to forward to the
747           server all the messages in a single HTTP round trip, unless
748           ++$$$client-&gt;no_multicall$$++ has been previously set to
749           ++TRUE++ (see the multicall method below), in which case
750           many consecutive xmlrpc requests will be sent.
751
752 The third syntax allows to build by hand (or any other means)
753           a complete xmlrpc request message, and send it to the server.
754           xml_payload should be a string containing the
755           complete xml representation of the request. It is e.g. useful when,
756           for maximal speed of execution, the request is serialized into a
757           string using the native php xmlrpc functions (see link:$$http://www.php.net/xmlrpc$$[the php manual on xmlrpc]).
758
759 The timeout is optional, and will be
760           set to ++0++ (wait for platform-specific predefined
761           timeout) if omitted. This timeout value is passed to
762           fsockopen(). It is also used for detecting
763           server timeouts during communication (i.e. if the server does not
764           send anything to the client for timeout
765           seconds, the connection will be closed).
766
767 The transport parameter is optional,
768           and if omitted will default to the transport set using instance
769           creator or 'http' if omitted. The only other valid values are
770           'https', which will use an SSL HTTP connection to connect to the
771           remote server, and 'http11'. Note that your PHP must have the "curl"
772           extension compiled in order to use both these features. Note that
773           when using SSL you should normally set your port number to 443,
774           unless the SSL server you are contacting runs at any other
775           port.
776
777 In addition to low-level errors, the XML-RPC server you were
778           querying may return an error in the
779           xmlrpcresp object. See <<xmlrpcresp>> for details of how to handle these
780           errors.
781
782 [[multicall]]
783
784 ===== multiCall
785
786 This method takes the form:
787
788 array multiCall array $messages int $timeout string $transport bool $fallback This method is used to boxcar many method calls in a single
789           xml-rpc request. It will try first to make use of the
790           ++system.multicall++ xml-rpc method call, and fall back to
791           executing many separate requests if the server returns any
792           error.
793
794 msgs is an array of
795           xmlrpcmsg objects (see <<xmlrpcmsg>>), and response is an
796           array of xmlrpcresp objects (see <<xmlrpcresp>>).
797
798 The timeout and
799           transport parameters are optional, and behave
800           as in the send method above.
801
802 The fallback parameter is optional, and
803           defaults to TRUE. When set to
804           FALSE it will prevent the client to try using
805           many single method calls in case of failure of the first multicall
806           request. It should be set only when the server is known to support
807           the multicall extension.
808
809 ===== setAcceptedCompression
810
811 void setAcceptedCompression string $compressionmethod This method defines whether the client will accept compressed
812           xml payload forming the bodies of the xmlrpc responses received from
813           servers. Note that enabling reception of compressed responses merely
814           adds some standard http headers to xmlrpc requests. It is up to the
815           xmlrpc server to return compressed responses when receiving such
816           requests. Allowed values for
817           compressionmethod are: 'gzip', 'deflate',
818           'any' or null (with any meaning either gzip or deflate).
819
820 This requires the "zlib" extension to be enabled in your php
821           install. If it is, by default xmlrpc_client
822           instances will enable reception of compressed content.
823
824 ===== setCaCertificate
825
826 voidsetCaCertificatestring$certificatebool$is_dirThis method sets an optional certificate to be used in
827           SSL-enabled communication to validate a remote server with (when the
828           server_method is set to 'https' in the
829           client's construction or in the send method and
830           SetSSLVerifypeer has been set to
831           TRUE).
832
833 The certificate parameter must be the
834           filename of a PEM formatted certificate, or a directory containing
835           multiple certificate files. The is_dir
836           parameter defaults to FALSE, set it to
837           TRUE to specify that
838           certificate indicates a directory instead of
839           a single file.
840
841 This requires the "curl" extension to be compiled into your
842           installation of PHP. For more details see the man page for the
843           curl_setopt function.
844
845
846 ===== setCertificate
847
848 voidsetCertificatestring$certificatestring$passphraseThis method sets the optional certificate and passphrase used
849           in SSL-enabled communication with a remote server (when the
850           server_method is set to 'https' in the
851           client's construction or in the send method).
852
853 The certificate parameter must be the
854           filename of a PEM formatted certificate. The
855           passphrase parameter must contain the
856           password required to use the certificate.
857
858 This requires the "curl" extension to be compiled into your
859           installation of PHP. For more details see the man page for the
860           curl_setopt function.
861
862 Note: to retrieve information about the client certificate on
863           the server side, you will need to look into the environment
864           variables which are set up by the webserver. Different webservers
865           will typically set up different variables.
866
867 ===== setCookie
868
869 void setCookiestring $name string $value string $path string $domain int $portThis method sets a cookie that will be sent to the xmlrpc
870           server along with every further request (useful e.g. for keeping
871           session info outside of the xml-rpc payload).
872
873 $value is optional, and defaults to
874           null.
875
876 $path, $domain and $port are optional,
877           and will be omitted from the cookie header if unspecified. Note that
878           setting any of these values will turn the cookie into a 'version 1'
879           cookie, that might not be fully supported by the server (see RFC2965
880           for more details).
881
882 ===== setCredentials
883
884 voidsetCredentialsstring$usernamestring$passwordint$authtypeThis method sets the username and password for authorizing the
885           client to a server. With the default (HTTP) transport, this
886           information is used for HTTP Basic authorization. Note that username
887           and password can also be set using the class constructor. With HTTP
888           1.1 and HTTPS transport, NTLM and Digest authentication protocols
889           are also supported. To enable them use the constants
890           CURLAUTH_DIGEST and
891           CURLAUTH_NTLM as values for the authtype
892           parameter.
893
894
895 ===== setCurlOptions
896
897 voidsetCurlOptionsarray$optionsThis method allows to directly set any desired
898           option to manipulate the usage of the cURL client (when in cURL
899           mode). It can be used eg. to explicitly bind to an outgoing ip
900           address when the server is multihomed
901
902
903 ===== setDebug
904
905 void setDebugint$debugLvldebugLvl is either ++0, 1++ or 2 depending on whether you require the client to
906           print debugging information to the browser. The default is not to
907           output this information (0).
908
909 The debugging information at level 1includes the raw data
910           returned from the XML-RPC server it was querying (including bot HTTP
911           headers and the full XML payload), and the PHP value the client
912           attempts to create to represent the value returned by the server. At
913           level2, the complete payload of the xmlrpc request is also printed,
914           before being sent t the server.
915
916 This option can be very useful when debugging servers as it
917           allows you to see exactly what the client sends and the server
918           returns.
919
920
921 ===== setKey
922
923 voidsetKeyint$keyint$keypassThis method sets the optional certificate key and passphrase
924           used in SSL-enabled communication with a remote server (when the
925           transport is set to 'https' in the client's
926           construction or in the send method).
927
928 This requires the "curl" extension to be compiled into your
929           installation of PHP. For more details see the man page for the
930           curl_setopt function.
931
932
933 ===== setProxy
934
935 voidsetProxystring$proxyhostint$proxyportstring$proxyusernamestring$proxypasswordint$authtypeThis method enables calling servers via an HTTP proxy. The
936           proxyusername,
937           proxypassword and authtype
938           parameters are optional. Authtype defaults to
939           CURLAUTH_BASIC (Basic authentication protocol);
940           the only other valid value is the constant
941           CURLAUTH_NTLM, and has effect only when the
942           client uses the HTTP 1.1 protocol.
943
944 NB: CURL versions before 7.11.10 cannot use a proxy to
945           communicate with https servers.
946
947
948 ===== setRequestCompression
949
950 voidsetRequestCompressionstring$compressionmethodThis method defines whether the xml payload forming the
951           request body will be sent to the server in compressed format, as per
952           the HTTP specification. This is particularly useful for large
953           request parameters and over slow network connections. Allowed values
954           for compressionmethod are: 'gzip', 'deflate',
955           'any' or null (with any meaning either gzip or deflate). Note that
956           there is no automatic fallback mechanism in place for errors due to
957           servers not supporting receiving compressed request bodies, so make
958           sure that the particular server you are querying does accept
959           compressed requests before turning it on.
960
961 This requires the "zlib" extension to be enabled in your php
962           install.
963
964
965 ===== setSSLVerifyHost
966
967 voidsetSSLVerifyHostint$iThis method defines whether connections made to XML-RPC
968           backends via HTTPS should verify the remote host's SSL certificate's
969           common name (CN). By default, only the existence of a CN is checked.
970           $i should be an
971           integer value; 0 to not check the CN at all, 1 to merely check for
972           its existence, and 2 to check that the CN on the certificate matches
973           the hostname that is being connected to.
974
975
976 ===== setSSLVerifyPeer
977
978 voidsetSSLVerifyPeerbool$iThis method defines whether connections made to XML-RPC
979           backends via HTTPS should verify the remote host's SSL certificate,
980           and cause the connection to fail if the cert verification fails.
981           $i should be a boolean
982           value. Default value: TRUE. To specify custom
983           SSL certificates to validate the server with, use the
984           setCaCertificate method.
985
986
987 ===== setUserAgent
988
989 voidUseragentstring$useragentThis method sets a custom user-agent that will be
990           used by the client in the http headers sent with the request. The
991           default value is built using the library name and version
992           constants.
993
994
995 ==== Variables
996
997 NB: direct manipulation of these variables is only recommended
998         for advanced users.
999
1000
1001 ===== no_multicall
1002
1003 This member variable determines whether the multicall() method
1004           will try to take advantage of the system.multicall xmlrpc method to
1005           dispatch to the server an array of requests in a single http
1006           roundtrip or simply execute many consecutive http calls. Defaults to
1007           FALSE, but it will be enabled automatically on the first failure of
1008           execution of system.multicall.
1009
1010
1011 ===== request_charset_encoding
1012
1013 This is the charset encoding that will be used for serializing
1014           request sent by the client.
1015
1016 If defaults to NULL, which means using US-ASCII and encoding
1017           all characters outside of the ASCII range using their xml character
1018           entity representation (this has the benefit that line end characters
1019           will not be mangled in the transfer, a CR-LF will be preserved as
1020           well as a singe LF).
1021
1022 Valid values are 'US-ASCII', 'UTF-8' and 'ISO-8859-1'
1023
1024 [[return-type]]
1025
1026 ===== return_type
1027
1028 This member variable determines whether the value returned
1029           inside an xmlrpcresp object as results of calls to the send() and
1030           multicall() methods will be an xmlrpcval object, a plain php value
1031           or a raw xml string. Allowed values are 'xmlrpcvals' (the default),
1032           'phpvals' and 'xml'. To allow the user to differentiate between a
1033           correct and a faulty response, fault responses will be returned as
1034           xmlrpcresp objects in any case. Note that the 'phpvals' setting will
1035           yield faster execution times, but some of the information from the
1036           original response will be lost. It will be e.g. impossible to tell
1037           whether a particular php string value was sent by the server as an
1038           xmlrpc string or base64 value.
1039
1040 Example usage:
1041
1042
1043 [source, php]
1044 ----
1045
1046 $client = new xmlrpc_client("phpxmlrpc.sourceforge.net/server.php");
1047 $client->return_type = 'phpvals';
1048 $message = new xmlrpcmsg("examples.getStateName", array(new xmlrpcval(23, "int")));
1049 $resp = $client->send($message);
1050 if ($resp->faultCode()) echo 'KO. Error: '.$resp->faultString(); else echo 'OK: got '.$resp->value();
1051
1052 ----
1053
1054 For more details about usage of the 'xml' value, see Appendix
1055           A.
1056
1057 [[xmlrpcresp]]
1058
1059 === xmlrpcresp
1060
1061 This class is used to contain responses to XML-RPC requests. A
1062       server method handler will construct an
1063       xmlrpcresp and pass it as a return value. This
1064       same value will be returned by the result of an invocation of the
1065       send method of the
1066       xmlrpc_client class.
1067
1068
1069 ==== Creation
1070
1071 xmlrpcrespnew
1072             xmlrpcrespxmlrpcval$xmlrpcvalxmlrpcrespnew
1073             xmlrpcresp0int$errcodestring$err_stringThe first syntax is used when execution has happened without
1074         difficulty: $xmlrpcval is an
1075         xmlrpcval value with the result of the method
1076         execution contained in it. Alternatively it can be a string containing
1077         the xml serialization of the single xml-rpc value result of method
1078         execution.
1079
1080 The second type of constructor is used in case of failure.
1081         errcode and err_string
1082         are used to provide indication of what has gone wrong. See <<xmlrpc-server>> for more information on passing error
1083         codes.
1084
1085
1086 ==== Methods
1087
1088
1089 ===== faultCode
1090
1091 intfaultCodeReturns the integer fault code return from the XML-RPC
1092           response. A zero value indicates success, any other value indicates
1093           a failure response.
1094
1095
1096 ===== faultString
1097
1098 stringfaultStringReturns the human readable explanation of the fault indicated
1099           by $resp-&gt;faultCode().
1100
1101
1102 ===== value
1103
1104 xmlrpcvalvalueReturns an xmlrpcval object containing
1105           the return value sent by the server. If the response's
1106           faultCode is non-zero then the value returned
1107           by this method should not be used (it may not even be an
1108           object).
1109
1110 Note: if the xmlrpcresp instance in question has been created
1111           by an xmlrpc_client object whose
1112           return_type was set to 'phpvals', then a plain
1113           php value will be returned instead of an
1114           xmlrpcval object. If the
1115           return_type was set to 'xml', an xml string will
1116           be returned (see the return_type member var above for more
1117           details).
1118
1119
1120 ===== serialize
1121
1122 stringserializeReturns an XML string representation of the response (xml
1123           prologue not included).
1124
1125 [[xmlrpc-server]]
1126
1127 === xmlrpc_server
1128
1129 The implementation of this class has been kept as simple to use as
1130       possible. The constructor for the server basically does all the work.
1131       Here's a minimal example:
1132
1133
1134 [source, php]
1135 ----
1136
1137   function foo ($xmlrpcmsg) {
1138     ...
1139     return new xmlrpcresp($some_xmlrpc_val);
1140   }
1141
1142   class bar {
1143     function foobar($xmlrpcmsg) {
1144       ...
1145       return new xmlrpcresp($some_xmlrpc_val);
1146     }
1147   }
1148
1149   $s = new xmlrpc_server(
1150     array(
1151       "examples.myFunc1" => array("function" => "foo"),
1152       "examples.myFunc2" => array("function" => "bar::foobar"),
1153     ));
1154
1155 ----
1156
1157 This performs everything you need to do with a server. The single
1158       constructor argument is an associative array from xmlrpc method names to
1159       php function names. The incoming request is parsed and dispatched to the
1160       relevant php function, which is responsible for returning a
1161       xmlrpcresp object, that will be serialized back
1162       to the caller.
1163
1164
1165 ==== Method handler functions
1166
1167 Both php functions and class methods can be registered as xmlrpc
1168         method handlers.
1169
1170 The synopsis of a method handler function is:
1171
1172 xmlrpcresp $resp = function (xmlrpcmsg $msg)
1173
1174 No text should be echoed 'to screen' by the handler function, or
1175         it will break the xml response sent back to the client. This applies
1176         also to error and warning messages that PHP prints to screen unless
1177         the appropriate parameters have been set in the php.in file. Another
1178         way to prevent echoing of errors inside the response and facilitate
1179         debugging is to use the server SetDebug method with debug level 3 (see
1180         ...). Exceptions thrown duting execution of handler functions are
1181         caught by default and a XML-RPC error reponse is generated instead.
1182         This behaviour can be finetuned by usage of the
1183         exception_handling member variable (see
1184         ...).
1185
1186 Note that if you implement a method with a name prefixed by
1187         ++system.++ the handler function will be invoked by the
1188         server with two parameters, the first being the server itself and the
1189         second being the xmlrpcmsg object.
1190
1191 The same php function can be registered as handler of multiple
1192         xmlrpc methods.
1193
1194 Here is a more detailed example of what the handler function
1195         foo may do:
1196
1197
1198 [source, php]
1199 ----
1200
1201   function foo ($xmlrpcmsg) {
1202     global $xmlrpcerruser; // import user errcode base value
1203
1204     $meth = $xmlrpcmsg->method(); // retrieve method name
1205     $par = $xmlrpcmsg->getParam(0); // retrieve value of first parameter - assumes at least one param received
1206     $val = $par->scalarval(); // decode value of first parameter - assumes it is a scalar value
1207
1208     ...
1209
1210     if ($err) {
1211       // this is an error condition
1212       return new xmlrpcresp(0, $xmlrpcerruser+1, // user error 1
1213         "There's a problem, Captain");
1214     } else {
1215       // this is a successful value being returned
1216       return new xmlrpcresp(new xmlrpcval("All's fine!", "string"));
1217     }
1218   }
1219
1220 ----
1221
1222 See __server.php__ in this distribution for
1223         more examples of how to do this.
1224
1225 Since release 2.0RC3 there is a new, even simpler way of
1226         registering php functions with the server. See section 5.7
1227         below
1228
1229
1230 ==== The dispatch map
1231
1232 The first argument to the xmlrpc_server
1233         constructor is an array, called the __dispatch map__.
1234         In this array is the information the server needs to service the
1235         XML-RPC methods you define.
1236
1237 The dispatch map takes the form of an associative array of
1238         associative arrays: the outer array has one entry for each method, the
1239         key being the method name. The corresponding value is another
1240         associative array, which can have the following members:
1241
1242
1243 * ++function++ - this
1244             entry is mandatory. It must be either a name of a function in the
1245             global scope which services the XML-RPC method, or an array
1246             containing an instance of an object and a static method name (for
1247             static class methods the 'class::method' syntax is also
1248             supported).
1249
1250
1251 * ++signature++ - this
1252             entry is an array containing the possible signatures (see <<signatures>>) for the method. If this entry is present
1253             then the server will check that the correct number and type of
1254             parameters have been sent for this method before dispatching
1255             it.
1256
1257
1258 * ++docstring++ - this
1259             entry is a string containing documentation for the method. The
1260             documentation may contain HTML markup.
1261
1262
1263 * ++$$signature_docs$$++ - this entry can be used
1264             to provide documentation for the single parameters. It must match
1265             in structure the 'signature' member. By default, only the
1266             documenting_xmlrpc_server class in the
1267             extras package will take advantage of this, since the
1268             "system.methodHelp" protocol does not support documenting method
1269             parameters individually.
1270
1271
1272 * ++$$parameters_type$$++ - this entry can be used
1273             when the server is working in 'xmlrpcvals' mode (see ...) to
1274             define one or more entries in the dispatch map as being functions
1275             that follow the 'phpvals' calling convention. The only useful
1276             value is currently the string ++phpvals++.
1277
1278 Look at the __server.php__ example in the
1279         distribution to see what a dispatch map looks like.
1280
1281 [[signatures]]
1282
1283 ==== Method signatures
1284
1285 A signature is a description of a method's return type and its
1286         parameter types. A method may have more than one signature.
1287
1288 Within a server's dispatch map, each method has an array of
1289         possible signatures. Each signature is an array of types. The first
1290         entry is the return type. For instance, the method
1291 [source, php]
1292 ----
1293 string examples.getStateName(int)
1294
1295 ----
1296
1297  has the signature
1298 [source, php]
1299 ----
1300 array($xmlrpcString, $xmlrpcInt)
1301
1302 ----
1303
1304  and, assuming that it is the only possible signature for the
1305         method, it might be used like this in server creation:
1306 [source, php]
1307 ----
1308
1309 $findstate_sig = array(array($xmlrpcString, $xmlrpcInt));
1310
1311 $findstate_doc = 'When passed an integer between 1 and 51 returns the
1312 name of a US state, where the integer is the index of that state name
1313 in an alphabetic order.';
1314
1315 $s = new xmlrpc_server( array(
1316   "examples.getStateName" => array(
1317     "function" => "findstate",
1318     "signature" => $findstate_sig,
1319     "docstring" => $findstate_doc
1320   )));
1321
1322 ----
1323
1324
1325
1326 Note that method signatures do not allow to check nested
1327         parameters, e.g. the number, names and types of the members of a
1328         struct param cannot be validated.
1329
1330 If a method that you want to expose has a definite number of
1331         parameters, but each of those parameters could reasonably be of
1332         multiple types, the array of acceptable signatures will easily grow
1333         into a combinatorial explosion. To avoid such a situation, the lib
1334         defines the global var $xmlrpcValue, which can be
1335         used in method signatures as a placeholder for 'any xmlrpc
1336         type':
1337
1338
1339 [source, php]
1340 ----
1341
1342 $echoback_sig = array(array($xmlrpcValue, $xmlrpcValue));
1343
1344 $findstate_doc = 'Echoes back to the client the received value, regardless of its type';
1345
1346 $s = new xmlrpc_server( array(
1347   "echoBack" => array(
1348     "function" => "echoback",
1349     "signature" => $echoback_sig, // this sig guarantees that the method handler will be called with one and only one parameter
1350     "docstring" => $echoback_doc
1351   )));
1352
1353 ----
1354
1355 Methods system.listMethods,
1356         system.methodHelp,
1357         system.methodSignature and
1358         system.multicall are already defined by the
1359         server, and should not be reimplemented (see Reserved Methods
1360         below).
1361
1362
1363 ==== Delaying the server response
1364
1365 You may want to construct the server, but for some reason not
1366         fulfill the request immediately (security verification, for instance).
1367         If you omit to pass to the constructor the dispatch map or pass it a
1368         second argument of ++0++ this will have the desired
1369         effect. You can then use the service() method of
1370         the server class to service the request. For example:
1371
1372
1373 [source, php]
1374 ----
1375
1376 $s = new xmlrpc_server($myDispMap, 0); // second parameter = 0 prevents automatic servicing of request
1377
1378 // ... some code that does other stuff here
1379
1380 $s->service();
1381
1382 ----
1383
1384 Note that the service method will print
1385         the complete result payload to screen and send appropriate HTTP
1386         headers back to the client, but also return the response object. This
1387         permits further manipulation of the response, possibly in combination
1388         with output buffering.
1389
1390 To prevent the server from sending HTTP headers back to the
1391         client, you can pass a second parameter with a value of
1392         ++TRUE++ to the service
1393         method. In this case, the response payload will be returned instead of
1394         the response object.
1395
1396 Xmlrpc requests retrieved by other means than HTTP POST bodies
1397         can also be processed. For example:
1398
1399
1400 [source, php]
1401 ----
1402
1403 $s = new xmlrpc_server(); // not passing a dispatch map prevents automatic servicing of request
1404
1405 // ... some code that does other stuff here, including setting dispatch map into server object
1406
1407 $resp = $s->service($xmlrpc_request_body, true); // parse a variable instead of POST body, retrieve response payload
1408
1409 // ... some code that does other stuff with xml response $resp here
1410
1411 ----
1412
1413
1414 ==== Modifying the server behaviour
1415
1416 A couple of methods / class variables are available to modify
1417         the behaviour of the server. The only way to take advantage of their
1418         existence is by usage of a delayed server response (see above)
1419
1420
1421 ===== setDebug()
1422
1423 This function controls weather the server is going to echo
1424           debugging messages back to the client as comments in response body.
1425           Valid values: 0,1,2,3, with 1 being the default. At level 0, no
1426           debug info is returned to the client. At level 2, the complete
1427           client request is added to the response, as part of the xml
1428           comments. At level 3, a new PHP error handler is set when executing
1429           user functions exposed as server methods, and all non-fatal errors
1430           are trapped and added as comments into the response.
1431
1432
1433 ===== allow_system_funcs
1434
1435 Default_value: TRUE. When set to FALSE, disables support for
1436           System.xxx functions in the server. It
1437           might be useful e.g. if you do not wish the server to respond to
1438           requests to System.ListMethods.
1439
1440
1441 ===== compress_response
1442
1443 When set to TRUE, enables the server to take advantage of HTTP
1444           compression, otherwise disables it. Responses will be transparently
1445           compressed, but only when an xmlrpc-client declares its support for
1446           compression in the HTTP headers of the request.
1447
1448 Note that the ZLIB php extension must be installed for this to
1449           work. If it is, compress_response will default to
1450           TRUE.
1451
1452
1453 ===== exception_handling
1454
1455 This variable controls the behaviour of the server when an
1456           exception is thrown by a method handler php function. Valid values:
1457           0,1,2, with 0 being the default. At level 0, the server catches the
1458           exception and return an 'internal error' xmlrpc response; at 1 it
1459           catches the exceptions and return an xmlrpc response with the error
1460           code and error message corresponding to the exception that was
1461           thron; at 2 = the exception is floated to the upper layers in the
1462           code
1463
1464
1465 ===== response_charset_encoding
1466
1467 Charset encoding to be used for response (only affects string
1468           values).
1469
1470 If it can, the server will convert the generated response from
1471           internal_encoding to the intended one.
1472
1473 Valid values are: a supported xml encoding (only UTF-8 and
1474           ISO-8859-1 at present, unless mbstring is enabled), null (leave
1475           charset unspecified in response and convert output stream to
1476           US_ASCII), 'default' (use xmlrpc library default as specified in
1477           xmlrpc.inc, convert output stream if needed), or 'auto' (use
1478           client-specified charset encoding or same as request if request
1479           headers do not specify it (unless request is US-ASCII: then use
1480           library default anyway).
1481
1482
1483 ==== Fault reporting
1484
1485 Fault codes for your servers should start at the value indicated
1486         by the global ++$xmlrpcerruser++ + 1.
1487
1488 Standard errors returned by the server include:
1489
1490 ++1++ Unknown method:: Returned if the server was asked to dispatch a method it
1491               didn't know about
1492
1493 ++2++ Invalid return payload:: This error is actually generated by the client, not
1494               server, code, but signifies that a server returned something it
1495               couldn't understand. A more detailed error report is sometimes
1496               added onto the end of the phrase above.
1497
1498 ++3++ Incorrect parameters:: This error is generated when the server has signature(s)
1499               defined for a method, and the parameters passed by the client do
1500               not match any of signatures.
1501
1502 ++4++ Can't introspect: method unknown:: This error is generated by the builtin
1503               system.* methods when any kind of
1504               introspection is attempted on a method undefined by the
1505               server.
1506
1507 ++5++ Didn't receive 200 OK from remote server:: This error is generated by the client when a remote server
1508               doesn't return HTTP/1.1 200 OK in response to a request. A more
1509               detailed error report is added onto the end of the phrase
1510               above.
1511
1512 ++6++ No data received from server:: This error is generated by the client when a remote server
1513               returns HTTP/1.1 200 OK in response to a request, but no
1514               response body follows the HTTP headers.
1515
1516 ++7++ No SSL support compiled in:: This error is generated by the client when trying to send
1517               a request with HTTPS and the CURL extension is not available to
1518               PHP.
1519
1520 ++8++ CURL error:: This error is generated by the client when trying to send
1521               a request with HTTPS and the HTTPS communication fails.
1522
1523 ++9-14++ multicall errors:: These errors are generated by the server when something
1524               fails inside a system.multicall request.
1525
1526 ++100-++ XML parse errors:: Returns 100 plus the XML parser error code for the fault
1527               that occurred. The faultString returned
1528               explains where the parse error was in the incoming XML
1529               stream.
1530
1531
1532 ==== 'New style' servers
1533
1534 In the same spirit of simplification that inspired the
1535         xmlrpc_client::return_type class variable, a new
1536         class variable has been added to the server class:
1537         functions_parameters_type. When set to 'phpvals',
1538         the functions registered in the server dispatch map will be called
1539         with plain php values as parameters, instead of a single xmlrpcmsg
1540         instance parameter. The return value of those functions is expected to
1541         be a plain php value, too. An example is worth a thousand
1542         words:
1543 [source, php]
1544 ----
1545
1546   function foo($usr_id, $out_lang='en') {
1547     global $xmlrpcerruser;
1548
1549     ...
1550
1551     if ($someErrorCondition)
1552       return new xmlrpcresp(0, $xmlrpcerruser+1, 'DOH!');
1553     else
1554       return array(
1555         'name' => 'Joe',
1556         'age' => 27,
1557         'picture' => new xmlrpcval(file_get_contents($picOfTheGuy), 'base64')
1558       );
1559   }
1560
1561   $s = new xmlrpc_server(
1562     array(
1563       "examples.myFunc" => array(
1564         "function" => "bar::foobar",
1565         "signature" => array(
1566           array($xmlrpcString, $xmlrpcInt),
1567           array($xmlrpcString, $xmlrpcInt, $xmlrpcString)
1568         )
1569       )
1570     ), false);
1571   $s->functions_parameters_type = 'phpvals';
1572   $s->service();
1573
1574 ----
1575
1576 There are a few things to keep in mind when using this
1577         simplified syntax:
1578
1579 to return an xmlrpc error, the method handler function must
1580         return an instance of xmlrpcresp. The only
1581         other way for the server to know when an error response should be
1582         served to the client is to throw an exception and set the server's
1583         exception_handling memeber var to 1;
1584
1585 to return a base64 value, the method handler function must
1586         encode it on its own, creating an instance of an xmlrpcval
1587         object;
1588
1589 the method handler function cannot determine the name of the
1590         xmlrpc method it is serving, unlike standard handler functions that
1591         can retrieve it from the message object;
1592
1593 when receiving nested parameters, the method handler function
1594         has no way to distinguish a php string that was sent as base64 value
1595         from one that was sent as a string value;
1596
1597 this has a direct consequence on the support of
1598         system.multicall: a method whose signature contains datetime or base64
1599         values will not be available to multicall calls;
1600
1601 last but not least, the direct parsing of xml to php values is
1602         much faster than using xmlrpcvals, and allows the library to handle
1603         much bigger messages without allocating all available server memory or
1604         smashing PHP recursive call stack.
1605
1606
1607 [[globalvars]]
1608
1609 == Global variables
1610
1611 Many global variables are defined in the xmlrpc.inc file. Some of
1612     those are meant to be used as constants (and modifying their value might
1613     cause unpredictable behaviour), while some others can be modified in your
1614     php scripts to alter the behaviour of the xml-rpc client and
1615     server.
1616
1617
1618 === "Constant" variables
1619
1620
1621 ==== $xmlrpcerruser
1622
1623 $xmlrpcerruser800The minimum value for errors reported by user
1624         implemented XML-RPC servers. Error numbers lower than that are
1625         reserved for library usage.
1626
1627
1628 ==== $xmlrpcI4, $xmlrpcInt, $xmlrpcBoolean, $xmlrpcDouble, $xmlrpcString, $xmlrpcDateTime, $xmlrpcBase64, $xmlrpcArray, $xmlrpcStruct, $xmlrpcValue, $xmlrpcNull
1629
1630 For convenience the strings representing the XML-RPC types have
1631         been encoded as global variables:
1632 [source, php]
1633 ----
1634
1635 $xmlrpcI4="i4";
1636 $xmlrpcInt="int";
1637 $xmlrpcBoolean="boolean";
1638 $xmlrpcDouble="double";
1639 $xmlrpcString="string";
1640 $xmlrpcDateTime="dateTime.iso8601";
1641 $xmlrpcBase64="base64";
1642 $xmlrpcArray="array";
1643 $xmlrpcStruct="struct";
1644 $xmlrpcValue="undefined";
1645 $xmlrpcNull="null";
1646
1647 ----
1648
1649 ==== $xmlrpcTypes, $xmlrpc_valid_parents, $xmlrpcerr, $xmlrpcstr, $xmlrpcerrxml, $xmlrpc_backslash, $_xh, $xml_iso88591_Entities, $xmlEntities, $xmlrpcs_capabilities
1650
1651 Reserved for internal usage.
1652
1653
1654 === Variables whose value can be modified
1655
1656 [[xmlrpc-defencoding]]
1657
1658 ==== xmlrpc_defencoding
1659
1660 $xmlrpc_defencoding"UTF8"This variable defines the character set encoding that will be
1661         used by the xml-rpc client and server to decode the received messages,
1662         when a specific charset declaration is not found (in the messages sent
1663         non-ascii chars are always encoded using character references, so that
1664         the produced xml is valid regardless of the charset encoding
1665         assumed).
1666
1667 Allowed values: ++"UTF8"++,
1668         ++"ISO-8859-1"++, ++"ASCII".++
1669
1670 Note that the appropriate RFC actually mandates that XML
1671         received over HTTP without indication of charset encoding be treated
1672         as US-ASCII, but many servers and clients 'in the wild' violate the
1673         standard, and assume the default encoding is UTF-8.
1674
1675
1676 ==== xmlrpc_internalencoding
1677
1678 $xmlrpc_internalencoding"ISO-8859-1"This variable defines the character set encoding
1679         that the library uses to transparently encode into valid XML the
1680         xml-rpc values created by the user and to re-encode the received
1681         xml-rpc values when it passes them to the PHP application. It only
1682         affects xml-rpc values of string type. It is a separate value from
1683         xmlrpc_defencoding, allowing e.g. to send/receive xml messages encoded
1684         on-the-wire in US-ASCII and process them as UTF-8. It defaults to the
1685         character set used internally by PHP (unless you are running an
1686         MBString-enabled installation), so you should change it only in
1687         special situations, if e.g. the string values exchanged in the xml-rpc
1688         messages are directly inserted into / fetched from a database
1689         configured to return UTF8 encoded strings to PHP. Example
1690         usage:
1691
1692 [source, php]
1693 ----
1694
1695 <?php
1696
1697 include('xmlrpc.inc');
1698 $xmlrpc_internalencoding = 'UTF-8'; // this has to be set after the inclusion above
1699 $v = new xmlrpcval('κόÏ\83με'); // This xmlrpc value will be correctly serialized as the greek word 'kosme'
1700
1701 ----
1702
1703 ==== xmlrpcName
1704
1705 $xmlrpcName"XML-RPC for PHP"The string representation of the name of the XML-RPC
1706         for PHP library. It is used by the client for building the User-Agent
1707         HTTP header that is sent with every request to the server. You can
1708         change its value if you need to customize the User-Agent
1709         string.
1710
1711
1712 ==== xmlrpcVersion
1713
1714 $xmlrpcVersion"2.2"The string representation of the version number of
1715         the XML-RPC for PHP library in use. It is used by the client for
1716         building the User-Agent HTTP header that is sent with every request to
1717         the server. You can change its value if you need to customize the
1718         User-Agent string.
1719
1720
1721 ==== xmlrpc_null_extension
1722
1723 When set to TRUE, the lib will enable
1724         support for the &lt;NIL/&gt; (and &lt;EX:NIL/&gt;) xmlrpc value, as
1725         per the extension to the standard proposed here. This means that
1726         &lt;NIL/&gt; and &lt;EX:NIL/&gt; tags received will be parsed as valid
1727         xmlrpc, and the corresponding xmlrpcvals will return "null" for
1728         scalarTyp().
1729
1730
1731 ==== xmlrpc_null_apache_encoding
1732
1733 When set to ++TRUE++, php NULL values encoded
1734         into xmlrpcval objects get serialized using the
1735         ++&lt;EX:NIL/&gt;++ tag instead of
1736         ++&lt;NIL/&gt;++. Please note that both forms are
1737         always accepted as input regardless of the value of this
1738         variable.
1739
1740
1741 [[helpers]]
1742
1743 == Helper functions
1744
1745 XML-RPC for PHP contains some helper functions which you can use to
1746     make processing of XML-RPC requests easier.
1747
1748
1749 === Date functions
1750
1751 The XML-RPC specification has this to say on dates:
1752
1753 [quote]
1754 ____
1755 [[wrap_xmlrpc_method]]
1756 Don't assume a timezone. It should be
1757         specified by the server in its documentation what assumptions it makes
1758         about timezones.
1759 ____
1760
1761
1762 Unfortunately, this means that date processing isn't
1763       straightforward. Although XML-RPC uses ISO 8601 format dates, it doesn't
1764       use the timezone specifier.
1765
1766 We strongly recommend that in every case where you pass dates in
1767       XML-RPC calls, you use UTC (GMT) as your timezone. Most computer
1768       languages include routines for handling GMT times natively, and you
1769       won't have to translate between timezones.
1770
1771 For more information about dates, see link:$$http://www.uic.edu/year2000/datefmt.html$$[ISO 8601: The Right Format for Dates], which has a handy link to a PDF of the ISO
1772       8601 specification. Note that XML-RPC uses exactly one of the available
1773       representations: CCYYMMDDTHH:MM:SS.
1774
1775 [[iso8601encode]]
1776
1777 ==== iso8601_encode
1778
1779 stringiso8601_encodestring$time_tint$utc0Returns an ISO 8601 formatted date generated from the UNIX
1780         timestamp $time_t, as returned by the PHP
1781         function time().
1782
1783 The argument $utc can be omitted, in
1784         which case it defaults to ++0++. If it is set to
1785         ++1++, then the function corrects the time passed in
1786         for UTC. Example: if you're in the GMT-6:00 timezone and set
1787         $utc, you will receive a date representation
1788         six hours ahead of your local time.
1789
1790 The included demo program __vardemo.php__
1791         includes a demonstration of this function.
1792
1793 [[iso8601decode]]
1794
1795 ==== iso8601_decode
1796
1797 intiso8601_decodestring$isoStringint$utc0Returns a UNIX timestamp from an ISO 8601 encoded time and date
1798         string passed in. If $utc is
1799         ++1++ then $isoString is assumed
1800         to be in the UTC timezone, and thus the result is also UTC: otherwise,
1801         the timezone is assumed to be your local timezone and you receive a
1802         local timestamp.
1803
1804 [[arrayuse]]
1805
1806 === Easy use with nested PHP values
1807
1808 Dan Libby was kind enough to contribute two helper functions that
1809       make it easier to translate to and from PHP values. This makes it easier
1810       to deal with complex structures. At the moment support is limited to
1811       int, double, string,
1812       array, datetime and struct
1813       datatypes; note also that all PHP arrays are encoded as structs, except
1814       arrays whose keys are integer numbers starting with 0 and incremented by
1815       1.
1816
1817 These functions reside in __xmlrpc.inc__.
1818
1819 [[phpxmlrpcdecode]]
1820
1821 ==== php_xmlrpc_decode
1822
1823 mixedphp_xmlrpc_decodexmlrpcval$xmlrpc_valarray$optionsarrayphp_xmlrpc_decodexmlrpcmsg$xmlrpcmsg_valstring$optionsReturns a native PHP value corresponding to the values found in
1824         the xmlrpcval $xmlrpc_val,
1825         translated into PHP types. Base-64 and datetime values are
1826         automatically decoded to strings.
1827
1828 In the second form, returns an array containing the parameters
1829         of the given
1830         xmlrpcmsg_val, decoded
1831         to php types.
1832
1833 The options parameter is optional. If
1834         specified, it must consist of an array of options to be enabled in the
1835         decoding process. At the moment the only valid option are
1836         decode_php_objs and
1837         ++$$dates_as_objects$$++. When the first is set, php
1838         objects that have been converted to xml-rpc structs using the
1839         php_xmlrpc_encode function and a corresponding
1840         encoding option will be converted back into object values instead of
1841         arrays (provided that the class definition is available at
1842         reconstruction time). When the second is set, XML-RPC datetime values
1843         will be converted into native dateTime objects
1844         instead of strings.
1845
1846 ____WARNING__:__ please take
1847         extreme care before enabling the decode_php_objs
1848         option: when php objects are rebuilt from the received xml, their
1849         constructor function will be silently invoked. This means that you are
1850         allowing the remote end to trigger execution of uncontrolled PHP code
1851         on your server, opening the door to code injection exploits. Only
1852         enable this option when you have complete trust of the remote
1853         server/client.
1854
1855 Example:
1856 [source, php]
1857 ----
1858
1859 // wrapper to expose an existing php function as xmlrpc method handler
1860 function foo_wrapper($m)
1861 {
1862   $params = php_xmlrpc_decode($m);
1863   $retval = call_user_func_array('foo', $params);
1864   return new xmlrpcresp(new xmlrpcval($retval)); // foo return value will be serialized as string
1865 }
1866
1867 $s = new xmlrpc_server(array(
1868    "examples.myFunc1" => array(
1869      "function" => "foo_wrapper",
1870      "signatures" => ...
1871   )));
1872
1873 ----
1874
1875 [[phpxmlrpcencode]]
1876
1877 ==== php_xmlrpc_encode
1878
1879 xmlrpcvalphp_xmlrpc_encodemixed$phpvalarray$optionsReturns an xmlrpcval object populated with the PHP
1880         values in $phpval. Works recursively on arrays
1881         and objects, encoding numerically indexed php arrays into array-type
1882         xmlrpcval objects and non numerically indexed php arrays into
1883         struct-type xmlrpcval objects. Php objects are encoded into
1884         struct-type xmlrpcvals, excepted for php values that are already
1885         instances of the xmlrpcval class or descendants thereof, which will
1886         not be further encoded. Note that there's no support for encoding php
1887         values into base-64 values. Encoding of date-times is optionally
1888         carried on on php strings with the correct format.
1889
1890 The options parameter is optional. If
1891         specified, it must consist of an array of options to be enabled in the
1892         encoding process. At the moment the only valid options are
1893         encode_php_objs, ++$$null_extension$$++
1894         and auto_dates.
1895
1896 The first will enable the creation of 'particular' xmlrpcval
1897         objects out of php objects, that add a "php_class" xml attribute to
1898         their serialized representation. This attribute allows the function
1899         php_xmlrpc_decode to rebuild the native php objects (provided that the
1900         same class definition exists on both sides of the communication). The
1901         second allows to encode php ++NULL++ values to the
1902         ++&lt;NIL/&gt;++ (or
1903         ++&lt;EX:NIL/&gt;++, see ...) tag. The last encodes any
1904         string that matches the ISO8601 format into an XML-RPC
1905         datetime.
1906
1907 Example:
1908 [source, php]
1909 ----
1910
1911 // the easy way to build a complex xml-rpc struct, showing nested base64 value and datetime values
1912 $val = php_xmlrpc_encode(array(
1913   'first struct_element: an int' => 666,
1914   'second: an array' => array ('apple', 'orange', 'banana'),
1915   'third: a base64 element' => new xmlrpcval('hello world', 'base64'),
1916   'fourth: a datetime' => '20060107T01:53:00'
1917   ), array('auto_dates'));
1918
1919 ----
1920
1921 ==== php_xmlrpc_decode_xml
1922
1923 xmlrpcval | xmlrpcresp |
1924             xmlrpcmsgphp_xmlrpc_decode_xmlstring$xmlarray$optionsDecodes the xml representation of either an xmlrpc request,
1925         response or single value, returning the corresponding php-xmlrpc
1926         object, or ++FALSE++ in case of an error.
1927
1928 The options parameter is optional. If
1929         specified, it must consist of an array of options to be enabled in the
1930         decoding process. At the moment, no option is supported.
1931
1932 Example:
1933 [source, php]
1934 ----
1935
1936 $text = '<value><array><data><value>Hello world</value></data></array></value>';
1937 $val = php_xmlrpc_decode_xml($text);
1938 if ($val) echo 'Found a value of type '.$val->kindOf(); else echo 'Found invalid xml';
1939
1940 ----
1941
1942 === Automatic conversion of php functions into xmlrpc methods (and vice versa)
1943
1944 For the extremely lazy coder, helper functions have been added
1945       that allow to convert a php function into an xmlrpc method, and a
1946       remotely exposed xmlrpc method into a local php function - or a set of
1947       methods into a php class. Note that these comes with many caveat.
1948
1949
1950 ==== wrap_xmlrpc_method
1951
1952 stringwrap_xmlrpc_method$client$methodname$extra_optionsstringwrap_xmlrpc_method$client$methodname$signum$timeout$protocol$funcnameGiven an xmlrpc server and a method name, creates a php wrapper
1953         function that will call the remote method and return results using
1954         native php types for both params and results. The generated php
1955         function will return an xmlrpcresp object for failed xmlrpc
1956         calls.
1957
1958 The second syntax is deprecated, and is listed here only for
1959         backward compatibility.
1960
1961 The server must support the
1962         system.methodSignature xmlrpc method call for
1963         this function to work.
1964
1965 The client param must be a valid
1966         xmlrpc_client object, previously created with the address of the
1967         target xmlrpc server, and to which the preferred communication options
1968         have been set.
1969
1970 The optional parameters can be passed as array key,value pairs
1971         in the extra_options param.
1972
1973 The signum optional param has the purpose
1974         of indicating which method signature to use, if the given server
1975         method has multiple signatures (defaults to 0).
1976
1977 The timeout and
1978         protocol optional params are the same as in the
1979         xmlrpc_client::send() method.
1980
1981 If set, the optional new_function_name
1982         parameter indicates which name should be used for the generated
1983         function. In case it is not set the function name will be
1984         auto-generated.
1985
1986 If the ++$$return_source$$++ optional parameter is
1987         set, the function will return the php source code to build the wrapper
1988         function, instead of evaluating it (useful to save the code and use it
1989         later as stand-alone xmlrpc client).
1990
1991 If the ++$$encode_php_objs$$++ optional parameter is
1992         set, instances of php objects later passed as parameters to the newly
1993         created function will receive a 'special' treatment that allows the
1994         server to rebuild them as php objects instead of simple arrays. Note
1995         that this entails using a "slightly augmented" version of the xmlrpc
1996         protocol (ie. using element attributes), which might not be understood
1997         by xmlrpc servers implemented using other libraries.
1998
1999 If the ++$$decode_php_objs$$++ optional parameter is
2000         set, instances of php objects that have been appropriately encoded by
2001         the server using a coordinate option will be deserialized as php
2002         objects instead of simple arrays (the same class definition should be
2003         present server side and client side).
2004
2005 __Note that this might pose a security risk__,
2006         since in order to rebuild the object instances their constructor
2007         method has to be invoked, and this means that the remote server can
2008         trigger execution of unforeseen php code on the client: not really a
2009         code injection, but almost. Please enable this option only when you
2010         trust the remote server.
2011
2012 In case of an error during generation of the wrapper function,
2013         FALSE is returned, otherwise the name (or source code) of the new
2014         function.
2015
2016 Known limitations: server must support
2017         system.methodsignature for the wanted xmlrpc
2018         method; for methods that expose multiple signatures, only one can be
2019         picked; for remote calls with nested xmlrpc params, the caller of the
2020         generated php function has to encode on its own the params passed to
2021         the php function if these are structs or arrays whose (sub)members
2022         include values of type base64.
2023
2024 Note: calling the generated php function 'might' be slow: a new
2025         xmlrpc client is created on every invocation and an xmlrpc-connection
2026         opened+closed. An extra 'debug' param is appended to the parameter
2027         list of the generated php function, useful for debugging
2028         purposes.
2029
2030 Example usage:
2031
2032
2033 [source, php]
2034 ----
2035
2036 $c = new xmlrpc_client('http://phpxmlrpc.sourceforge.net/server.php');
2037
2038 $function = wrap_xmlrpc_method($client, 'examples.getStateName');
2039
2040 if (!$function)
2041   die('Cannot introspect remote method');
2042 else {
2043   $stateno = 15;
2044   $statename = $function($a);
2045   if (is_a($statename, 'xmlrpcresp')) // call failed
2046   {
2047     echo 'Call failed: '.$statename->faultCode().'. Calling again with debug on';
2048     $function($a, true);
2049   }
2050   else
2051     echo "OK, state nr. $stateno is $statename";
2052 }
2053
2054 ----
2055
2056 [[wrap_php_function]]
2057
2058 ==== wrap_php_function
2059
2060 arraywrap_php_functionstring$funcnamestring$wrapper_function_namearray$extra_optionsGiven a user-defined PHP function, create a PHP 'wrapper'
2061         function that can be exposed as xmlrpc method from an xmlrpc_server
2062         object and called from remote clients, and return the appropriate
2063         definition to be added to a server's dispatch map.
2064
2065 The optional $wrapper_function_name
2066         specifies the name that will be used for the auto-generated
2067         function.
2068
2069 Since php is a typeless language, to infer types of input and
2070         output parameters, it relies on parsing the javadoc-style comment
2071         block associated with the given function. Usage of xmlrpc native types
2072         (such as datetime.dateTime.iso8601 and base64) in the docblock @param
2073         tag is also allowed, if you need the php function to receive/send data
2074         in that particular format (note that base64 encoding/decoding is
2075         transparently carried out by the lib, while datetime vals are passed
2076         around as strings).
2077
2078 Known limitations: only works for
2079         user-defined functions, not for PHP internal functions (reflection
2080         does not support retrieving number/type of params for those); the
2081         wrapped php function will not be able to programmatically return an
2082         xmlrpc error response.
2083
2084 If the ++$$return_source$$++ optional parameter is
2085         set, the function will return the php source code to build the wrapper
2086         function, instead of evaluating it (useful to save the code and use it
2087         later in a stand-alone xmlrpc server). It will be in the stored in the
2088         ++source++ member of the returned array.
2089
2090 If the ++$$suppress_warnings$$++ optional parameter
2091         is set, any runtime warning generated while processing the
2092         user-defined php function will be catched and not be printed in the
2093         generated xml response.
2094
2095 If the extra_options array contains the
2096         ++$$encode_php_objs$$++ value, wrapped functions returning
2097         php objects will generate "special" xmlrpc responses: when the xmlrpc
2098         decoding of those responses is carried out by this same lib, using the
2099         appropriate param in php_xmlrpc_decode(), the objects will be
2100         rebuilt.
2101
2102 In short: php objects can be serialized, too (except for their
2103         resource members), using this function. Other libs might choke on the
2104         very same xml that will be generated in this case (i.e. it has a
2105         nonstandard attribute on struct element tags)
2106
2107 If the ++$$decode_php_objs$$++ optional parameter is
2108         set, instances of php objects that have been appropriately encoded by
2109         the client using a coordinate option will be deserialized and passed
2110         to the user function as php objects instead of simple arrays (the same
2111         class definition should be present server side and client
2112         side).
2113
2114 __Note that this might pose a security risk__,
2115         since in order to rebuild the object instances their constructor
2116         method has to be invoked, and this means that the remote client can
2117         trigger execution of unforeseen php code on the server: not really a
2118         code injection, but almost. Please enable this option only when you
2119         trust the remote clients.
2120
2121 Example usage:
2122
2123
2124 [source, php]
2125 ----
2126 /**
2127 * State name from state number decoder. NB: do NOT remove this comment block.
2128 * @param integer $stateno the state number
2129 * @return string the name of the state (or error description)
2130 */
2131 function findstate($stateno)
2132 {
2133   global $stateNames;
2134   if (isset($stateNames[$stateno-1]))
2135   {
2136     return $stateNames[$stateno-1];
2137   }
2138   else
2139   {
2140     return "I don't have a state for the index '" . $stateno . "'";
2141   }
2142 }
2143
2144 // wrap php function, build xmlrpc server
2145 $methods = array();
2146 $findstate_sig = wrap_php_function('findstate');
2147 if ($findstate_sig)
2148   $methods['examples.getStateName'] = $findstate_sig;
2149 $srv = new xmlrpc_server($methods);
2150
2151 ----
2152
2153 [[deprecated]]
2154
2155 === Functions removed from the library
2156
2157 The following two functions have been deprecated in version 1.1 of
2158       the library, and removed in version 2, in order to avoid conflicts with
2159       the EPI xml-rpc library, which also defines two functions with the same
2160       names.
2161
2162 To ease the transition to the new naming scheme and avoid breaking
2163       existing implementations, the following scheme has been adopted:
2164
2165 * If EPI-XMLRPC is not active in the current PHP installation,
2166             the constant ++$$XMLRPC_EPI_ENABLED$$++ will be set to
2167             ++$$'0'$$++
2168
2169
2170 * If EPI-XMLRPC is active in the current PHP installation, the
2171             constant ++$$XMLRPC_EPI_ENABLED$$++ will be set to
2172             ++$$'1'$$++
2173
2174
2175
2176 The following documentation is kept for historical
2177       reference:
2178
2179 [[xmlrpcdecode]]
2180
2181 ==== xmlrpc_decode
2182
2183 mixedx mlrpc_decode xmlrpcval $xmlrpc_val Alias for php_xmlrpc_decode.
2184
2185 [[xmlrpcencode]]
2186
2187 ==== xmlrpc_encode
2188
2189 xmlrpcval xmlrpc_encode mixed $phpvalAlias for php_xmlrpc_encode.
2190
2191 [[debugging]]
2192
2193 === Debugging aids
2194
2195 ==== xmlrpc_debugmsg
2196
2197 void xmlrpc_debugmsgstring$debugstringSends the contents of $debugstring in XML
2198         comments in the server return payload. If a PHP client has debugging
2199         turned on, the user will be able to see server debug
2200         information.
2201
2202 Use this function in your methods so you can pass back
2203         diagnostic information. It is only available from
2204         __xmlrpcs.inc__.
2205
2206
2207 [[reserved]]
2208
2209 == Reserved methods
2210
2211 In order to extend the functionality offered by XML-RPC servers
2212     without impacting on the protocol, reserved methods are supported in this
2213     release.
2214
2215 All methods starting with system. are
2216     considered reserved by the server. PHP for XML-RPC itself provides four
2217     special methods, detailed in this chapter.
2218
2219 Note that all server objects will automatically respond to clients
2220     querying these methods, unless the property
2221     allow_system_funcs has been set to
2222     false before calling the
2223     service() method. This might pose a security risk
2224     if the server is exposed to public access, e.g. on the internet.
2225
2226
2227 === system.getCapabilities
2228
2229
2230 === system.listMethods
2231
2232 This method may be used to enumerate the methods implemented by
2233       the XML-RPC server.
2234
2235 The system.listMethods method requires no
2236       parameters. It returns an array of strings, each of which is the name of
2237       a method implemented by the server.
2238
2239 [[sysmethodsig]]
2240
2241 === system.methodSignature
2242
2243 This method takes one parameter, the name of a method implemented
2244       by the XML-RPC server.
2245
2246 It returns an array of possible signatures for this method. A
2247       signature is an array of types. The first of these types is the return
2248       type of the method, the rest are parameters.
2249
2250 Multiple signatures (i.e. overloading) are permitted: this is the
2251       reason that an array of signatures are returned by this method.
2252
2253 Signatures themselves are restricted to the top level parameters
2254       expected by a method. For instance if a method expects one array of
2255       structs as a parameter, and it returns a string, its signature is simply
2256       "string, array". If it expects three integers, its signature is "string,
2257       int, int, int".
2258
2259 For parameters that can be of more than one type, the "undefined"
2260       string is supported.
2261
2262 If no signature is defined for the method, a not-array value is
2263       returned. Therefore this is the way to test for a non-signature, if
2264       $resp below is the response object from a method
2265       call to system.methodSignature:
2266
2267 [source, php]
2268 ----
2269
2270 $v = $resp->value();
2271 if ($v->kindOf() != "array") {
2272   // then the method did not have a signature defined
2273 }
2274
2275 ----
2276
2277 See the __introspect.php__ demo included in this
2278       distribution for an example of using this method.
2279
2280 [[sysmethhelp]]
2281
2282 === system.methodHelp
2283
2284 This method takes one parameter, the name of a method implemented
2285       by the XML-RPC server.
2286
2287 It returns a documentation string describing the use of that
2288       method. If no such string is available, an empty string is
2289       returned.
2290
2291 The documentation string may contain HTML markup.
2292
2293 === system.multicall
2294
2295 This method takes one parameter, an array of 'request' struct
2296       types. Each request struct must contain a
2297       methodName member of type string and a
2298       params member of type array, and corresponds to
2299       the invocation of the corresponding method.
2300
2301 It returns a response of type array, with each value of the array
2302       being either an error struct (containing the faultCode and faultString
2303       members) or the successful response value of the corresponding single
2304       method call.
2305
2306
2307 [[examples]]
2308
2309 == Examples
2310
2311 The best examples are to be found in the sample files included with
2312     the distribution. Some are included here.
2313
2314 [[statename]]
2315
2316 === XML-RPC client: state name query
2317
2318 Code to get the corresponding state name from a number (1-50) from
2319       the demo server available on SourceForge
2320
2321 [source, php]
2322 ----
2323
2324   $m = new xmlrpcmsg('examples.getStateName',
2325     array(new xmlrpcval($HTTP_POST_VARS["stateno"], "int")));
2326   $c = new xmlrpc_client("/server.php", "phpxmlrpc.sourceforge.net", 80);
2327   $r = $c->send($m);
2328   if (!$r->faultCode()) {
2329       $v = $r->value();
2330       print "State number " . htmlentities($HTTP_POST_VARS["stateno"]) . " is " .
2331         htmlentities($v->scalarval()) . "<BR>";
2332       print "<HR>I got this value back<BR><PRE>" .
2333         htmlentities($r->serialize()) . "</PRE><HR>\n";
2334   } else {
2335       print "Fault <BR>";
2336       print "Code: " . htmlentities($r->faultCode()) . "<BR>" .
2337             "Reason: '" . htmlentities($r->faultString()) . "'<BR>";
2338   }
2339
2340 ----
2341
2342 === Executing a multicall call
2343
2344 To be documented...
2345
2346
2347 [[faq]]
2348
2349 [qanda]
2350 == Frequently Asked Questions
2351
2352 === Hi
2353
2354 ==== How to send custom XML as payload of a method call::
2355
2356 Unfortunately, at the time the XML-RPC spec was designed, support
2357       for namespaces in XML was not as ubiquitous as it is now. As a
2358       consequence, no support was provided in the protocol for embedding XML
2359       elements from other namespaces into an xmlrpc request.
2360
2361 To send an XML "chunk" as payload of a method call or response,
2362       two options are available: either send the complete XML block as a
2363       string xmlrpc value, or as a base64 value. Since the '&lt;' character in
2364       string values is encoded as '&amp;lt;' in the xml payload of the method
2365       call, the XML string will not break the surrounding xmlrpc, unless
2366       characters outside of the assumed character set are used. The second
2367       method has the added benefits of working independently of the charset
2368       encoding used for the xml to be transmitted, and preserving exactly
2369       whitespace, whilst incurring in some extra message length and cpu load
2370       (for carrying out the base64 encoding/decoding).
2371
2372
2373 ==== Is there any limitation on the size of the requests / responses that can be successfully sent?::
2374
2375 Yes. But I have no hard figure to give; it most likely will depend
2376       on the version of PHP in usage and its configuration.
2377
2378 Keep in mind that this library is not optimized for speed nor for
2379       memory usage. Better alternatives exist when there are strict
2380       requirements on throughput or resource usage, such as the php native
2381       xmlrpc extension (see the PHP manual for more information).
2382
2383 Keep in mind also that HTTP is probably not the best choice in
2384       such a situation, and XML is a deadly enemy. CSV formatted data over
2385       socket would be much more efficient.
2386
2387 If you really need to move a massive amount of data around, and
2388       you are crazy enough to do it using phpxmlrpc, your best bet is to
2389       bypass usage of the xmlrpcval objects, at least in the decoding phase,
2390       and have the server (or client) object return to the calling function
2391       directly php values (see xmlrpc_client::return_type
2392       and xmlrpc_server::functions_parameters_type for more
2393       details).
2394
2395
2396 ==== My server (client) returns an error whenever the client (server) returns accented characters
2397
2398 To be documented...
2399
2400
2401 ==== How to enable long-lasting method calls
2402
2403 To be documented...
2404
2405
2406 ==== My client returns "XML-RPC Fault #2: Invalid return payload: enable debugging to examine incoming payload": what should I do?
2407
2408 The response you are seeing is a default error response that the
2409       client object returns to the php application when the server did not
2410       respond to the call with a valid xmlrpc response.
2411
2412 The most likely cause is that you are not using the correct URL
2413       when creating the client object, or you do not have appropriate access
2414       rights to the web page you are requesting, or some other common http
2415       misconfiguration.
2416
2417 To find out what the server is really returning to your client,
2418       you have to enable the debug mode of the client, using
2419       $client-&gt;setdebug(1);
2420
2421
2422 ==== How can I save to a file the xml of the xmlrpc responses received from servers?
2423
2424 If what you need is to save the responses received from the server
2425       as xml, you have two options:
2426
2427 1- use the serialize() method on the response object.
2428
2429
2430 [source, php]
2431 ----
2432
2433 $resp = $client->send($msg);
2434 if (!$resp->faultCode())
2435   $data_to_be_saved = $resp->serialize();
2436
2437 ----
2438
2439 Note that this will not be 100% accurate, since the xml generated
2440       by the response object can be different from the xml received,
2441       especially if there is some character set conversion involved, or such
2442       (eg. if you receive an empty string tag as &lt;string/&gt;, serialize()
2443       will output &lt;string&gt;&lt;/string&gt;), or if the server sent back
2444       as response something invalid (in which case the xml generated client
2445       side using serialize() will correspond to the error response generated
2446       internally by the lib).
2447
2448 2 - set the client object to return the raw xml received instead
2449       of the decoded objects:
2450
2451
2452 [source, php]
2453 ----
2454
2455 $client = new xmlrpc_client($url);
2456 $client->return_type = 'xml';
2457 $resp = $client->send($msg);
2458 if (!$resp->faultCode())
2459   $data_to_be_saved = $resp->value();
2460
2461 ----
2462
2463 Note that using this method the xml response response will not be
2464       parsed at all by the library, only the http communication protocol will
2465       be checked. This means that xmlrpc responses sent by the server that
2466       would have generated an error response on the client (eg. malformed xml,
2467       responses that have faultcode set, etc...) now will not be flagged as
2468       invalid, and you might end up saving not valid xml but random
2469       junk...
2470
2471
2472 ==== Can I use the ms windows character set?
2473
2474 If the data your application is using comes from a Microsoft
2475       application, there are some chances that the character set used to
2476       encode it is CP1252 (the same might apply to data received from an
2477       external xmlrpc server/client, but it is quite rare to find xmlrpc
2478       toolkits that encode to CP1252 instead of UTF8). It is a character set
2479       which is "almost" compatible with ISO 8859-1, but for a few extra
2480       characters.
2481
2482 PHP-XMLRPC only supports the ISO 8859-1 and UTF8 character sets.
2483       The net result of this situation is that those extra characters will not
2484       be properly encoded, and will be received at the other end of the
2485       XML-RPC transmission as "garbled data". Unfortunately the library cannot
2486       provide real support for CP1252 because of limitations in the PHP 4 xml
2487       parser. Luckily, we tried our best to support this character set anyway,
2488       and, since version 2.2.1, there is some form of support, left commented
2489       in the code.
2490
2491 To properly encode outgoing data that is natively in CP1252, you
2492       will have to uncomment all relative code in the file
2493       __xmlrpc.inc__ (you can search for the string "1252"),
2494       then set ++$$$GLOBALS['xmlrpc_internalencoding']='CP1252';$$++
2495       Please note that all incoming data will then be fed to your application
2496       as UTF-8 to avoid any potential data loss.
2497
2498
2499 ==== Does the library support using cookies / http sessions?
2500
2501 In short: yes, but a little coding is needed to make it
2502       happen.
2503
2504 The code below uses sessions to e.g. let the client store a value
2505       on the server and retrieve it later.
2506
2507 [source, php]
2508 ----
2509
2510 $resp = $client->send(new xmlrpcmsg('registervalue', array(new xmlrpcval('foo'), new xmlrpcval('bar'))));
2511 if (!$resp->faultCode())
2512 {
2513   $cookies = $resp->cookies();
2514   if (array_key_exists('PHPSESSID', $cookies)) // nb: make sure to use the correct session cookie name
2515   {
2516     $session_id = $cookies['PHPSESSID']['value'];
2517
2518     // do some other stuff here...
2519
2520     $client->setcookie('PHPSESSID', $session_id);
2521     $val = $client->send(new xmlrpcmsg('getvalue', array(new xmlrpcval('foo')));
2522   }
2523 }
2524
2525 ----
2526
2527 Server-side sessions are handled normally like in any other
2528       php application. Please see the php manual for more information about
2529       sessions.
2530
2531 NB: unlike web browsers, not all xmlrpc clients support usage of
2532       http cookies. If you have troubles with sessions and control only the
2533       server side of the communication, please check with the makers of the
2534       xmlrpc client in use.
2535
2536
2537 [[integration]]
2538
2539 [appendix]
2540 == Integration with the PHP xmlrpc extension
2541
2542 To be documented more...
2543
2544 In short: for the fastest execution possible, you can enable the php
2545     native xmlrpc extension, and use it in conjunction with phpxmlrpc. The
2546     following code snippet gives an example of such integration
2547
2548
2549 [source, php]
2550 ----
2551
2552 /*** client side ***/
2553 $c = new xmlrpc_client('http://phpxmlrpc.sourceforge.net/server.php');
2554
2555 // tell the client to return raw xml as response value
2556 $c->return_type = 'xml';
2557
2558 // let the native xmlrpc extension take care of encoding request parameters
2559 $r = $c->send(xmlrpc_encode_request('examples.getStateName', $_POST['stateno']));
2560
2561 if ($r->faultCode())
2562   // HTTP transport error
2563   echo 'Got error '.$r->faultCode();
2564 else
2565 {
2566   // HTTP request OK, but XML returned from server not parsed yet
2567   $v = xmlrpc_decode($r->value());
2568   // check if we got a valid xmlrpc response from server
2569   if ($v === NULL)
2570     echo 'Got invalid response';
2571   else
2572   // check if server sent a fault response
2573   if (xmlrpc_is_fault($v))
2574     echo 'Got xmlrpc fault '.$v['faultCode'];
2575   else
2576     echo'Got response: '.htmlentities($v);
2577 }
2578
2579 ----
2580
2581
2582 [[substitution]]
2583
2584 [appendix]
2585 == Substitution of the PHP xmlrpc extension
2586
2587 Yet another interesting situation is when you are using a ready-made
2588     php application, that provides support for the XMLRPC protocol via the
2589     native php xmlrpc extension, but the extension is not available on your
2590     php install (e.g. because of shared hosting constraints).
2591
2592 Since version 2.1, the PHP-XMLRPC library provides a compatibility
2593     layer that aims to be 100% compliant with the xmlrpc extension API. This
2594     means that any code written to run on the extension should obtain the
2595     exact same results, albeit using more resources and a longer processing
2596     time, using the PHP-XMLRPC library and the extension compatibility module.
2597     The module is part of the EXTRAS package, available as a separate download
2598     from the sourceforge.net website, since version 0.2
2599
2600
2601 [[enough]]
2602
2603 [appendix]
2604 == 'Enough of xmlrpcvals!': new style library usage
2605
2606 To be documented...
2607
2608 In the meantime, see docs about xmlrpc_client::return_type and
2609     xmlrpc_server::functions_parameters_types, as well as php_xmlrpc_encode,
2610     php_xmlrpc_decode and php_xmlrpc_decode_xml
2611
2612
2613 [[debugger]]
2614
2615 [appendix]
2616 == Usage of the debugger
2617
2618 A webservice debugger is included in the library to help during
2619     development and testing.
2620
2621 The interface should be self-explicative enough to need little
2622     documentation.
2623
2624 image::debugger.gif[,,,,align="center"]
2625
2626 The most useful feature of the debugger is without doubt the "Show
2627     debug info" option. It allows to have a screen dump of the complete http
2628     communication between client and server, including the http headers as
2629     well as the request and response payloads, and is invaluable when
2630     troubleshooting problems with charset encoding, authentication or http
2631     compression.
2632
2633 The debugger can take advantage of the JSONRPC library extension, to
2634     allow debugging of JSON-RPC webservices, and of the JS-XMLRPC library
2635     visual editor to allow easy mouse-driven construction of the payload for
2636     remote methods. Both components have to be downloaded separately from the
2637     sourceforge.net web pages and copied to the debugger directory to enable
2638     the extra functionality:
2639
2640
2641 * to enable jsonrpc functionality, download the PHP-XMLRPC
2642           EXTRAS package, and copy the file __jsonrpc.inc__
2643           either to the same directory as the debugger or somewhere in your
2644           php include path
2645
2646
2647 * to enable the visual value editing dialog, download the
2648           JS-XMLRPC library, and copy somewhere in the web root files
2649           __visualeditor.php__,
2650           __visualeditor.css__ and the folders
2651           __yui__ and __img__. Then edit the
2652           debugger file __controller.php__ and set
2653           appropriately the variable $editorpath.
2654
2655
2656 [[news]]
2657
2658 [appendix]
2659 == Whats's new
2660
2661 __Note:__ not all items the following list have
2662     (yet) been fully documented, and some might not be present in any other
2663     chapter in the manual. To find a more detailed description of new
2664     functions and methods please take a look at the source code of the
2665     library, which is quite thoroughly commented in phpdoc form.
2666
2667 === 4.0.0
2668
2669 ...to be documented...
2670
2671 === 3.0.0
2672
2673 __Note:__ this is the last release of the library that will support PHP 5.1 and up.
2674       Future releases will target php 5.3 as minimum supported version.
2675
2676 * when using curl and keepalive, reset curl handle if we did not get back an http 200 response (eg a 302)
2677
2678 * omit port on http 'Host' header if it is 80
2679
2680 * test suite allows interrogating https servers ignoring their certs
2681
2682 * method setAcceptedCompression was failing to disable reception of compressed responses if the
2683          client supported them
2684
2685 === 3.0.0 beta
2686
2687 This is the first release of the library to only support PHP 5.
2688       Some legacy code has been removed, and support for features such as
2689       exceptions and dateTime objects introduced.
2690
2691 The "beta" tag is meant to indicate the fact that the refactoring
2692       has been more widespread than in precedent releases and that more
2693       changes are likely to be introduced with time - the library is still
2694       considered to be production quality.
2695
2696 * improved: removed all usage of php functions deprecated in
2697             php 5.3, usage of assign-by-ref when creating new objects
2698             etc...
2699
2700 * improved: add support for the &lt;ex:nil/&gt; tag used by
2701             the apache library, both in input and output
2702
2703 * improved: add support for dateTime
2704             objects in both in php_xmlrpc_encode and as
2705             parameter for constructor of
2706             xmlrpcval
2707
2708 * improved: add support for timestamps as parameter for
2709             constructor of xmlrpcval
2710
2711 * improved: add option 'dates_as_objects' to
2712             php_xmlrpc_decode to return
2713             dateTime objects for xmlrpc
2714             datetimes
2715
2716 * improved: add new method
2717             SetCurlOptions to
2718             xmrlpc_client to allow extra flexibility in
2719             tweaking http config, such as explicitly binding to an ip
2720             address
2721
2722 * improved: add new method
2723             SetUserAgent to
2724             xmrlpc_client to to allow having different
2725             user-agent http headers
2726
2727 * improved: add a new member variable in server class to allow
2728             fine-tuning of the encoding of returned values when the server is
2729             in 'phpvals' mode
2730
2731 * improved: allow servers in 'xmlrpcvals' mode to also
2732             register plain php functions by defining them in the dispatch map
2733             with an added option
2734
2735 * improved: catch exceptions thrown during execution of php
2736             functions exposed as methods by the server
2737
2738 * fixed: bad encoding if same object is encoded twice using
2739             php_xmlrpc_encode
2740
2741 === 2.2.2
2742
2743 __Note:__ this is the last release of the
2744       library that will support PHP 4. Future releases (if any) should target
2745       php 5.0 as minimum supported version.
2746
2747 * fixed: encoding of utf-8 characters outside of the BMP
2748             plane
2749
2750 * fixed: character set declarations surrounded by double
2751             quotes were not recognized in http headers
2752
2753 * fixed: be more tolerant in detection of charset in http
2754             headers
2755
2756 * fixed: fix detection of zlib.output_compression
2757
2758 * fixed: use feof() to test if socket connections are to be
2759             closed instead of the number of bytes read (rare bug when
2760             communicating with some servers)
2761
2762 * fixed: format floating point values using the correct
2763             decimal separator even when php locale is set to one that uses
2764             comma
2765
2766 * fixed: improve robustness of the debugger when parsing weird
2767             results from non-compliant servers
2768
2769 * php warning when receiving 'false' in a bool value
2770
2771 * improved: allow the add_to_map server method to add docs for
2772             single params too
2773
2774 * improved: added the possibility to wrap for exposure as
2775             xmlrpc methods plain php class methods, object methods and even
2776             whole classes
2777
2778 === 2.2.1
2779
2780 * fixed: work aroung bug in php 5.2.2 which broke support of
2781           HTTP_RAW_POST_DATA
2782
2783 * fixed: is_dir parameter of setCaCertificate() method is
2784           reversed
2785
2786 * fixed: a php warning in xmlrpc_client creator method
2787
2788 * fixed: parsing of '1e+1' as valid float
2789
2790 * fixed: allow errorlevel 3 to work when prev. error handler was
2791           a static method
2792
2793 * fixed: usage of client::setcookie() for multiple cookies in
2794           non-ssl mode
2795
2796 * improved: support for CP1252 charset is not part or the
2797           library but almost possible
2798
2799 * improved: more info when curl is enabled and debug mode is
2800           on
2801 === 2.2
2802
2803 * fixed: debugger errors on php installs with magic_quotes_gpc
2804           on
2805
2806 * fixed: support for https connections via proxy
2807
2808 * fixed: wrap_xmlrpc_method() generated code failed to properly
2809           encode php objects
2810
2811 * improved: slightly faster encoding of data which is internally
2812           UTF-8
2813
2814 * improved: debugger always generates a 'null' id for jsonrpc if
2815           user omits it
2816
2817 * new: debugger can take advantage of a graphical value builder
2818           (it has to be downloaded separately, as part of jsxmlrpc package.
2819           See Appendix D for more details)
2820
2821 * new: support for the &lt;NIL/&gt; xmlrpc extension. see below
2822           for more details
2823
2824 * new: server support for the system.getCapabilities xmlrpc
2825           extension
2826
2827 * new: <<wrap_xmlrpc_method,wrap_xmlrpc_method()>>
2828           accepts two new options: debug and return_on_fault
2829
2830 === 2.1
2831
2832 * The wrap_php_function and
2833             wrap_xmlrpc_method functions have been moved
2834             out of the base library file __xmlrpc.inc__ into
2835             a file of their own: __$$xmlrpc_wrappers.php$$__. You
2836             will have to include() / require() it in your scripts if you have
2837             been using those functions. For increased security, the automatic
2838             rebuilding of php object instances out of received xmlrpc structs
2839             in wrap_xmlrpc_method() has been disabled
2840             (but it can be optionally re-enabled). Both
2841             wrap_php_function() and
2842             wrap_xmlrpc_method() functions accept many
2843             more options to fine tune their behaviour, including one to return
2844             the php code to be saved and later used as standalone php
2845             script
2846
2847 * The constructor of xmlrpcval() values has seen some internal
2848             changes, and it will not throw a php warning anymore when invoked
2849             using an unknown xmlrpc type: the error will only be written to
2850             php error log. Also ++$$new xmlrpcval('true', 'boolean')$$++
2851             is not supported anymore
2852
2853 * The new function
2854             php_xmlrpc_decode_xml() will take the xml
2855             representation of either an xmlrpc request, response or single
2856             value and return the corresponding php-xmlrpc object
2857             instance
2858
2859 * A new function wrap_xmlrpc_server()has
2860             been added, to wrap all (or some) of the methods exposed by a
2861             remote xmlrpc server into a php class
2862
2863 * A new file has been added:
2864             __$$verify_compat.php$$__, to help users diagnose the
2865             level of compliance of their php installation with the
2866             library
2867
2868 * Restored compatibility with php 4.0.5 (for those poor souls
2869             still stuck on it)
2870
2871 * Method xmlrpc_server-&gt;service()
2872             now returns a value: either the response payload or xmlrpcresp
2873             object instance
2874
2875 * Method
2876             xmlrpc_server-&gt;add_to_map() now
2877             accepts xmlrpc methods with no param definitions
2878
2879 * Documentation for single parameters of exposed methods can
2880             be added to the dispatch map (and turned into html docs in
2881             conjunction with a future release of the 'extras' package)
2882
2883 * Full response payload is saved into xmlrpcresp object for
2884             further debugging
2885
2886 * The debugger can now generate code that wraps a remote
2887             method into a php function (works for jsonrpc, too); it also has
2888             better support for being activated via a single GET call (e.g. for
2889             integration into other tools)
2890
2891 * Stricter parsing of incoming xmlrpc messages: two more
2892             invalid cases are now detected (double ++data++
2893             element inside ++array++ and
2894             ++struct++/++array++ after scalar
2895             inside ++value++ element)
2896
2897 * More logging of errors in a lot of situations
2898
2899 * Javadoc documentation of lib files (almost) complete
2900
2901 * Many performance tweaks and code cleanups, plus the usual
2902             crop of bugs fixed (see NEWS file for complete list of
2903             bugs)
2904
2905 * Lib internals have been modified to provide better support
2906             for grafting extra functionality on top of it. Stay tuned for
2907             future releases of the EXTRAS package (or go read Appendix
2908             B)...
2909
2910 === 2.0 final
2911
2912 * Added to the client class the possibility to use Digest and
2913             NTLM authentication methods (when using the CURL library) for
2914             connecting to servers and NTLM for connecting to proxies
2915
2916 * Added to the client class the possibility to specify
2917             alternate certificate files/directories for authenticating the
2918             peer with when using HTTPS communication
2919
2920 * Reviewed all examples and added a new demo file, containing
2921             a proxy to forward xmlrpc requests to other servers (useful e.g.
2922             for ajax coding)
2923
2924 * The debugger has been upgraded to reflect the new client
2925             capabilities
2926
2927 * All known bugs have been squashed, and the lib is more
2928             tolerant than ever of commonly-found mistakes
2929
2930 === 2.0 Release candidate 3
2931
2932 * Added to server class the property
2933             functions_parameters_type, that allows the
2934             server to register plain php functions as xmlrpc methods (i.e.
2935             functions that do not take an xmlrpcmsg object as unique
2936             param)
2937
2938 * let server and client objects serialize calls using a
2939             specified character set encoding for the produced xml instead of
2940             US-ASCII (ISO-8859-1 and UTF-8 supported)
2941
2942 * let php_xmlrpc_decode accept xmlrpcmsg objects as valid
2943             input
2944
2945 * 'class::method' syntax is now accepted in the server
2946             dispatch map
2947
2948 * xmlrpc_clent::SetDebug() accepts
2949             integer values instead of a boolean value, with debugging level 2
2950             adding to the information printed to screen the complete client
2951             request
2952
2953 === 2.0 Release candidate 2
2954
2955 * Added a new property of the client object:
2956             ++$$xmlrpc_client-&gt;return_type$$++, indicating whether
2957             calls to the send() method will return xmlrpcresp objects whose
2958             value() is an xmlrpcval object, a php value (automatically
2959             decoded) or the raw xml received from the server.
2960
2961 * Added in the extras dir. two new library file:
2962             __jsonrpc.inc__ and
2963             __jsonrpcs.inc__ containing new classes that
2964             implement support for the json-rpc protocol (alpha quality
2965             code)
2966
2967 * Added a new client method: ++setKey($key,
2968             $keypass)++ to be used in HTTPS connections
2969
2970 * Added a new file containing some benchmarks in the testsuite
2971             directory
2972
2973 === 2.0 Release candidate 1
2974
2975 * Support for HTTP proxies (new method:
2976           ++$$xmlrpc_client::setProxy()$$++)
2977
2978 * Support HTTP compression of both requests and responses.
2979           Clients can specify what kind of compression they accept for
2980           responses between deflate/gzip/any, and whether to compress the
2981           requests. Servers by default compress responses to clients that
2982           explicitly declare support for compression (new methods:
2983           ++$$xmlrpc_client::setAcceptedCompression()$$++,
2984           ++$$xmlrpc_client::setRequestCompression()$$++). Note that the
2985           ZLIB php extension needs to be enabled in PHP to support
2986           compression.
2987
2988 * Implement HTTP 1.1 connections, but only if CURL is enabled
2989           (added an extra parameter to
2990           ++$$xmlrpc_client::xmlrpc_client$$++ to set the desired HTTP
2991           protocol at creation time and a new supported value for the last
2992           parameter of ++$$xmlrpc_client::send$$++, which now can be
2993           safely omitted if it has been specified at creation time)
2994 +
2995 With PHP versions greater than 4.3.8 keep-alives are enabled
2996           by default for HTTP 1.1 connections. This should yield faster
2997           execution times when making multiple calls in sequence to the same
2998           xml-rpc server from a single client.
2999
3000 * Introduce support for cookies. Cookies to be sent to the
3001           server with a request can be set using
3002           ++$$xmlrpc_client::setCookie()$$++, while cookies received from
3003           the server are found in ++xmlrpcresp::cookies()++. It is
3004           left to the user to check for validity of received cookies and
3005           decide whether they apply to successive calls or not.
3006
3007 * Better support for detecting different character set encodings
3008           of xml-rpc requests and responses: both client and server objects
3009           will correctly detect the charset encoding of received xml, and use
3010           an appropriate xml parser.
3011 +
3012 Supported encodings are US-ASCII, UTF-8 and ISO-8859-1.
3013
3014 * Added one new xmlrpcmsg constructor syntax, allowing usage of
3015           a single string with the complete URL of the target server
3016
3017 * Convert xml-rpc boolean values into native php values instead
3018           of 0 and 1
3019
3020 * Force the ++$$php_xmlrpc_encode$$++ function to properly
3021           encode numerically indexed php arrays into xml-rpc arrays
3022           (numerically indexed php arrays always start with a key of 0 and
3023           increment keys by values of 1)
3024
3025 * Prevent the ++$$php_xmlrpc_encode$$++ function from
3026           further re-encoding any objects of class ++xmlrpcval++ that
3027           are passed to it. This allows to call the function with arguments
3028           consisting of mixed php values / xmlrpcval objects.
3029
3030 * Allow a server to NOT respond to system.* method calls
3031           (setting the ++$$$server-&gt;allow_system_funcs$$++
3032           property).
3033
3034 * Implement a new xmlrpcval method to determine if a value of
3035           type struct has a member of a given name without having to loop
3036           trough all members: ++xmlrpcval::structMemExists()++
3037
3038 * Expand methods ++xmlrpcval::addArray++,
3039           ++addScalar++ and ++addStruct++ allowing extra php
3040           values to be added to xmlrpcval objects already formed.
3041
3042 * Let the ++$$xmlrpc_client::send$$++ method accept an XML
3043           string for sending instead of an xmlrpcmsg object, to facilitate
3044           debugging and integration with the php native xmlrpc
3045           extension
3046
3047 * Extend the ++$$php_xmlrpc_encode$$++ and
3048           ++$$php_xmlrpc_decode$$++ functions to allow serialization and
3049           rebuilding of PHP objects. To successfully rebuild a serialized
3050           object, the object class must be defined in the deserializing end of
3051           the transfer. Note that object members of type resource will be
3052           deserialized as NULL values.
3053 +
3054 Note that his has been implemented adding a "php_class"
3055           attribute to xml representation of xmlrpcval of STRUCT type, which,
3056           strictly speaking, breaks the xml-rpc spec. Other xmlrpc
3057           implementations are supposed to ignore such an attribute (unless
3058           they implement a brain-dead custom xml parser...), so it should be
3059           safe enabling it in heterogeneous environments. The activation of
3060           this feature is done by usage of an option passed as second
3061           parameter to both ++$$php_xmlrpc_encode$$++ and
3062           ++$$php_xmlrpc_decode$$++.
3063
3064 * Extend the ++$$php_xmlrpc_encode$$++ function to allow
3065           automatic serialization of iso8601-conforming php strings as
3066           datetime.iso8601 xmlrpcvals, by usage of an optional
3067           parameter
3068
3069 * Added an automatic stub code generator for converting xmlrpc
3070           methods to php functions and vice-versa.
3071 +
3072 This is done via two new functions:
3073           ++$$wrap_php_function$$++ and ++$$wrap_xmlrpc_method$$++,
3074           and has many caveats, with php being a typeless language and
3075           all...
3076
3077 * Allow object methods to be used in server dispatch map
3078
3079 * Added a complete debugger solution, in the
3080           __debugger__ folder
3081
3082 * Added configurable server-side debug messages, controlled by
3083           the new method ++$$xmlrpc_server::SetDebug()$$++. At level 0,
3084           no debug messages are sent to the client; level 1 is the same as the
3085           old behaviour; at level 2 a lot more info is echoed back to the
3086           client, regarding the received call; at level 3 all warnings raised
3087           during server processing are trapped (this prevents breaking the xml
3088           to be echoed back to the client) and added to the debug info sent
3089           back to the client
3090
3091 * New XML parsing code, yields smaller memory footprint and
3092           faster execution times, not to mention complete elimination of the
3093           dreaded __eval()__ construct, so prone to code
3094           injection exploits
3095
3096 * Rewritten most of the error messages, making text more
3097           explicative
3098
3099 ++++++++++++++++++++++++++++++++++++++
3100 <!-- Keep this comment at the end of the file
3101 Local variables:
3102 mode: sgml
3103 sgml-omittag:nil
3104 sgml-shorttag:t
3105 sgml-minimize-attributes:nil
3106 sgml-always-quote-attributes:t
3107 sgml-indent-step:2
3108 sgml-indent-data:t
3109 sgml-parent-document:nil
3110 sgml-exposed-tags:nil
3111 sgml-local-catalogs:nil
3112 sgml-local-ecat-files:nil
3113 sgml-namecase-general:t
3114 sgml-general-insert-case:lower
3115 End:
3116 -->
3117 ++++++++++++++++++++++++++++++++++++++