Apache Cookbook and over 2 million other books are available for Amazon Kindle . Learn more

Have one to sell? Sell yours here
Start reading Apache Cookbook on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Apache Cookbook [Paperback]

Ken Coar , Rich Bowen
5.0 out of 5 stars  See all reviews (2 customer reviews)

Available from these sellers.

‹  Return to Product Overview

Product Description


"The range of recipes is excellent, covering ust about every task you'd be likely to throw at Apache, from complex redirects to performance tweaking and error handling... Apached Cookbook offers a pleasant, highly usable guide which should ensure the smooth, successful running of many a website" - Martin Howse, Linux User & Developer

About the Author

Ken Coar is a member of the Apache Software Foundation, the body that oversees Apache development. He is the author of Apache Server for Dummies (January 1998) and co-author of Apache Server Unleashed (March 2000). Ken has been responsible for fielding email sent to the Apache project, and his experience with that mailing list provided a foundation for this book.

Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. He lives in Lexington, Kentucky, where he spends his free time GeoCaching. He also enjoys flying kites and reading stuff by Charles Dickens and his contemporaries. Rich is a coauthor of Apache Administrators Handbook and Apache Cookbook. Rich, or DrBacchus--his handle on IRC--also spends entirely too much time on #apache. You can find him on the web at http://www.drbacchus.com/journal/.

Excerpt. © Reprinted by permission. All rights reserved.

Chapter 9 - Error Handling

When you’re running a web site, things go wrong. And when they do, it’s important that they are handled gracefully, so that the user experience is not too greatly diminished. In this chapter, you’ll learn how to handle error conditions, return useful messages to the user, and capture information that will help you fix the problem so that it does not happen again.

9.1 Handling a Missing Host Field

You have multiple virtual hosts in your configuration, and at least one of them is name-based. For name-based virtual hosts to work properly, the client must send a valid Host field in the request header. This recipe describes how you can deal with situations in which the field is not included.

Add the following lines to your httpd.conf file:

Alias /NoHost.cgi /usr/local/apache/cgi-bin/NoHost.cgi
RewriteEngine On
RewriteCond "%{HTTP_HOST}" "^$"
RewriteRule "(.*)" "/NoHost.cgi$1" [PT]

The file NoHost.cgi can contain something like the following:

#! /usr/bin/perl –Tw

my $msg = "To properly direct your request, this server requires that\n"
. "your Web client include the HTTP 'Host' request header field.\n"
. "The request which caused this response did not include such\n"
. "a field, so we cannot determine the correct document for you.\n";
print "Status: 400 Bad Request\r\n\"
. "Content-type: text/plain\r\n\". 'Content-length: ' . length($msg) . "\r\n\"
. "\r\n\"
. $msg;

Once the directives in the solution are in place, all requests made of the server that do not include a Host: field in the request header are redirected to the specified CGI script, which can take appropriate action.

The solution uses a CGI script so that the response text can be tailored according to the attributes of the request and the server’s environment. For instance, the script might respond with a list of links to valid sites on the server, determined by the script at runtime by examining the server’s own configuration files. If all you need is a "please try again, this time with a Host: field" sort of message, a static HTML file would suffice:

RewriteRule .* /nohost.html [PT]

A more advanced version of the script approach could possibly scan the httpd.conf file for ServerName directives, construct a list of possibilities from them, and present links in a 300 Multiple Choices response. Of course, there’s an excellent chance they wouldn’t work, because the client would still not be including the Host: field.

9.2 Changing the Response Status for CGI Scripts

There may be times when you want to change the status for a response—for example, you want 404 Not Found errors to be sent back to the client as 403 Forbidden instead.

Point your ErrorDocument to a CGI script instead of a static file. The CGI specification permits scripts to specify the response status code.

In addition to the other header fields the script emits, like the Content-type: field,
include one named Status: with the value and text of the status you want to return:

#! /bin/perl -w
print "Content-type: text/html;charset=iso-8859-1\r\n";
print "Status: 403 Access denied\r\n";

If Apache encounters an error processing a document, such as not being able to locate a file, by default it will return a canned error response to the client. You can customize this error response with the ErrorDocument directive, and Apache will generally maintain the error status when it sends your custom error text to the client.

However, if you want to change the status to something else, such as hiding the fact that a file doesn’t exist by returning a Forbidden status, you need to tell Apache about the change.

This requires that the ErrorDocument be a dynamic page, such as a CGI script. The CGI specification provides a very simple means of specifying the status code for a response: the Status: CGI header field. The Solution shows how it can be used.

‹  Return to Product Overview