| Previous | Table of Contents | Next |
by Steve Burnett
By now you should have a running Web server, although it will be minimally configured. In this chapter, you learn about most of the functionality that comes bundled with the server. This chapter is organized as a series of tutorials so that if you’re new to Apache, you can get up to speed quickly. Toward the end of the chapter, you dive into some experimental Apache modules as well.
Because of its rapid pace of development, it’s possible that Apache will have some significantly new functionality by the time you read this chapter. However, the existing functionality isn’t likely to change much. The Apache Group has commitment to backward compatibility.
The srm.conf and access.conf files are where most of the configuration related to the actual objects on the server takes place. The srm.conf file is also known as the ResourceConfig file, which is a directive that can be set in httpd.conf; the access.conf file is also known as the AccessConfig file, which also is a directive in httpd.conf.
The names srm.conf and access.conf are mostly historical. At one point, when the server was still NCSA, the only thing access.conf was used for was setting permissions, restrictions, authentication, and so forth. Then, when directory indexing was added, the cry went out for the capability to control certain characteristics on a directory-by-directory basis. The access.conf file was the only configuration file that had any kind of structure for tight access control: the pseudo-HTML <Directory> container.
• See “access.conf,” p. 677
With Apache’s configuration file-parsing routines, most directives can literally appear anywhere—for example, within <Directory> containers in access.conf, within <VirtualHost> containers in httpd.conf, and so on. However, for sanity’s sake, you should keep some structure to the configuration files. You should put server-processing-level configuration options (such as Port and <VirtualHost> containers) in httpd.conf, generic server resource information (such as Redirect, AddType, and directory indexing information) in srm.conf, and per-directory configurations in access.conf.
In addition to the <Directory> container is the <Limit> container, which is used within <Directory> containers to specify certain HTTP methods to which particular directives apply. Examples are given later in this chapter.
NOTE: Although this chapter is still useful, release 1.3.0 and higher of Apache include a GNU Autoconf-style front-end, which supports all previous configuration options as well as the enhancements in 1.3.0 and above. Use of that interface for configuration is recommended in general.
Before you get too deep into the different configuration options, look at a mechanism that controls configuration on a directory-by-directory basis. This is accomplished by using a configuration file that’s local to the directory that you want to configure. You can already control subdirectory options in access.conf, as outlined in Chapter 35, “Getting Started with Apache.” However, for several reasons, you may want to allow these configurations to be maintained by users other than those with the power to restart the server (such as users maintaining their home pages). For that purpose the AccessFileName directive was invented.
• See “Performing a Basic Configuration,” p. 674
The default AccessFileName is .htaccess. If you want to use something else—for example, .acc—you would say the following in the srm.conf file:
AccessFileName .acc
If looking for the AccessFileName file is enabled and a request comes in that translates to the file /www/htdocs/path/path2/file, the server will look for /.acc, /www/.acc, /www/htdocs/.acc, /www/htdocs/path/.acc, and /www/htdocs/path/path2/.acc in that order. Also, if it finds the file, the server will parse the file to see what configuration options apply. (Remember that this parsing has to happen with each hit, separately, so this can be a big performance hit.) You can turn off the AccessFileName directive by setting the following options in your access config file:
<Directory /> AllowOverride None </Directory>
For the sake of brevity and clarity, assume that the AccessFileName option has set the name of these files to be .htaccess. What options can these files affect? The AllowOverride directive controls the range of available options within the <Directory> container in the AccessConfig file, as mentioned previously. Table 36.1 lists the exact arguments for AllowOverride.
| Argument | Result |
|---|---|
| AuthConfig | When listed, .htaccess files can specify their own authentication directives, such as AuthUserFile, AuthName, AuthType, and require. |
| FileInfo | When listed, .htaccess can override any settings for meta-information about files by using directives such as AddType, AddEncoding, and AddLanguage. |
| Indexes | When listed, .htaccess files can locally set directives that control the rendering of the directory indexing, as implemented in the mod_dir.c module—for example, FancyIndexing, AddIcon, and AddDescription. |
| Limit | This argument allows the use of the directives that limit access based on host name or host IP number (allow, deny, and order). |
| Options | This argument allows the use of the Options directive. |
| All | This argument allows all of the preceding arguments to be true. |
AllowOverrideoptions aren’t merged, meaning that if the configuration for /path/ is different than the configuration for /, the /path/ one will take precedence because it’s deeper.
| Previous | Table of Contents | Next |