Serving proper 404/410 error codes on dynamic database driven site

Question

a developer I'm working with is having a difficult time serving 404 errors on dynamically generated pages (they get created when the request is made by querying the database to see if the content exists)

He has told me (paraphrasing) that it's too late to serve the error because the page has already started loading by the time it finds out if the page exists or not. I'm not really sure how to respond not knowing much about how PHP or apache work

Has anyone else run into this sort of issue and if so, how could I resolve it and start serving proper 404 or 410 errors on this removed content?

Currently requests are being redirected (not sure if 302 or 301 at the moment) to our 404.php page. Is this an acceptable alternative?

Thanks :)

Answer 1

If the code is half way through printing out the page, it is indeed too late send a 404 status. Any status codes must be set as a HTTP header, sent before any of the HTML.

Because of this, it is usually useful to structure the code such that it gather the information that it need to build the page before sending any HTML to the client. Your developer may not have set it up this way, unfortunately.

The only thing that doesn't sit right with your developer's explanation: 301 and 302 redirects are also specified as HTTP status codes that need to be sent before any HTML. If it isn't too late to send a redirect, it shouldn't be too late to send a 404 header. The PHP manual for headers has examples of redirects and 404s. They are very similar.

Redirecting to a 404 page rather than directly showing a 404 page is very common. Apache configuration makes doing so very easy (even by mistake sometimes). As a result, search engine spiders have to know how to deal with such a situation. It isn't ideal, but it shouldn't cause huge problems.

Answer 2

According to RFC 2616 (Section 4.2):

The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response- header fields, and ending with the entity-header fields.

You have to think a little different if you're a developer and have to deal with an issue like this. This style of coding needs to be determine at the BEGINNING OF DEVELOPMENT. Many people love to code PHP so they can switch in and out of HTML. At the point HTML (even a whitespace) or PHP has an echo or print statement headers are closed (not the HTML headers, but the headers that tell the browser what is coming, an image, an HTML page, a redirect, etc.).

Typical PHP code by home-grown developers:

<h2>Welcome <?php echo $Username; ?></h2>
<p> We were considering your application(s) for <?php echo $specialty; ?>.
We are <?php

  if($accepted==1){
     echo "happy"
  } else {
     echo "sorry"
  }

  ?> to inform you of our decision ...

A better, more flexible way

The way around this is to store everything serverside until completely done processing, THEN check for errors and post a response. A better method is:

/*$page string started out here somewhere*/

if(empty($request_id)){
  //code for the 404
} elseif ($request_id < 0)
  //code for the 410
} else {

  switch($accepted){
    case "1":
     $mood = "happy";
    break;
    default:
     $mood = "sorry";

$inner_code = "<h2>Welcome $Username</h2>\n";
$inner_code .= "<p>We were considering your application(s) for $specialty.";
$inner_code .= " We are $mood to inform you of our decision ...";

/*more stuff here*/

$page .= $HTML_header;
$page.=$inner_code;
$page .= $HTML_footer;

print $page;

}

In your specific case

It sounds as though a lot of development has been done. If the site has a bit of size or complexity, this can cause an issue in budgeting (if you're using contractors). If the programmers are in-house though, you should be able to rewrite the site without issue (at least this part of it).