Custom permalink and 404.php error

My System’s Set-up:

FreeBSD 5.4
Apache 1.3.34
PHP 4.4.2
WordPress 2.0

Next, I’ll point to several related threads in this forum.

Steps I’ve Taken So Far

1. First, I read all of the documentation on Creating an Error 404 Page and Using Permalinks, trying all of their suggestions. None of them worked for me.
2. Next, I took a look at my .htaccess file. It’s CHMOD access was 666 (which is correct, and what an omen, huh?). The contents of it were:

   
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
</IfModule>
# END WordPress
ErrorDocument 404 /404.html


   This is what WordPress created for the custom permalinks, and it appears to be working as it should – except for the last line. The last line should be displaying the custom 404.php file. And for some reason, it wasn’t.

3. Next, I verified that my hosting provider has the Apache module mod_rewrite installed. They do.
4. Next, I read all of the above forum threads and even tried a search on Yahoo and Google. The thread WP 2.0 messed up my permalinks held some promise. One of our members, Ryan, posted some fixes to the functions-post.php and classes.php files. I promptly downloaded & installed them. Unfortunately, they didn’t resolve the bug.
5. Then I turned off my custom permalinks and found my custom 404 page working as it should. However, when I tried to point my 404 page to the custom one in my theme (using: ErrorDocument 404 /index.php?error=404 in my .htaccess file), I received the same error again. Hmmm.
6. Then I decided to dig into the .htaccess file some more, to understand exactly what it was doing. I read up on this Apache module mod_rewrite documentation. And here is what I understand to be going on:

   This turns on the mod_rewrite runtime engine:
   RewriteEngine On

   This sets the base URL for rewrites to my document root URL (for you, it could be different):
   RewriteBase /

   This sets a condition to detect whether or not the URL to your blog is a valid filename. If it’s NOT, then it returns true:
   RewriteCond %{REQUEST_FILENAME} !-f

   This sets a condition to detect whether or not the URL to your blog is a valid directory. If it’s NOT, then it returns true:
   RewriteCond %{REQUEST_FILENAME} !-d

   If both conditions are true (meaning if the URL to your blog is not an existing filename or directory, then go to your root index.php file:
   RewriteRule . /index.php

   Ah ha. That seems to be something. So essentially, these rewrite conditions are hijacking the errorDocument statement and pushing every request through index.php. That explains why my system has been seemingly ignoring my errorDocument statement.

7. Then I typed in this explicitly: blog_domain_name.com/index.php?error=404, since that’s what this documentation suggests. Instead of seeing my custom 404 page, I get my blog’s homepage. Ah. Now I think I’m getting closer to the problem. The issue seems to be in how WordPress handles the error querystring parameter.
8. Now I’m going to dig into WordPress’ code to find out exactly what it does with the error parameter. It seems to me that blog_domain_name.com/index.php?error=404 should work, and for some reason, it isn’t. Give me a few days to look into this. If I find any answers, I’ll post them right away. If you have any comments, please post them to this thread! Thanks!

Solved!

My sysadmin looked into the problem, did some research, and discovered that FastCGI was causing the problem.

The solution has already been documented here on this forum, in the thread problems running under php/fastcgi.

Big thanks to everyone here who helped out! And much thanks to my brilliant sysadmin!