Welcome to WebmasterWorld Guest from 62.210.77.51

Forum Moderators: Ocean10000 & incrediBILL & phranque

Message Too Old, No Replies

php header not server errordocuments

     
12:55 pm on Jan 2, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 17, 2002
posts:1178
votes: 5


I don't know if this is a php or apache problem:

httpd.conf
------------------------
ErrorDocument 404 /errors/error_4.php
ErrorDocument 500 /errors/error_5.php

If I generate either a 404 or a 500 error naturally I get served the correct pages.

But if I try and serve the pages via a test.php script it doesn't work:

test.php
--------
<?php
if(stristr($_POST['username'],"spam")) {
header("HTTP/1.1 500 Internal Server Error");
exit;
}
//rest of script here
?>

Running the script does indeed generate a HTTP 500 error but the page is blank in FF and the standard IE 500 error page in IE. The access_log files shows that the script was run but with status 500.

How can I get the script to indicate a 500 error and serve the correct error page?

As I say - this works if I generate a genuine 500 or 404 but not via this test script.

3:43 pm on Jan 2, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member jdmorgan is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 31, 2002
posts:25430
votes: 0


Your script forces the state of the response header, but it does not actually put Apache into an error state. Since Apache behaves according to its actual state, and (usually) sets the headers itself, your changing of the header cannot affect Apache's actual state. Simply put, you can't reverse the cart and the horse.

It's not clear what the goal is here, but it would probably be easier to avoid trying to change the server state, and simply output a faked-up error page to that 'user' along with a faked-up status response header, leaving the real state of Apache unchanged. Sort of a case of "Let's not do it, but say we did." Find a different mechanism to transfer control to the fake-error script, independent of Apache's error-handling mechanism.

I'd also like to comment that real 500-Error pages should be static documents, and kept as simple as possible. Otherwise, if you have a *real* server error, the added complexity of invoking a 500-error-handling script may defeat all of your attempts to find the real problem. For example, using PHP to handle errors, you might get a 500 error because of a bad PHP upgrade or a typo introduced into a configuration file. You would then then get multiple recursive 500 errors because the PHP scripts couldn't be correctly processed because of the original underlying error, and every attempt to report the error via the 500-error handler would cause another error.

The more critical an error is, the simpler its handler should be. My personal preference for 500 errors is to either use the default Apache 500-error paqe, or to output a simple HTML page with no images, CSS, or any other included elements -- dirt simple, in other words.

Jim

4:48 pm on Jan 2, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 17, 2002
posts:1178
votes: 5


This is an exercise to serve a 500 to spambots attempting to subscribe to a membership system (p h p guard dog)

If a spambot registers with certain keywords I want to feed it a 500 with the hope that they eventually give up.

So the php header function will serve a 500 but then apache will not process it's own procedure for dealing with it. Presumably I can leave the header as is but also output some meaningful text (like duplicate the error_5.php page) incase a genuine user triggers the 500?

4:50 pm on Jan 2, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 17, 2002
posts:1178
votes: 5


<?php
if(stristr($_POST['username'],"spam")) {
header("HTTP/1.1 500 Internal Server Error");

print "membership subscription error .... please contact webmaster at ....";

exit;
}
//rest of script here
?>

7:34 pm on Jan 2, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member jdmorgan is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 31, 2002
posts:25430
votes: 0


> the php header function will serve a 500 but then apache will not process it's own procedure for dealing with it.

Yes, that was my point: You can output any server response header you like, but Apache is NOT in an error state, and so will behave as if a 200-OK or other normal response is in progress. If you want the server to handle this as a 'real' 500 server error, then you'll have to do something that actually causes a server error, not just output an arbitrary 500-Error response header.

By default, the server outputs HTTP status headers in response to its internal state: The state causes the response, not the reverse.

You can preempt the server's default status response by outputting an HTTP status header from PHP or PERL, etc., but this does not change the true server state.

So I recommend that you pursue the current path, reproducing whatever text you need on the 'fake' PHP error page, and not toy with Apache's internal error-handling; If you ever get a real problem on your server due to an error caused by your host, a bad upgrade, an error in one of your scripts, or some other cause, then any modification to Apache 500-error handling may cost you dearly -- The thought that comes to mind here is that a simple 403-Forbidden response would be more appropriate, safer, and less bother.

Also, consider the chances of a genuine user hitting this page carefully; I would not hand violators my e-mail address on that error page unless you feel it's absolutely necessary because you think that a legitimate user hitting that page is likely. Consider that information is power, and the less you give to the enemy, the better.

Jim