unable to return a 200 OK header

sfullman

I have an .htaccess file with this line

ErrorDocument 404 /404.php

which works fine - if the page is not there the user will get the 404.php page instead. So far so good.

But, in certain cases such as recognized keywords like www.mysite.com/2010-budget I want to return a "real page" using the 404.php file. I just output content from my database based on the REQUEST_URI.

The PROBLEM is that even though I put this line in the coding before any other output:

header('HTTP/1.1 200 OK');

when I do curl -I www.mysite.com/2010-budget I still get an output of
HTTP/1.1 404 Not Found

How do I force the 200 header to override the 404 header?

Thanks,
Samuel

bradgrafelman

Take a look at the manual page for [man]header/man... specifically, look at using the optional second argument.

EDIT: Oops... the default is to replace, apparently (could've sworn it was the other way around :o).

I haven't tried this with an ErrorDocument handler, but I would assume that PHP can override the default header that Apache sets. I'll try to duplicate that in my test environment, but first... what version of PHP and Apache are you using? Is PHP installed as an Apache module or a CGI binary?

Also, have you turned display_errors On and set error_reporting to E_ALL?

EDIT2: Also, have you tried using the 3rd parameter for [man]header/man? Although it shouldn't be necessary, try doing something like:

header('HTTP/1.1 200 OK', true, 200);

sfullman

It's weird but this is the deal

If I use:

header('HTTP/1.1 299 OK');

it will output a 299. BUT if I try to replace 299 with 200, it WILL NOT REPLACE the 404 status. Of course, 200 is the one I need. But interestingly enough, 299 works in the browser's mind. I say that because a referenced .js file will not "run" if the browser sees a 404 header, but it will run with a 299. Go figure..

I got this idea from this link http://bugs.php.net/27026 though on my Apache/PHP this has NOT been fixed..

Hope this helps someone out there 🙂

bradgrafelman

sfullman wrote:
though on my Apache/PHP this has NOT been fixed

Any chance you can supply us with the appropriate version numbers?