Skip to content
This repository was archived by the owner on Oct 10, 2019. It is now read-only.

Alternative bugfix for problem with invalid characters in thrown exception#3

Open
slavo2 wants to merge 1 commit intoklarna:masterfrom
slavo2:fix/invalid-character-in-exception2
Open

Alternative bugfix for problem with invalid characters in thrown exception#3
slavo2 wants to merge 1 commit intoklarna:masterfrom
slavo2:fix/invalid-character-in-exception2

Conversation

@slavo2
Copy link
Copy Markdown

@slavo2 slavo2 commented Jun 1, 2015

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)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

JoakimLofgren added a commit that referenced this pull request Jun 3, 2015
…-date to v4.0

* commit '52038e47e53f9f21c252443bbe0af920d5685032':
  Set timezone for extendExpiryDate
  Update CHANGELOG
  Add extend expiry date XMLRPC function call
@slavo2
Copy link
Copy Markdown
Author

slavo2 commented Jun 26, 2015

So maybe the change could be made in 4.0 branch, e.g. using pull request #4

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants