Mysterious HTTP 404 header in my own scripts

by

I have a WordPress 3.5.1 + nginx configuration. Its nginx configuration is this:

server {
    root /mysite/public_html;
    server_name wp.mysite;
    location / {
        try_files $uri $uri/ /index.php;
        index index.php index.html index.htm;
    }
    location ~ \.php(.*)$ {
        try_files $uri =404;
        include /etc/nginx/fastcgi_params;
        if ($uri !~ "^/uploads/") {
                fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
        }
        fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME /mysite/public_html$fastcgi_script_name;
    }
}

Note that WordPress’s index.php is in /mysite/public_html/.

I’m also using nginx helper. Since I’m only running a single site, I only used its permalink beautify function.

I noticed that my custom scripts (outside of WordPress) are returning 404 headers. For instance, if I put index.php into /mysite/public_html/my/, and point browser to http://wp.mysite/my/, the script will execute okay, even with correct MIME type, but with an HTTP 404 header.

Putting header("Status: 200 OK"); (for fastcgi) won’t work. In fact, it seems to ignore other headers such as Cache-Control and Expires as well. It did pick up Content-type header as I mentioned earlier. In fact, its header part is:

$sapi_type = php_sapi_name();
if (substr($sapi_type, 0, 3) == 'cgi')
    header("Status: 200 OK");
else
    header("HTTP/1.1 200 OK");
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Content-type: image/jpeg");
imagejpeg($this->im, null, 80);

I can see the JPEG alright. But no other headers are sent. I’m wondering where do I start to debug this problem? Thank you.

1 Answer
1

It turns out that it’s the require('../wp-blog-header.php'); part who caused the HTTP 404 error. I replaced the header code with:

status_header(200);
nocache_headers();

Both are part of WordPress API. And the problem went away. I found this solution from: http://wordpress.org/support/topic/integrating-wp-in-external-php-pages?replies=22

Leave a Comment