4.11.0

• new: added new Client option Client::OPT_EXTRA_HEADERS, useful to set custom HTTP headers

• improved: compatibility with not-yet-released PHP version 8.4

4.10.4

fixed: Response returned from the library in case of HttpException did not have set the correct status_code member var ( issue #119 )

4.10.3

• fixed: avoid emitting warnings when parsing some classes of malformed XML (issue #116)

• fixed: the library will now return a Fault Response object with error code 2 whenever parsing some xml responses
  which do not conform to the specification, namely those having both fault and params elements inside methodResponse

4.10.2

• fixed: allow Server subclasses to use their own Parser to determine the Request's charset

• fixed: the Server would not swallow and log php warnings generated from end user's method handler functions unless
  debug mode was set to 2 or higher. It now does that always.

• fixed: the library will now return a Fault Response object whenever parsing some xml responses which do not conform
  to the specification, namely the for following cases:

  • a methodResponse element without either fault or params
  • a methodResponse element with a params child which does not have a single param

• improved: test on php 8.3

4.10.1

• fixed: class autoloading got broken in rel 4.10.0 for users of the legacy API (issue #111)

• fixed: let the Server create Response objects whose class can be overridden by subclasses (this is required by the
  json-rpc server now that the xml_header method has been moved to the Request object)

• fixed: let the Client create Requests whose class can be overridden by subclasses, within the _try_multicall method,
  which is called from multicall

• fixed: declare the library not to be compatible with old versions of 'phpxmlrpc/extras' and 'phpxmlrpc/jsonrpc'

4.10.0

• changed: the minimum php version required has been increased to 5.4

• changed: dropped support for parsing cookie headers which follow the obsolete Cookie2 specification

• new: it is now possible to make the library generate warning messages whenever a deprecated feature is used, such as
  calling deprecated methods, using deprecated method parameters, or reading/writing deprecated object properties.
  This is disabled by default, and can be enabled by setting PhpXmlRpc\PhpXmlRpc::xmlrpc_silence_deprecations = false.
  Note that the deprecation warnings will be by default added to the php error log, and not be displayed on screen.
  If you prefer them to be handled in some other way, you should take over the Logger, as described below here

• new: allow to specify other charsets than the canonical three (UTF-8, ISO-8859-1, ASCII), when mbstring is
  available, both for outgoing and incoming data (issue #42).

  For outgoing data, this can be set in $client->request_charset_encoding and $server->response_charset_encoding.
  The library will then transcode the data fed to it by the application into the desired charset when serializing
  it for transmission.

  For incoming data, this can be set using PhpXmlRpc::$internal_encoding. The library will then transcode the data
  received from 3rd parties into the desired charset when handling it back to the application.

  An example of using this feature has been added to demo file windowscharset.php

• new: allow the library to pass to the application DateTime objects instead of string for all received dateTime.iso8601
  xml-rpc values. This includes both client-side, for data within the $response->value(), and server-side, for data
  passed to xml-rpc method handlers, and works for both 'xmlrpcvals' and 'phpvals' modes.
  In order to enable this, you should set PhpXmlRpc\PhpXmlRpc::$xmlrpc_return_datetimes = true.

  NB: since the xml-rpc spec mandates that no Timezone is used on the wire for dateTime values, the DateTime objects
  created by the library will be set to the default php timezone, set using the 'date.timezone' ini setting.

  NB: if the received strings are not parseable as dates, NULL will be returned instead of an object, but that can
  be avoided by setting PhpXmlRpc\PhpXmlRpc::$xmlrpc_reject_invalid_values = true, see below.

• improved: be more strict in the Response constructor and in Request::addParam: both of those will now generate
  an error message in the log if passed unexpected values

• improved: be more strict in the data accepted as valid for dateTime xml-rpc values. Clearly invalid dates such as a
  month '13', day '32' or hour '25' will cause an error message to be logged or the value to be rejected, depending
  on configuration

• improved: be more strict in the data accepted as valid for 'float' and 'int' xml-rpc values. If you need to allow
  different formats for numbers, you can set a custom value to PhpXmlRpc\PhpXmlRpc::$xmlrpc_double_format and
  PhpXmlRpc\PhpXmlRpc::$xmlrpc_int_format

• new: allow the library to be stricter in parsing the received xml: by setting
  PhpXmlRpc\PhpXmlRpc::$xmlrpc_reject_invalid_values = true, incoming xml which has data not conforming to the expected
  format for value elements of type date, int, float, double, base64 and methodname will be rejected instead of passed
  on to the application. The same will apply for elements of type struct-member which miss either the name or the value

• new: it is now possible to tell the library to allow non-standard formats for received datetime value, such as f.e.
  datetimes with a timezone specifier, by setting a custom value to PhpXmlRpc\PhpXmlRpc::$xmlrpc_datetime_format
  (issue #46).

• new: it is now possible to tell the library to allow non-standard formats for received int and float values, as well
  as for methdoname elements. See the api docs for PhpXmlRpc\PhpXmlRpc static variables.

• fixed: when a server is configured with its default value of 'xmlrpcvals' for $functions_parameters_type, and
  a method handler in the dispatch was defined with 'parameters_type' = 'phpvals', the handler would be passed a
  Request object instead of plain php values.

• fixed: made sure all debug output goes through the logger at response parsing time (there was one printf call left)

• fixed: Client::send will now return an error Response when it is requested to use an auth method that it does not
  support, instead of logging an error message and continuing with another auth schema. The returned error code is 20

• fixed: when calling Client::multicall() with $client->return_type = 'xml', the code would be always falling back to
  non-multicall requests

• fixed: support calling Client::setSSLVersion() for the case of not using curl transport

• fixed: receiving integers which use the 'EX:I8' xml tag

• fixed: setting/retrieving the php value from a Value object using array notation would fail if the object was created
  using i4 then accessed using int, eg: $v = new Value(1, 'i4'); $v[$v->scalrtyp()] = 2;

• fixed: setting values to deprecated Response property cookies would trigger a PHP notice, ex:
  $response->_cookies['name'] = ['value' => 'something']; (introduced in 4.6.0)

• fixed: made deprecated method Value::structEach work again with php 8.0 and later

• new: method PhpXmlRpc::useInteropFaults() can be used to make the library change the error codes it generates to
  match the spec described at https://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

• new: both Request and Response acquired methods getPayload and getContentType

• new: method Response::valueType()

• new: method Client::getUrl()

• new: method Server::setDispatchMap()

• new: added methods getOption, setOption, setOptions and getOptions to both Client and Server, meant to replace
  direct access to all public properties as well as the $timeout argument in calls to Client::send and Client::multicall

• new: by using Client::setOption('extracurlopts'), it is possible to pass in protocol=specific options for when
  using the Socket http transport. The value has to be an array with key being 'socket' or 'ssl', and the value an array
  (see https://www.php.net/manual/en/context.socket.php and https://www.php.net/manual/en/context.ssl.php)

• new: it is now possible to inject a custom logger into helper classes Charset, Http, XMLParser, inching a step
  closer to supporting DIC patterns (issue #78)

• new: method PhpXmlRpc::setLogger(), to simplify injecting a custom logger into all classes of the library in one step

• improved: the Client will automatically try to use cURL for requests using Digest/NTLM auth, unless told explicitly
  told not to do so via option 'use_curl'

• improved: the Client is more verbose in logging issues when trying to compress a Request for sending

• improved: the Logger class now sports methods adhering to Psr\Log\LoggerInterface

• improved: limit the size of incoming data which will be used in error responses and logged error messages, making
  it slightly harder to carry out DOS attacks against the library

• new: passing value -1 to $client->setDebug will avoid storing the full http response data in the returned Response
  object when executing call. This could be useful in reducing memory usage for big responses

• new: when calling Wrapper::wrapXmlrpcMethod and wrapXmlrpcServer, it is possible to pass 'throw_on_fault' as option
  to argument $extraOptions. This will make the generated function throw on http errors and xml-rpc faults instead of
  returning a Response object

• new: when calling Wrapper::wrapXmlrpcMethod, wrapXmlrpcServer, wrapPhpFunction and wrapPhpClass it is possible
  to pass 'encode_nulls' as option to argument $extraOptions. This will make the generated code emit a ''
  xml-rpc element for php null values, instead of emitting an empty-string xml-rpc element

• new: methods Wrapper::holdObject() and Wrapper::getheldObject(), allowing flexibility in storing object instances
  for code-generation scenarios involving Wrapper::wrapPhpClass and Wrapper::wrapPhpFunction

• improved: all Value methods now follow snakeCase convention

• improved: all the Exceptions thrown by the library are now \PhpXmlRpc\Exception or subclasses thereof

• improved: all the Client's setSomething() methods now return the client object, allowing for usage of fluent style
  calling. The same applies to Request::setDebug

• improved: when calling Client::multicall(), the returned Response objects did not have any data in their httpResponse

• new: method Helper\Date::iso8601Encode now accepts a DateTime input beside a timestamp

• new: in the dispatch map, it is now possible to set different exception handling modes for each exposed xml-rpc method

• new: method Server::add_to_map is deprecated in favour of addToMap. It has also acquired new parameters:
  $parametersType = false, $exceptionHandling = false

• improved: the XMLParser accepts more options in its constructor (see phpdocs for details)

• improved: removed usage of extension_loaded in favour of function_exists when checking for mbstring. This allows
  for mbstring functions to be polyfilled

• improved: the code generated by the various code-generating methods of Wrapper are formatted better, and include
  more phpdoc blocks too

• improved: made the Wrapper and Client classes easy to subclass for use by the PhpJsonRpc library

• improved: added the library version number to the debugger title line

• improved: the debugger will now sport the "load method synopsis" button when interacting with json-rpc servers

• improved: added an example Symfony Client and Server to the demo files (using Symfony 6 / PHP 8 syntax)

• improved: added to the taskfile command an option to automatically set up the git hooks for develop...

4.9.5

• improved: revised all demo files. Showcase more features in client demos; isolate better testsuite functions in server demos and make sure they are not active unless triggered by running the tests; add demos for code-generation for both clients and servers

• improved: added cli command taskfile, which can be used to download the demo files or the visualeditor component for the debugger (requires bash, curl and a smattering of other common unix/linux/macos? tools)

• improved: for php 7 and up, catch php Errors besides Exceptions thrown by method handler functions (ie. server-side)

• fixed: when using the Exception or Error thrown by a method handler function to build the xml-rpc response, override fault Code 0, as it breaks response serialization

4.9.4

• improved: updated the user's manual to be inline with the version4 API and modern coding practices.
  The manual is now bundled in the default distribution tarball, and is easily viewable as html, provided you can
  serve it using a webserver. It is also available as pdf at https://gggeek.github.io/phpxmlrpc/doc-4/phpxmlrpc_manual.pdf

• improved: automated the process of creating the github release when pushing a release-tag to GitHub; also add a tarball
  of the demo files as release asset, and automatically update both http://gggeek.github.io and the code on altervista.org

• improved: added a pre-push git hook script, to avoid pushing tagged versions with inconsistent version tags in code.
  To install it, execute composer run-script setup-git-hooks (NB: it is only useful for developers of this library,
  not for the developers simply using it)

• fixed: the value for error 'no_http2' has been switched from 15 to 19 to avoid a collision

4.9.3

• improved: avoid stalling the webserver when using the debugger with the php cli-webserver and testing the demo server within the same install

• improved: allow installation of the jsxmlrpc library within the debugger folder via composer or npm to enable the visual-editing capabilities of the debugger, as this works well when the debugger is used as web-root (target usage scenario being f.e. using the php cli-webserver to run the debugger)

4.9.2

• security fix: removed the possibility of an XSS attack in the debugger.
  Since the debugger is not designed to be exposed to end users but only to the developers using this library, and in the default configuration it is not exposed to requests from the web, the severity of this issue can be considered low.

• improved: the debugger now uses jsxmlrpc lib version 0.6. It loads it from a cdn rather than locally.
  It also can make use of a 2nd constant to help telling it where the visual-editor form the jsxmlrpc lib is located, in case its path on disk relative to the debugger and its url relative to the web root do not match.