1

I'm using PHP on Apache server

I'm wondering.. If the error pages should best be served as pure and simple html, without database connection etc.?

This would remove any chance of repeating/complicating an error that was caused by php or database, no?

3
  • I know it doesn't really answer your question, but I reckon if you have those sort of errors, you have bigger problems to worry about than whether the error pages are working :P
    – Steve
    Commented Aug 23, 2014 at 4:57
  • @Steve Well, I don't have any errors, but I want to be sure the user see's a nice error page for any weird situation
    – mowgli
    Commented Aug 23, 2014 at 9:40
  • Now I have removed database connection from the error page. Maybe that's enough
    – mowgli
    Commented Aug 23, 2014 at 9:54

4 Answers 4

3

I would say yes, simply because there isn't any need for dynamic error pages. For example: If your database is down or under pressure, it is unlikely that you will want your error pages to be attempting database connections. Likewise, if your server is under pressure, you don't want your error pages to be carrying out any server-side processing. All-in-all, I think that it is better to keep things simple in this regard.

In saying that, 404 error pages might prove to be the exception to this. Example: Showing the end-user a list of links to pages that are similar to the page that they were looking for.

3

This really depends on the error being served. For a 404 error, there would be no reason that there are any issues with the server - meaning all the php stuff should be working find. But if you have a 500 there may be an issue with the server, preventing php from running. This really depends on your tolerance for risk.

1
  • I think the OP is talking about PHP code errors which will not result in a 404 or 500 error but rather errors within the PHP environment. Of course the 500 error signifies a broader error within the web server/PHP setup. I code in another language, however, I can trap errors and put up custom error pages if I would like. It is a bit of work of course. I can trigger a 301, 302, 404, 500, or any other HTTP protocol error. In this case, the question is about the PHP environment and more of a theoretical question than a how to question.
    – closetnoc
    Commented Aug 23, 2014 at 14:55
2

It depends on your situation.

Your PHP could also handle the lack of database connection in a nice way. But if you have a custom PHP with many possibilities for bugs and problems, go for an HTML page.

If you're using a system such as Drupal or WordPress it's best to go with whatever is provided there, possibly adding something such as a module such as Search 404 on Drupal that will take your visitors to a search page.

If you have a lot of traffic and the load on your servers might go up considerably when suddenly hundreds of people are refreshing a page it can be an idea to serve an image instead, served from a 3rd party service (e.g. Amazon) since it will take people more time to load the image and it will keep them from hitting Ctrl-R very quickly which would cause your load to go up even more.

1

You should only serve very generic error page to the user, as providing more details on error may disclose highly valuable information for malicious attacker.

However you need more information for debugging. There are following solutions:

  • Log all error information rather than just responding with it. This is good for production servers as allows to analyse error that happened to the end user and otherwise would never be seen by you.
  • If you have a testing server, make your software specifically configurable to respond with full error information only if it runs on a testing server.
  • If you only use your workstation for testing, only respond with full error information if the request is from the local host.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.