Alternative bugfix for problem with invalid characters in thrown exception #3
Conversation
…nvalid character in thrown exception
| $tmp_xmlrpc_internalencoding = $GLOBALS['xmlrpc_internalencoding']; | ||
| //Set XML RPC client encoding settings. | ||
| $GLOBALS['xmlrpc_defencoding'] = 'ISO-8859-1'; | ||
| $GLOBALS['xmlrpc_internalencoding'] = 'UTF-8'; |
There was a problem hiding this comment.
This feels a bit odd.. isn't this the purpose of the $accepted_charset_encodings and $request_charset_encoding fields?
// The charset encoding used by the server for received messages and
// by the client for received responses when received charset cannot be determined
// or is not supported
$GLOBALS['xmlrpc_defencoding']='UTF-8';
// The encoding used internally by PHP.
// String values received as xml will be converted to this, and php strings will be converted to xml
// as if having been coded with this
$GLOBALS['xmlrpc_internalencoding']='ISO-8859-1';Those globals seems to only be there as a fallback.
There was a problem hiding this comment.
But it works for UTF-8 based PHP applications with current Klarna API (using ISO-8859-1 by default)
Without that both input strings, being sent to Klarna API, as well as strings received from Klarna API (e.g. error messages) are incorrectly interpreted.
Most important is line 3663 - it sets encoding, in which strings accepted as parts of arguments are interpreted and returned strings are encoded. I suppose neither of these things is being set by $accepted_charset_encodings nor $request_charset_encoding, but it is actually the bit, which allows XML RPC client communicate correctly with the rest of the application.
There was a problem hiding this comment.
After some further investigation, the simplest solution (for us both), would be for you to just set
$GLOBALS['xmlrpc_internalencoding'] = 'UTF-8';After you have configured the Klarna object (that's when the xmlrpc.inc file is loaded by the composer autoload and the globals are set).
We do not want to change the default encoding due to backward compatibility reasons.
…-date to v4.0 * commit '52038e47e53f9f21c252443bbe0af920d5685032': Set timezone for extendExpiryDate Update CHANGELOG Add extend expiry date XMLRPC function call
|
So maybe the change could be made in 4.0 branch, e.g. using pull request #4 |
This pull request provides alternative fix for bug described in
pull request #1 and Issue #2
Provided solution: sets encodings for PHP XML RPC client before XML RPC call
(and sets encodings to previous values after XML RPC call)