fix error code returned by server for invalid xml when in interop mode

Author: gggeek

NEWS.md

@@ -9,6 +9,8 @@
 
 * improved: prepare the debugger for json-rpc 2.0 support, which will be in a pending release of the PhpJsonRpc library
 
+* improved: when using "Interop" error codes, use error code -32700 when xml parsing fails server-side, instead of 100+X
+
 * improved: changes some error numbers to avoid conflicts - now errors related to http compression use the range 153-157,
   while the range 103-107 is reserved for xml parsing errors
 

src/PhpXmlRpc.php

@@ -39,7 +39,7 @@ class PhpXmlRpc
         'unsupported_option' => 20, // client
         // the following 3 are meant to give greater insight than 'invalid_return'. They use the same code for BC,
         // but you can override their value in your own code
-        'invalid_xml' => 2, // client
+        'invalid_xml' => 2, // client (and server, when interop mode is enabled)
         'xml_not_compliant' => 2, // client
         'xml_parsing_error' => 2, // client
 
@@ -129,7 +129,8 @@ class PhpXmlRpc
      * @var int
      * Let XML parse errors start at 100.
      * The final code will be 100 + X, with X coming from https://www.php.net/manual/en/xml.error-codes.php.
-     * Values are known to go from 1 (XML_ERROR_NO_MEMORY) to 21 (XML_ERROR_EXTERNAL_ENTITY_HANDLING)
+     * Values are known to go from 1 (XML_ERROR_NO_MEMORY) to 21 (XML_ERROR_EXTERNAL_ENTITY_HANDLING).
+     * Used only server-side
      */
     public static $xmlrpcerrxml = 100;
 
@@ -251,6 +252,11 @@ public static function useInteropFaults()
         self::$xmlrpcerruser = -Interop::$xmlrpcerruser;
     }
 
+    public static function isUsingInteropFaults()
+    {
+        return self::$xmlrpcerruser == -Interop::$xmlrpcerruser;
+    }
+
     /**
      * A function to be used for compatibility with legacy code: it creates all global variables which used to be declared,
      * such as library version etc...

src/Request.php

@@ -334,9 +334,9 @@ public function parseResponse($data = '', $headersProcessed = false, $returnType
 
             // BC break: in the past for some cases we used the error message: 'XML error at line 1, check URL'
 
-            // Q: should we give back an error with variable error number, as we do server-side? But if we do, will
-            //    we be able to tell apart the two cases? In theory, we never emit invalid xml on our end, but
-            //    there could be proxies meddling with the request, or network data corruption...
+            // @todo should we give back an error with variable error number, as we do server-side? But if we do, will
+            //       we be able to tell apart the two cases? In theory, we never emit invalid xml on our end, but
+            //       there could be proxies meddling with the request, or network data corruption...
 
             $r = new Response(0, PhpXmlRpc::$xmlrpcerr['invalid_xml'],
                 PhpXmlRpc::$xmlrpcstr['invalid_xml'] . ' ' . $_xh['isf_reason'], '', $httpResponse);

src/Server.php

@@ -680,10 +680,11 @@ public function parseRequest($data, $reqEncoding = '')
 
         if ($_xh['isf'] == 3) {
             // (BC) we return XML error as a faultCode
+            // unless we are in "interop faults" mode
             preg_match('/^XML error ([0-9]+)/', $_xh['isf_reason'], $matches);
             return new static::$responseClass(
                 0,
-                PhpXmlRpc::$xmlrpcerrxml + (int)$matches[1],
+                (PhpXmlRpc::isUsingInteropFaults() ? PhpXmlRpc::$xmlrpcerr['invalid_xml'] : PhpXmlRpc::$xmlrpcerrxml + (int)$matches[1]),
                 $_xh['isf_reason']);
         } elseif ($_xh['isf']) {
             /// @todo separate better the various cases, as we have done in Request::parseResponse: invalid xml-rpc vs.