Error 406, “An appropriate representation of the requested resource XXX could not be found”, WordPress, and The Fatal Image/<img> Tag
I recently did some work for a client, and it was a stumper.
As the post title suggests, I had encountered a 406 error in working on a WordPress blog (otherwise known as “An appropriate representation of the requested resource XXX could not be found“) – but the error was extremely odd and a real pain to troubleshoot.
First off, this error message didn’t appear right away. In fact, the only problem was that the client couldn’t include images in his WordPress posts anymore. Trying to save/publish the post simply sent him to a blog page!
It took quite a bit of fiddling, but eventually the problem was found: the “http://” in the <img> tag’s image URL was not working – leave it off, or use something like “https://” instead, and it saved the post fine (but of course wouldn’t display right).
The next step was to see what was causing it. I turned on the default theme, turned off all plugins, and tried again. Still no go – the file wouldn’t save, but went to a blog page.
Try again: this time I reset the permalinks from the usual text to the default setting (the ?p=XXX posts version). I also renamed .htaccess so it wouldn’t be influencing the blog at all. Still, no way to save the post when “http://” appeared in it. Not only that, but I now found I couldn’t set the permalinks back either! That is, trying to reenter
back into the permalinks also sent me to a blog web page.
By now I was getting annoyed. Time to check the PHP settings via phpinfo(), using two variations:
<?php phpinfo(); ?>
<?php phpinfo(INFO_MODULES); ?>
(The former gives the PHP settings; the latter, the modules loaded in. To use, just create a file for each, upload, and then call via your browser. Be sure to remove them from your site after, as they leak a lot of information you don’t want passed around).
At this point, I was looking for something outside of the WordPress blog; a setting/module called MOD_SECURITY, which is a filter on data passed to the website. No dice, and no setting.
Unfortunately, no setting visible doesn’t mean MOD_SECURITY is not there (in fact, that turned to to be the case). But because I couldn’t access it, I couldn’t use the usual troubleshooting methods of editing .htaccess
For example, you can usually add this to the top of your .htaccess file to turn off MOD_SECURITY:
For the most safety, you can selectively turn off MOD_SECURITY just within the /wp_admin/ section, by creating an .htaccess file there and including those lines. Alternately, for either location you can use these entries to turn off only POST filtering:
By just turning off the POST filtering, the rest of MOD_SECURITY remains active.
Oddly enough, for my client, none of these worked. I figured it must be something else (like some server filtering, perhaps). But since I had explored all the options, I was certain that WordPress was doing nothing, and it must be a server setting. So I asked my client to contact support, mentioning that certain keywords were being filtered.
The result? THEY turned off MOD_SECURITY, and his site was as good as new!
So to recap for those pulling out their hair:
- MOD_SECURITY is a filter that tries to prevent ‘bad’ words from getting into the forms via POST (or GET). In this case, it thought the <img> (image) tag’s src= entry URL with “http://” in it might be an attempt at hacking, and likely /%category%/%postname%/ an attempt to hide data (the % is used for encoding).
- The problem was hidden at first because of permalinks. When the post was killed by MOD_SECURITY, the website generated a 406 error. But there was no handler for a 406 error, so the result was a 404 (file not found) error, which quite naturally IS handled by WordPress. Without turning off permalinks and resetting them, this would have continued to muddy the waters, making the problem very hard to figure out.
- MOD_SECURITY is elusive: although the setting may appear with phpinfo(), in this case it didn’t. No trace of it, yet the webhost had it activated.
- MOD_SECURITY can be deactivated. Although in this situation it needed a call to tech support, it’s possible to deactivate directly in many cases. You can use .htaccess to turn it off completely at the blog root, or turn it off in the /wp-admin/ directory only, or even better, use only the “SecFilterScanPOST Off” entry to turn off the POST filtering, leaving the rest of MOD_SECURITY still active.
I hope this little summary helps you if you encounter the problem. It was a hair-puller, but the end result was a little more Apache server information gleaned!