If you have ever encountered an “Error 404″ message when publishing or saving a post under WordPress. It would seem that WordPress will randomly generate this error, regardless of post length or whatever. You should consult your hosting provider if this is the case, it’s probably because your webserver is configured with mod_security enabled.

The Mysterious Random 404

I’ve been wrangling with these mysterious “Error 404″ messages that I “randomly” get whenever I post an article on this blog. For instance, while editing the article [PHP4 and PHP5 Side-by-Side Installation on Breezy][php4php5], I was continuously plagued with this error. It turns out, after a lot of trial and error, that the problem is caused [by mod_security][mod_security]. After discovering this, I went out and [posted][wp_forum_post] on the WordPress forums. It turns out, a lot of WordPress users seem to be having this problem.

I posted on the forum about 3 months ago and eventually, I forgot about it. Until it bit me in the ass again today. I tried to update [PHP4 and PHP5 Side-by-Side Installation on Breezy][php4php5] today to point out that it also works under “Dapper”. There it was again — Error 404. The funny thing is, if I saved the unmodified article, I still get the Error 404. It was only about 3 months ago that I posted it, and it passed mod_security validation. So through the same trial and error process described below, I was able to update the article.

mod_security

mod_security works by intercepting requests to the webserver, be it a GET request or a POST request. When you post an article to WordPress by clicking “Save and Continue Editing”, “Save”, or “Publish”, a POST request is made to your server. This request is then intercepted by mod_security which does some analysis of the POST’ed data. Based on filtering rules set forth by your hosting provider, your post will either pass or fail to validate. If your POSTed data fails to validate, the default action would be to generate a 404 error.

Working Around mod_security

Temporarily Disabling mod_security

The best way to work around mod_security is to disable it while you are posting and enable it when you are done posting. If you are under virtual hosting like myself, you would be lucky if you are allowed to turn off mod_security via .htaccess. To check out if you are able to turn off mod_security this way, add^[1][note1] the following lines to your .htaccess file:

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

Upload your update .htaccess file back to your server. Then check if your configuration worked by visiting your home page. If you see your home page, then the above configuration works. Now you should be able to post anything without it being intercepted by mod_security. If the above configuration does not work (i.e., you get an “Internal Server Error” instead), you might want to try the next one. Remove the above configuration from your .htaccess and replace it with the following:

<ifmodule mod_env.c>
SetEnv MODSEC_ENABLE Off
PassEnv MODSEC_ENABLE
</ifmodule>

Upload your updated .htaccess file. Then visit your home page and make sure that it does not generate an “Internal Server Error”. Most of the time, the SetEnv directive does not cause an “Internal Server Error”. It only requires FileInfo permissions to use it in your .htaccess and most hosting providers allow FileInfo by default. Try posting the problematic post (i.e., the one that causes the 404 error) and see if it works. If it does not work^[2][note2], then you are out of luck and must resort to the “infernal HTML entities work-around”.

Let me stress the point that if either one of the the above configuration settings work for you, you should not make them permanent. Your hosting provider installed mod_security to protect the sites that they are hosting. If you leave mod_security disabled and your site gets broken into it will be your fault!

Infernal HTML Entities

So you’ve tried disabling mod_security and it did not work, what do you do now? Well, you can try working around mod_security by “fooling” it. As of mod_security version 1.9.x, it seems that HTML entities will pass through just fine. However, before you think of encoding your entire post into HTML entities you should keep in mind that mod_security filters only certain word combinations. You can ask your hosting provider what rules they use for mod_security, but I doubt that they will give you that information. If they do give it to you, you will need to decipher them. See the mod_security documentation for that.

Unless you are able to acquire the mod_security rules from your hosting provider and you are able to decipher them, your only option would be to discover those rules by trial and error. First save your troublesome article text into a file. Then post the contents of the file paragraph by paragraph (i.e., post the first paragraph, then the second one, so on…). When you encounter the 404 error on a certain paragraph, stop right there and post the first sentence of the offending paragraph. Continue posting the sentences of the offending paragraph until you hit the sentence that causes a 404 error. From there, you should post the sentence word by word until you find the word that causes the 404 error.

When you find the word that causes the 404 error, modify the word by encoding any of the characters in the word using HTML entitiesm you can use [this table][htmlentities] for reference. For example, I’ve found that through trial and error, my post triggers the 404 error when the word “curl” appears in the text along with other words. Using the table [here][htmlentities], I encode ‘c’ into its HTML entity like so:

curl

If you look up the character for the decimal value 99 in the [table][htmlentities], you will find that it’s the character ‘c’. Now, try posting the encoded text. You should now be able to post it without problems and you can continue with your trial and error or you can try posting the remainder of your text file after the encoded word and see if it gets posted without errors.

That’s it. Good luck and happy hunting!

NOTES:

¹ If you are using “pretty URLs” for WordPress, make sure you download your current .htaccess file and add the mod_security directives to it.

² In my case, using SetEnv did not work. I think it has something to do with my PHP installation. On the server hosting this blog, PHP is installed as a CGI binary. Even PassEnv does not seem to work.

[php4php5]: http://abing.gotdns.com/2006/03/14/9/ “Permanent link to PHP4 and PHP5 Side-by-Side Installation on Breezy” [mod_security]: http://www.modsecurity.org/projects/modsecurity/apache/index.html “ModSecurity – ModSecurity for Apache” [wp_forum_post]: http://wordpress.org/support/topic/61431/page/3 “WordPress Support Forums: 404 after save or publish a post” [note1] #note1 “Note 1″ [note2] #note2 “Note 2″ [htmlentities]: http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html “ISO 8859-1 (Latin-1) Characters List”

This entry was posted on Thursday, July 6th, 2006 at 2:21 am and is filed under Apache, System Administration. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.