Thank you, Your Mother. I certainly gave too little details. I solved the issue. MySQL was set correctly. I was passing the values with a GET and something like this: /cgi-bin/mobile/setNewAccount.pl?key=$LicenseKey&user=$CloudUserName&pw=$CloudUserPW This would have needed special care for special characters. So I simply switched to POST and sending my data with:

my $request = POST($url, Content_Type=>'application/json',
    Content => encode_json($data) );
my $response = $ua->request($request);
[download]

This works fine. Will now read on vulnerabilities of this approach.

Your new approach using POST is far safer than what you were doing and has far better compliance with RFC2616's rules for "safe" and "idempotent" methods. In brief, GET requests are "defined" to not have side effects, while other methods, including POST, have no such restrictions. You must use POST if the request is intended to do something.

Further, request URLs often appear in logs, but POST data is generally understood to be potentially sensitive. You should never submit a password with a GET request; logins need to always use POST and, if you are sending them over the open Internet, TLS. Plaintext HTTP is safe on an isolated network, but sending anything remotely sensitive over the open Internet needs HTTPS (or the TLS upgrade sequence for HTTP/TLS over port 80).

Plaintext HTTP is safe on an isolated network

You make some good points, but I disagree with this bit, on principle. At the very least, one should use a scheme such as Digest access authentication. (And what network is really isolated anymore nowadays?)

just to clarify: if you use GET even on HTTPS, the GET parameters, just like the url, will not be encrypted (unless already encrypted). But POST over HTTPS will send its parameters (even plain-text ones) using the negotiated secure channel, right?