A Day in the Life of #Apache by Rich Bowen, coauthor of Apache Cookbook 12/04/2003

Author's note: I spend a lot of time on IRC. I mean a lot of time. Time when I really should be doing other things. After all, IRC is a great place to go for answers to questions. The trouble is, everybody seems to ask the same questions, day after day. And the folks that answer the questions tend to get frustrated with the folks asking the questions, and either stop answering, or start flaming. So it occurred to me that I should really start writing up some of these conversations and put them on my web site. About the same time, O'Reilly approached me about writing an article to coincide with the release of Apache Cookbook, which I co-wrote with Ken Coar. I pitched the idea of a series based on my IRC conversations, and voilà, someone is actually going to pay me to do this. Ain't life grand?

Today's piece jump-starts this new series, "A Day in the Life of #Apache", here on ONLamp. The goal of these articles will be to condense some of those frequent IRC conversations into a format that can be used to help folks with these commonly occurring problems, while, at the same time, reducing the burn-out rate of IRC tech support. And, of course, other folks can benefit from these articles without having to put up with the strange and surreal world that is IRC. There will be a Talkback at the end of each of these articles -- please let me know what you think.

Day One

Welcome to "day one" on #apache. Today, we encounter a user who is having difficulty getting his .htaccess file working. With the help of Fajita, we'll try to solve this problem. (Fajita is the name of the infobot that runs on the channel.) In future articles, we'll tackle some more difficult problems, but in the first few of this series, we'll look at the problems that seem to come up every day.

#apache is an IRC channel that runs on the irc.freenode.net IRC network. And, in case you wondered, I'm DrBacchus. (I'm not a real doctor, but I play one on IRC.) To join this channel, you need to install an IRC client (XChat, MIRC, and bitchx are some of the more popular clients, although there are roughly 3 bazillion other ones, too) and enter the following commands:

/server irc.freenode.net
/join #apache

Here's the first snippet of my conversation with this user:

  -->b3g1nn3r has joined #apache
  <b3g1nn3r> Can anybody help me?
  <DrBacchus> That would depend entirely on the nature of
  your problem.
  <b3g1nn3r> Well, I'm using a .htaccess file,
  and it's not working.
  <DrBacchus> details?
  <fajita> You need to give us a few additional details.
  What, exactly, is happening, and how does this differ from what
  you expect to be happening? 

Perhaps the biggest challenge in troubleshooting Apache problems (or, really, any problem at all) is getting "customers" to clearly state what the problem is that they are experiencing. Most of the time, once we can persuade them to tell us exactly what is happening, and what they are trying to do, the solution winds up being fairly simple.

    <b3g1nn3r> I created a .htaccess file and
    put some directives in it, but when I load pages from that
    directory, it appears that the .htaccess file is
    being ignored.
    <DrBacchus> What is AllowOverride set to?
    <b3g1nn3r> AllowOverride None
    <fajita> AllowOverride None means "Please ignore my
    htaccess files."

The AllowOverride directive controls the use of .htaccess files. These are files that permit users who don't have access to the main server-configuration file to override the configuration settings on the server for particular directories.

Since many server admins don't want users to override this configuration, the default Apache configuration file does not permit .htaccess files. Or, stated differently, we want server admins to have to make the conscious choice to permit this feature, rather than having it enabled by default. And so the default configuration file contains AllowOverride None for most scopes, as Fajita noted.

    <b3g1nn3r> So what should I have it set to?
    <DrBacchus> That depends on what you are putting in your
    .htaccess file.

AllowOverride is not simply turned on or off. Rather, Apache configuration directives fall into a number of broad categories, and AllowOverride allows you to permit, or not permit, these categories of directives in .htaccess files.

Here are those categories, and what they mean:

AuthConfig	Directives related to authentication, such as AuthName and Require.
FileInfo	Directives about the file type, such as MIME type (e.g., AddType) or language (e.g., LanguagePriority).
Indexes	Directives relating to automatic directory listings, such as DirectoryIndex and ReadmeName.
Limit	Directives limiting access by host address (i.e., Order, Allow, and Deny).
Options	Allows the setting of the Options directive, and also the use of the XBitHack directive.

    <b3g1nn3r> AllowOverride All?
    <fajita> AllowOverride All is a really bad idea, because
    it implies AllowOverride Options, which lets people do stuff
    like Options FollowSymlinks and Options ExecCGI, even though
    they are explicitly disabled in the main config. 

While Fajita's opinion here is not necessarily the only view on the matter, it does reflect a common theme in sysadmining. Namely, only turn on the stuff that you need. There are probably cases where AllowOverride All is appropriate. But usually, what you really want to do is determine what is actually needed, and set AllowOverride to permit just the directives you are actually using. For example, if you are using the .htaccess file just to set a MIME type in a particular directory, then it is sufficient to set AllowOverride FileInfo.

    <b3g1nn3r> So, how do I know what to set AllowOverride to
    in a given situation?
    <DrBacchus> You look in the Apache documentation for that
    particular directive, and see what the Override
    field says. That's what you have to set
    AllowOverride to in order to permit that
    directive, and other related directives.

And, of course, some directives aren't allowed in .htaccess files at all. When considering a particular directive, there are two things that you should look for in the documentation. For example, if we look in the docs for the AuthType directive, we see the following:

AuthType Directive

• Syntax: AuthType Basic|Digest
• Context: directory, .htaccess
• Override: AuthConfig
• Status: core

The two pieces of information we're interested in here are the Context line, which says that this directive is permitted in .htaccess files, and the Override line, which says that AllowOverride would need to be set to AuthConfig in order for that to be permitted.

Many directives can't be put in .htaccess files at all. For example, it wouldn't make much sense to change the ServerName or Port of a server on a per-directory basis.

    <b3g1nn3r> Oh, thanks. Setting AllowOverride to the
    correct value made my .htaccess file work. Thanks for your
    help!
    <-- b3g1nn3r has left #apache

Of course, we never did know what b3g1nn3r was trying to do with his .htaccess file, but, in this particular case, it didn't actually matter.

In summary, here's what we learned:

1. Apache's default configuration file contains AllowOverride None, which causes .htaccess files to get ignored.

2. Each Apache configuration directive has documentation that tells you whether you can put that directive in a .htaccess file at all, and, if so, what you need to set AllowOverride in order to permit it.

Stay tuned. Next month we'll tackle another common Apache dilemma.

Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.

---

O'Reilly & Associates recently released (November 2003) Apache Cookbook.

• Sample Chapter 9, "Error Handling," is available free online.

• You can also look at the Table of Contents, the Index, and the full description of the book.

• For more information, or to order the book, click here.

---

Return to Apache DevCenter.