Http 406 Errors Galore

If you have ever had these errors or just want to be prepared in case they pop up somtime (and they surely will), then read on as I discuss various situations that lead to them and also their solutions.

I generally use desktop clients (mostly blogjet, but also Windows Live Writer and Scribe Fire sometimes) to blog to my WordPress based blogs. Some months ago, I started getting “Http 406: Not Acceptable” error while posting a particular post. Tried posting through the WordPress inbuilt TinyMCE editor, but got the same result. A little bit of research told me that this was because the post contained some words that were considered harmful by the “mod_security” plugin for apache that had been installed by my host to prevent hacking attempts. The quick resolution was to include the following lines in my .htaccess:

<ifmodule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</ifmodule>

Sure enough, I put them in, published the post, and it worked. But since this meant opening up my site to the real hacking attempts, I commented them out and went about my work, occassionally turning them on as and when required.

But, a few days ago, after a server upgrade, the problem reared its head again, and in a more vicious manner. I started getting the dreaded 406 error again, and this time for any post, even a blank post, and through all clients. But this time, TinyMCE was working without issues. A little bit of looking around my site told me that the problem was that my desktop clients were not able to connect to my “x mlrpc.php” file which is responsible for taking care of all the remote api provided by WordPress. Trying to access it through any means provided the 406 error. My site’s error log was filled with:

Now, the xml rpc methods are used not just by WordPress but many other CMS’s (like drupal, joomla, etc) and sure enough a quick search resulted in many similar reports for all the platforms. Enabling my previous mod_security options resulted in “503: Server misconfiguration” errors, complicating things further.

On seeing the error logs, I found that the server could not understand the options, and then I discovered that the mod_security had been upgraded to and it wasn’t backward compatible with old options. Modifying the options to their latest counterparts also didn’t work, as further wading through mod_security manual told me that now, its options cannot be overridden through .htaccess and can only be changed by the web admin.

I found that my host has basically blocked the x mlrpc.php file from being accessed at all instead of using proper rules for blocking only the attacks while allowing valid accesses. This was the problem that a huge number of people are also having and moreover they (like me) are not able to convince their hosts to switch to proper rules.

However, not all hope is lost. I have “fixed” this issue with a workaround for now. It is pretty simple really. Just rename your x mlrpc.php to something else (e.g. myrpc123.php) and also replace all references to it in your CMS with your new file name. You can use sed to automate this task. I used perl however:

perl -e 's/x mlrpc.php/myrpc123.php/gi' -p -i *

Now, the 406 errors should be gone. If this worked for you, or you had any issues let me know. Also, if you have any other workarounds/fixes of your own, do drop me a word.

Note: In the above article, please ignore the space between “x” and “mlrpc” as the mod_security rules prevent them from being in content also. Moreover, use some unique name for rpc file.

See also