WordPress’s iOS app requires php-xml being installed on serverAfter reinitialized my VPS, WordPress’s iOS app starts to keep reporting “parse error. not well formed”.
I once thought this was caused by my too constrained TLS cipher suites as only CHACHA20 / AES256 is enabled for TLS 1.2 since then, and “parse error” really looks like the app somehow trying to parse a failed-to-decrypt response.
I tried to revert my settings of TLS, both the cipher suites and ECDH curve, but none of them turns out to work.
After logged what’s sent to nginx, it turns out that WordPress’s app failed to call system.listMethods on /xmlrpc.php. This can be confirmed with posting <?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall> to /xmlrpc.php:
1234567891011121314151617 <?xml version="1.0" encoding="UTF-8"?><methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>-32700</int></value> </member> <member> <name>faultString</name> <value><string>parse error. not well formed</string></value> </member> </struct> </value> </fault></methodResponse>
Digging though the web it seems that xmlrpc.php requires php-xml to be installed, albeit not prompted for when installing WordPress (unlike php-mysql).
The referenced page also says that php-xmlrpc is necessary but that’s not the case for me. I only installed php-xml and everything seems to be fine.
Some interesting facts noticed during debugging the issue:
- Even if CHACHA20 is enabled, WordPress’s iOS app is still sticking with ECDHE-ECDSA-AES256-GCM-SHA384;
This could be an iOS issue, though, as Safari is doing this as well.
It’s also possible that A12 is better of doing AES and thus show a preference. 192.0.118.16 tries to call demo.sayHello on xmlrpc.php after WordPress’s iOS app fails to communicate. Presumbly this is a debugging mechanism built in WordPress’s app.
After reinitialized my VPS, WordPress’s iOS app starts to keep reporting “parse error. not well formed”.
I once thought this was caused by my too constrained TLS cipher suites as only CHACHA20 / AES256 is enabled for TLS 1.2 since then, and “parse error” really looks like the app somehow trying to parse a failed-to-decrypt response.
I tried to revert my settings of TLS, both the cipher suites and ECDH curve, but none of them turns out to work.
After logged what’s sent to nginx, it turns out that WordPress’s app failed to call system.listMethods on /xmlrpc.php. This can be confirmed with posting <?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall> to /xmlrpc.php:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | <?xml version="1.0" encoding="UTF-8"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>-32700</int></value> </member> <member> <name>faultString</name> <value><string>parse error. not well formed</string></value> </member> </struct> </value> </fault> </methodResponse> |
Digging though the web it seems that xmlrpc.php requires php-xml to be installed, albeit not prompted for when installing WordPress (unlike php-mysql).
The referenced page also says that php-xmlrpc is necessary but that’s not the case for me. I only installed php-xml and everything seems to be fine.
Some interesting facts noticed during debugging the issue:
- Even if CHACHA20 is enabled, WordPress’s iOS app is still sticking with ECDHE-ECDSA-AES256-GCM-SHA384;
This could be an iOS issue, though, as Safari is doing this as well.
It’s also possible that A12 is better of doing AES and thus show a preference. 192.0.118.16tries to calldemo.sayHelloonxmlrpc.phpafter WordPress’s iOS app fails to communicate. Presumbly this is a debugging mechanism built in WordPress’s app.