The xmlrpc extension currently fails to handle 64bit integers[1], and
the resolutions all seem suboptimal.
XML-RPC is over 15 years old, and the initial specification omitted
support for 64bit integers. Today however, XML-RPC implementations
frequently need to exchange 64bit integers. A de facto standard, the
<i8> integer has been gaining traction in libraries for several years
now.
In the interest of improving compatibility with these libraries, I
created a pull request[2] adding support for decoding <i8> with the
xmlrpc extension. In the process of doing this however I realized that
I had introduced a problem with xmlrpc encoding.
Firstly, I allowed xmlrpc to output a 64bit integer, which was both a
spec violation (<int> can only contain a 32bit integer) and caused a
test verifying this limitation to fail[3].
This leads me to a series of possible solutions, none of which are good:
- We can break the spec, and put 64bit integers into <int>, but this
is wrong according to the spec and may break some implementations. - We could output <i8> in place of <int> which breaks backwards
compatibility and possibly compatibility with older implementations of
XML-RPC. - We could create an opt-in 64bit mode, but people should not need to
opt-in to bug fixes (it sets a bad precedent). - We could check the size of every individual integer and output <i8>
only when exceeding a 32bit integer, but this adds complexity to the
actual encoding process. - We could allow the decoding of 64bit integers but not allow
encoding. This then introduces an inconsistency between encoding and
decoding.
I would appreciate feedback on how people would like to see this issue resolved.
[1] https://bugs.php.net/bug.php?id=66389
[2] https://github.com/php/php-src/pull/555
[3] https://github.com/php/php-src/blob/master/ext/xmlrpc/tests/bug40576_64bit.phpt#L36