-
Bug
-
Resolution: Fixed
-
Critical
-
3.1.4, 3.2.1, 3.2.4, 3.3.1
-
MOODLE_31_STABLE, MOODLE_32_STABLE, MOODLE_33_STABLE
-
MOODLE_32_STABLE, MOODLE_33_STABLE
-
MDL-57775-master-xmlrpc -
-
3.4 Sprint 4
This core bug has been discovered while I was working on MDLSITE-4726. We had a problem at moodle.net with some sites with non-ascii characters in their names. Their name was displayed wrongly.
Synopsis (long story short)
The XML-RPC client in Moodle 3.1 and 3.2 is broken and needs to be fixed. Moodle sites use that client to update their registration information via a scheduled task.
Description
As a result of MDL-52209, the Zend framework was removed from XML-RPC web service plugin in Moodle 3.1. Our webservice_xmlrpc_client class - originally extending the Zend_XmlRpc_Client class - was rewritten to use the PHP's xmlrpc extension directly.
Once a Moodle site is registered with a hub (such as moodle.net), the class webservice_xmlrpc_client is used by the registration_manager::cron() method to periodically update the site info at the hub. This is done by remotely calling the hub's web service function hub_update_site_info().
As was discovered in MDL-54868, there is a bug in the xmlrpc extension https://bugs.php.net/bug.php?id=41650 that escapes all UTF-8 characters in the RPC request wrongly as individual bytes, which then leads to nonsense result after decoding on the other side. Example:
xmlrpc_encode_request('method', '€', ['encoding' => 'utf-8']) |
produces incorrect:
<?xml version="1.0" encoding="utf-8"?> |
<methodCall> |
<methodName>method</methodName> |
<params> |
<param> |
<value> |
<string>€</string> |
</value> |
</param> |
</params> |
</methodCall> |
Such a request, when decoded via xmlrpc_decode($req, 'utf-8') then leads to a rubbish like ⬠instead of €.
Luckily, the fix is trivial. We need to declare additional output option "escaping" for the xmlrpc_encode_request():
xmlrpc_encode_request('method', '€', ['encoding' => 'utf-8', 'escaping' => 'markup']) |
then leads to the correct:
<?xml version="1.0" encoding="utf-8"?> |
<methodCall> |
<methodName>method</methodName> |
<params> |
<param> |
<value> |
<string>€</string> |
</value> |
</param> |
</params> |
</methodCall> |
Unfortunately, in the issue MDL-54868 only the webservice_xmlrpc_server was fixed to have this escaping set correctly. The webservice_xmlrpc_client was forgotten.
Steps to reproduce
Set up a new 3.1 or 3.2 site having non-ascii characters in its name. Let us say the name of the site is MOODLE ŠKOLA.
When a site is initially registered with a hub, the site name is passed to the hub via the plain HTTP GET request and all encoding is all good. The site appears with the correct name on https://moodle.net/sites/ list.
Once the schedule task core\task\registration_cron_task is executed, it sends the information wrongly encoded/escaped via the XML-RPC request. It will contain something like
<string>MOODLE Å KOLA</string> |
and after decoding, the name of the site appears on moodle.net as MOODLE Å KOLA.
See MDLSITE-4726 for further examples of what you get from Greek, Russian or Chinese characters.
p.s. While debugging this, I also realized that moodle.net has another bug so that it still displays a site even after it has been unregistered. You may take this into account before attempting to use moodle.net for testing this.
- has a non-specific relationship to
-
MDL-54868 Change of encoding behaviour in XMLRPC web services
- Closed
-
MDL-60977 XMLRPC request encoded on Moodle 3.1 can not be decoded
- Closed
-
MDL-59852 Replace dependency on the XML-RPC extension
- Closed
- has been marked as being related by
-
MDL-60594 Course names not displayed correctly in the Community finder block
- Closed
- is a regression caused by
-
MDL-52209 Remove Zend XML-RPC from Moodle's XML-RPC web service
- Closed
- will help resolve
-
MDLSITE-4726 Sites not displaying correctly on https://moodle.net/sites
- Resolved
-
MDLSITE-4617 Some non-English language courses sent to Moodle.net do not display correctly
- Closed