Configuring the Apache Server

The primary file for configuring your Apache Web server is httpd.conf (located in the /etc/httpd/conf directory). A few years ago, the Apache project began recommending not using additional configuration files, such as srm.conf and access.conf, and simply put everything in httpd.conf. In recent releases, however, there has been a trend toward having modules and other components that are used with Apache have their own configuration files (usually located in the /etc/httpd/conf.d directory).

All Apache configuration files are plain-text files and can be edited with your favorite text editor. The /etc/httpd/conf/httpd.conf file is reproduced in its entirety in the following section, with explanations inserted after related blocks of options (intended to supplement the comments provided with each file).

Some individual modules, scripts and other services related to Apache, such as perl, php, ssl, webalizer, and mysql, have individual configuration files that may interest you. Those files are contained in the /etc/httpd/conf.d directory. The "Configuring modules (/etc/httpd/conf.d/*.conf)" section later in this chapter discusses modules and related features.


More information on Apache can be obtained on your own Web server, from http://localhost/manual/ (if the httpd-manual package is installed).

Configuring the Web server (httpd.conf)

The httpd.conf file is the primary configuration file for the Apache Web server. It contains options that pertain to the general operation of the server. The default filename (/etc/httpd/conf/httpd.conf) can be overridden by the -f filename command-line argument to the httpd daemon or the ServerConfigFile directive. The following sections list the contents of the httpd.conf file and describe how to use the file.

The first section contains comments about the httpd.conf file:

#  # Based on the NCSA server configuration files originally by Rob McCool      #  # This is the main Apache server configuration file. It contains the  # configuration directives that give the server its instructions.  # See <URL:> for detailed information   # about the directives.  #  # Do NOT simply read the instructions in here without understanding  # what they do.  They're here only as hints or reminders.  If you are   # unsure consult the online docs. You have been warned.  #  # The configuration directives are grouped into three basic sections:  #  1. Directives that control the operation of the Apache server   #     process as a whole (the 'global environment').  #  2. Directives that define parameters of the main or default server,  #     which responds to requests that aren't handled by a virtual host.  #     These directives also provide default values for the settings  #     of all virtual hosts.  #  3. Settings for virtual hosts, which allow Web requests to be sent   #     to different IP addresses or hostnames and have them handled by   #     the same Apache server process.  #  # Configuration and logfile names: If the filenames you specify for   # many of the server's control files begin with "/" (or "drive:/" for   # Win32), the server will use that explicit path.  If the filenames do   # *not* begin with "/", the value of ServerRoot is prepended -- so   # "logs/foo.log"with ServerRoot set to "/usr/local/apache" will be   # interpreted by the server as "/usr/local/apache/logs/foo.log".  #  

This section consists entirely of comments. It basically tells you how information is grouped together in this file and how the httpd daemon accesses this file. By default, log files are in the /var/log/httpd directory.

Setting the global environment

In “Section 1: Global Environment” of the httpd.conf file, you set directives that affect the general workings of the Apache server. Here is what the different directives are for:

### Section 1: Global Environment  #  # The directives in this section affect overall operation of Apache,  # such as the number of concurrent requests it can handle or where it  # can find its configuration files.  # 

Revealing subcomponents

The ServerTokens directive lets you prevent remote computers from finding out what subcomponents you are running on your Apache server. Comment out this directive if you don’t mind exposing this information. To prevent exposure, ServerTokens is set as follows:

#  # Don't give away too much information about all the subcomponents  # we are running. Comment out this line if you don't mind remote sites  # finding out what major optional modules you are running  ServerTokens OS  

Setting the server root directory

The ServerRoot directive specifies the directory that contains the configuration files, a link to the log file directory, and a link to the module directory. An alternative ServerRoot path name can be specified using the -d command-line argument to httpd.

# ServerRoot: The top of the directory tree under which the server's  # configuration, error, and log files are kept.  #  # NOTE! If you intend to place this on an NFS (or other network) mounted  # filesystem then please read the LockFile documentation (available  # at <URL:>);  # you will save yourself a lot of trouble.  #  # Do NOT add a slash at the end of the directory path.  #  ServerRoot "/etc/httpd" 

Storing the server’s PID file

The Apache Web server keeps track of the PID for the running server process. You can change the locations of this file using the entry described next:

#  # PidFile: The file in which the server should record its process  # identification number when it starts.  #  PidFile run/ 

Apache uses the PidFile to store the process ID of the first (root-owned) master daemon process. This information is used by the /etc/init.d/httpd script when shutting down the server and also by the server-status handler (as described later).

Configuring timeout values

You can set several values that relate to timeout. Some of these values are described in the text following the code:

#  # Timeout: The number of seconds before receives and sends time out.  #  Timeout 120      #  # KeepAlive: Whether or not to allow persistent connections (more than  # one request per connection). Set to "Off" to deactivate.  #  KeepAlive Off      #  # MaxKeepAliveRequests: The maximum number of requests to allow  # during a persistent connection. Set to 0 to allow unlimited amount.  # We recommend you leave this number high, for maximum performance.  #  MaxKeepAliveRequests 100      #  # KeepAliveTimeout: Number of seconds to wait for the next request from  # the same client on the same connection.  #  KeepAliveTimeout 15  

The Timeout directive determines the number of seconds that Apache will hold a connection open between the receipt of packets, between the receipt of acknowledgments on sent responses, or while receiving an incoming request. The default of two minutes (120 seconds) can be lowered if you find an excessive number of open, idle connections on your machine.

The KeepAlive directive instructs Apache to hold a connection open for a period of time after a request has been handled. This enables subsequent requests from the same client to be processed faster, as a new connection doesn’t need to be created for each request.

The MaxKeepAliveRequests directive sets a limit on the number of requests that can be handled with one open connection. The default value is certainly reasonable because most connections will hit the KeepAliveTimeout before MaxKeepAliveRequests.

The KeepAliveTimeout directive specifies the number of seconds to hold the connection while awaiting another request. You might want to increase the default (15 seconds). Reasons for having a longer timeout could be to allow all the images on the page to be downloaded on the same connection or to take into account how long it may take a client to peruse your average page and select a link from it. The Web application you are using may also need a longer persistent connection. (Of course, a longer KeepAliveTimeout prevents each server from moving on to another client during this time period, so you may find that you need to add more request processes to account for that.)

Setting the number of server processes

To operate efficiently, a Web server has to be able to handle lots of incoming requests for content simultaneously. To be ready for requests for Web content, Apache (as it is set up in Fedora) has multiple server processes (httpd daemons) running and listening to service requests. Those servers can, in turn, direct requests to multiple threads to service the content requests.

With the Multi-Processing Module (MPM) feature (introduced in Apache 2.0), support for threads was added to Apache. On an operating system that supports Native POSIX Thread Libraries (which Fedora Core 3 does), threading allows Apache to improve performance by needing fewer process slots and less memory for the number of servers it needs. Adding threads consumes fewer resources than adding processes.

For a low-volume Web server, you can probably leave the parameters alone that support the MPM feature. You will probably have enough processes to handle your incoming requests, but not so many that they will be a drain on your server. However, if your server needs to serve up lots of content consistently, or needs to respond occasionally to large spikes of requests, you should consider tuning the MPM-related parameters in the httpd.conf file.

Here are a few issues to consider if you want to change any of the MPM-related parameters:

  • RAM is critical — Every process and thread that is active consumes some amount of memory. If the number of active processes and threads goes beyond the amount of RAM you have, your computer will begin to use swap space and performance will degrade quickly. Make sure this is enough RAM on your system to handle the maximum number of server processes and threads you expect to run on your Apache Web server.

  • Configure for maximum load — Apache is able to create new server processes and threads as they are needed. You don't need to have the maximum number of processes and threads available at all times. Instead, you can configure the maximum number of servers and threads that Apache can dynamically add as demand on the server requires.

  • Configure for performance — Performance degrades when Apache has to start a new thread (small amount), start a server process (greater amount), or use swap space (greatest amount). In the perfect world, the exact number of servers you need should be the default number of servers running, with a few spares to handle reasonable spikes. If response is critical, you might opt to have more servers running than you need so that performance isn't hurt when spikes come.

When Apache starts up, it launches a set number of httpd server processes (one parent and multiple child httpd processes) to handle incoming requests for content for the Web server. Parameters for defining how many httpd server processes are available include those that set:

  • How many child server processes should be started by the parent httpd server (StartServers)

  • The minimum number of server processes kept spare (MinSpareServers)

  • The maximum number of server processes kept spare (MaxSpareServers)

  • The maximum value MaxClients can be over the life of the server (ServerLimit)

  • The maximum number of server processes allowed to start (MaxClients)

  • The maximum number of requests a process can serve (MaxRequestsPerChild)

Parameters for defining how many threads are available for each httpd server process include those that set:

  • The minimum number of spare threads that should always be available, after which more will be created (MinSpareThreads)

  • The maximum number for spare threads, after which active threads will be deleted to get back to the number of threads per child (MaxSpareThreads)

  • The number of threads always available to each child process (ThreadsPerChild)

The following code example shows how MPM-specific parameters in the httpd.conf file are set for the prefork.c module (non-threaded module for managing servers processes) and worker.c (multi-thread, multi-process Web server module).

##  ## Server-Pool Size Regulation (MPM specific)  ##  <IfModule prefork.c>  StartServers       8  MinSpareServers    5  MaxSpareServers   20  ServerLimit      256  MaxClients       256  MaxRequestsPerChild 4000  </IfModule>      <IfModule worker.c>  StartServers        2  MaxClients        150  MinSpareThreads    25  MaxSpareThreads    75  ThreadsPerChild    25  MaxRequestsPerChild 0  </IfModule> 

Apache starts a master daemon process owned by root that binds to the appropriate port, then switches to a nonprivileged user. More servers (equivalent to the value of the StartServers directive in prefork.c) will then be started as the same nonprivileged user (the apache user in this case).

Apache attempts to intelligently start and kill servers based on the current load. If the amount of traffic decreases and there are too many idle servers, some will be killed (down to the number of servers noted in MinSpareServers). Similarly, if many requests arrive in close proximity and there are too few servers waiting for new connections, more servers will be started (up to the number of servers noted in MaxClients).


Getting the value of MaxClients right is critical, because it puts a lid on the total number ofsimultaneous client connections that can be active at a time. If the number of MaxClients servers are in use, no more will be created and subsequent requests to the server will fail.

Using the values specified above, when the daemon is started, the parent and eight child server processes will run, waiting for connections (as defined by StartServers). As more requests arrive, Apache will ensure that at least five server processes are ready to answer requests. When requests have been fulfilled and no new connections arrive, Apache will begin killing processes until the number of idle Web server processes is below 20. The value of StartServers should always be somewhere between MinSpareServers and MaxSpareServers.

Apache limits the total number of simultaneous threads with the MaxClients directive. The default value is 150, which should be sufficiently high. However, if you find that you frequently have nearly that many threads running, remember that any connection beyond the 150th will be rejected. In such cases, if your hardware is sufficiently powerful (and if your network connection can handle the load), you should increase the value of MaxClients.


You can see the state of your Apache server processes and get a feel for the server's activity by viewing the server-status page for your server, as described later in this chapter.

To minimize the effect of possible memory leaks (and to keep the server pool “fresh”), each server process is limited in the number of requests that it can handle (equal to the value of MaxRequestsPerChild). After servicing 4000 requests (the value specified above), the process will be killed. It is even more accurate to say that each process can service 4000 connections because all KeepAlive requests (occurring prior to encountering a KeepAliveTimeout) are calculated as just one request.

In a multiprocessor environment, setting thread values described previously can both limit the number of threads that servers can consume and supply as many threads as you will allow to handle server processing. MinSpareThreads and MaxSpareThreads control the number of threads available that are not being used. More are added if available threads fall below MinSpareThreads. If spare threads go above MaxSpareThreads, some are dropped.

Binding to specific addresses

You can bind to specific IP addresses using the Listen directive. Listen directives can be used to add to the default bindings you already have:

# Listen: Allows you to bind Apache to specific IP addresses and/or  # ports, in addition to the default. See also the <VirtualHost>  # directive.  #  # Change this to Listen on specific IP addresses as shown below to  # prevent Apache from glomming onto all bound IP addresses (  #Listen  Listen 80 

The Listen directive is more flexible than the BindAddress and Port directives. Multiple Listen commands can be specified, enabling you to specify several IP address/port number combinations. It can also be used to specify just IP addresses (in which case the Port directive is still necessary) or just port numbers. By default, Apache listens to port 80 (for standard http services) and port 443 (for secure https services) on all interfaces on the local computer (which is where Web browsers expect to find Web content).

Including module-specific configuration files

The following lines cause Apache to load configuration files from the /etc/httpd/conf.d directory. This directory contains configuration files associated with specific modules.

#  # Load config files from the config directory "/etc/httpd/conf.d".  #  Include conf.d/*.conf 


The “Configuring modules (/etc/httpd/conf.d/*.conf)” section, later in this chapter, describes some of the configuration files in the conf.d directory that may interest you.

Selecting modules in httpd.conf

During the compilation process, individual Apache modules can be selected for dynamic linking. Dynamically linked modules are not loaded into memory with the httpd server process unless LoadModule directives explicitly identify those modules to be loaded. The blocks of code that follow select several modules to be loaded into memory by using the LoadModule directive with the module name and the path to the module (relative to ServerRoot). The following text shows a partial listing of these modules:

#  # Dynamic Shared Object (DSO) Support  # Example:  # LoadModule foo_module modules/  #  LoadModule access_module modules/  LoadModule auth_module modules/  LoadModule auth_anon_module modules/  LoadModule auth_dbm_module modules/  LoadModule auth_digest_module modules/  LoadModule include_module modules/  LoadModule log_config_module modules/  LoadModule env_module modules/  LoadModule mime_magic_module modules/        .        .        .  LoadModule actions_module modules/  LoadModule speling_module modules/  LoadModule userdir_module modules/  LoadModule alias_module modules/  LoadModule rewrite_module modules/ 

Apache modules are included in the list of active modules via the LoadModule directive. The ClearModuleList directive removes all entries from the current list of active modules. Each of the standard modules that come with Apache is described in Table 21-1.

Table 21-1: Dynamic Shared Object (DSO) Modules




Provides access control based on originating host name/IP address.


Conditionally executes CGI scripts based on the file’s MIME type or the request method.


Allows for redirection and mapping parts of the physical file system into logical entities accessible through the Web server.


Enables files to be transferred without adding any HTTP headers (for example, the Status, Location, and Content-type header fields).


Provides access-control based on user name/password pairs. The authentication information is stored in a plain-text file, although the password is encrypted using the crypt()system call.


Similar to anonymous FTP, this module enables predefined user names access to authenticated areas by using a valid e- mail address as a password.


Provides access control based on user name/password pairs. The authentication information is stored in a DBM binary database file, with encrypted passwords.


Provides MD5 Digest user authentication.


Lets you use an LDAP directory to store the HTTP Basic authentication database.


Implements automatically generated directory indexes.


Allows local or proxied Web content to be cached. Used with the mod_disk_cache or mod_file_cache modules.


Offers a method of emulating CERN HTTPD meta file semantics.


Controls the execution of files that are parsed by the “cgi- script” handler or that have a MIME type of x-httpd-cgi. ScriptAlias sets the default directory.


Provides Web-based Distributed Authoring and Versioning (WebDAV) to upload Web content using copy, create, move, and delete resources.


Used to provide file system features to the mod_dav module.


Includes the DEFLATE output filter, to compress data before it is sent to the client.


Sets the list of filenames that may be used if no explicit filename is selected in a URL that references a directory.


Enables a disk-based storage manager to use with mod_proxy.


Controls environment variables passed to CGI scripts.


Implements time limits on cached documents by using the Expires HTTP header.


Allows caching of frequently requested static files.


Enables the creation and generation of custom HTTP headers.


Controls inline image map files, which have a MIME type of x- httpd-imap or that are parsed by the imap handler.


Implements Server-Side Includes (SSI), which are HTML documents that include conditional statements parsed by the server prior to being sent to a client. This module also has the ability to include files one into another.


Provides a detailed summary of the server’s configuration, including a list of actively loaded modules and the current settings of every directive defined within each module.


Used to speed performance of Web sites using LDAP servers.


Enables a customized format for information contained within the log files.


Used with mod_cache to provide memory-based storage.


Alters the handling of documents based on predefined values or the MIME type of the file.


Similar to the UNIX file command, this module attempts to determine the MIME type of a file based on a few bytes of the file’s contents.


Provides for the conditional display of documents based on the Content-Encoding, Content-Language, Content-Length, and Content-Type HTTP header fields.


Implements an HTTP 1.1 proxy/gateway server.


Entension to mod_proxy to handle CONNECT requests.


Extension to mod_proxy to handle FTP requests.


Extension to mod_proxy to handle HTTP requests.


Provides a flexible and extensible method for redirecting client requests and mapping incoming URLs to other locations in the file system.


Conditionally sets environment variables based on the contents of various HTTP header fields.


Attempts to automatically correct misspellings in requested URLs.


Implements cryptography using SSL and TLS protocols.


Provides a summary of the activities of each individual httpd server process, including CPU and bandwidth usage levels.


Lets CGI scripts run with permission of a particular user or group.


Specifies locations that can contain individual users’ HTML documents.


Uses cookies to track the progress of users through a Web site.


Contains support for dynamically configured mass virtual hosting.

If a particular module contains features that are not necessary, it can easily be commented out of the preceding list. Similarly, you might want to add the features or functionality of a third- party module (for example, mod_perl, which integrates the Perl runtime library for faster Perl script execution, or mod_php, which provides a scripting language embedded within HTML documents) by including those modules in the list.

More information about each module (and the directives that can be defined within it) can be found on your server at http://localhost/manual/mod/.

Setting the main server’s configuration

The second section of the http.conf file relates to directives handled by your main server. In other words, these values are used in all cases except when they are changed in virtual host definitions. To change the same directives for particular virtual hosts, add them within virtual host containers.

Choosing the server’s user and group

The httpd daemon doesn’t have to run as the root user; in fact, your system is more secure if it doesn’t. By setting User and Group entries, you can have the httpd daemon run using the permissions associated with a different user and group:

# If you wish httpd to run as a different user or group, you must run  # httpd as root initially and it will switch.  #  # User/Group: The name (or #number) of the user/group to run httpd as.  # . On SCO (ODT 3) use "User nouser" and "Group nogroup".  # . On HPUX you may not be able to use shared memory as nobody, and  # the suggested workaround is to create a user www and use that user.  # NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)  # when the value of (unsigned)Group is above 60000;  # don't use Group #-1 on these systems!  #  User apache  Group apache  

By default, apache is defined as both the user and group for the server. If you change the User and Group directives, you should specify a nonprivileged entity. This minimizes the risk of damage if your site is compromised. The first daemon process that is started runs as root. This is necessary to bind the server to a low-numbered port and to switch to the user and group specified by the User and Group directives. All other processes run under the user ID (UID) and group ID (GID) defined by those directives.

Choosing the HTTP port number

Apache listens on particular ports for HTTP requests. The port that is used is set by the Port entry as follows:

#  # Port: The port to which the standalone server listens. For  # ports < 1023, you will need httpd to be run as root initially.  #  Port 80 

Port 80 is the default for HTTP traffic, which is why is the same as If the server is bound to a different port, the port number must be specified in the URL. Most Web servers run on port 80, although they can accept connections on any port (up to 65535) that is not already bound to a particular service (see the /etc/services file for a list of common services and protocols and the ports they use). Only root can run programs that listen for connections on privileged ports (those below 1024).

Setting an e-mail address

You can identify an address where users can send e-mail if there is a problem with your server. This is done with the ServerAdmin directive:

#  # ServerAdmin: Your address, where problems with the server should be  # e-mailed. This address appears on some server-generated pages, such  # as error documents. e.g.  #  ServerAdmin you@your.address  

The ServerAdmin directive can be set to any valid e-mail address. The default is root@localhost.

Setting the server name

If your server name is anything but your exact registered host or domain name, you should identify your server name here. As the comments point out, the ServerName directive can be set to a value other than the actual host name of your machine. However, this other name should still point to your machine in DNS if the server is to be a public Internet server. Frequently, www is just an alias for the real name of the machine (for example, a machine may respond to, but its real name may be


Apache tries to use your host name as the ServerName if you don’t enter a valid server name. It is recommended that you explicitly enter a ServerName here.

Setting canonical names

Use the UseCanonicalName directive to create a self-referencing URL, as follows:

## UseCanonicalName: Determines how Apache constructs self-referencing  # URLs and the SERVER_NAME and SERVER_PORT variables.  # When set "Off", Apache will use the Hostname and Port supplied  # by the client. When set "On", Apache will use the value of the  # ServerName directive.  #  UseCanonicalName Off 

The UseCanonicalName directive provides a form of naming consistency. When it is set to On, Apache uses the ServerName and Port directives to create a URL that references a file on the same machine (for example, When UseCanonicalName is Off, the URL consists of whatever the client specified (for example, the URL could be or http://al/docs/ if the client is within the same domain).

This can be problematic, particularly when access-control rules require user name and password authentication: if the client is authenticated for the host but a link sends him or her to (physically the same machine), the client will be prompted to enter a user name and password again. It is recommended that UseCanonicalName be set to On. In the preceding situation, the authentication would not need to be repeated, because any reference to the same server would always be interpreted as

Identifying HTTP content directories

There are several directives for determining the location of your server’s Web content. The main location for your Web content is set to /var/www/html by the DocumentRootdirective. (Note that this location has changed from versions of Red Hat Linux prior to Red Hat Linux 7. The location was formerly in /home/http.)

# DocumentRoot: The directory out of which you will serve your  # documents. By default, all requests are taken from the directory, but  # symbolic links and aliases may be used to point to other locations.  DocumentRoot "/var/www/html" 

Setting access options and overrides

You can set individual access permissions for each directory in the Web server’s directory structure. The default is fairly restrictive. Here is the default:

<Directory />      Options FollowSymLinks      AllowOverride None  </Directory> 

This segment sets up a default block of permissions for the Options and AllowOverride directives. The <Directory /> . . . </Directory> tags enclose the directives that are to be applied to the / directory (which is /var/www/html by default, as defined by DocumentRoot).

The Options FollowSymLinks directive instructs the server that symbolic links within the directory can be followed to allow content that resides in other locations on the computer. None of the other special server features will be active in the / directory, or in any directory below that, without being explicitly specified later. Next, the following access options are specifically set for the root of your Web server (/var/www/html). (I removed the comments here for clarity.)

<Directory "/var/www/html">     Options Indexes FollowSymLinks     AllowOverride None     Order allow,deny     Allow from all  </Directory> 

If you have changed the value of DocumentRoot earlier in this file, you need to change the /var/www/html to match that value. The Options set for the directory are Indexes and FollowSymLinks. Those and other special server features are described in Table 21-2. The AllowOverride None directive instructs the server that an .htaccess file (or the value of AccessFileName) cannot override any of the special access features. You can replace None with any of the special access features described in Table 21-3.


Remember that unless you specifically enable a feature described in Tables 21-2 and 21-3, that feature is not enabled for your server (with the exceptions of Indexes and FollowSymLinks).

Table 21-2: Special Server Features for the Options Directive




The execution of CGI scripts is permitted.


The server will traverse symbolic links.


Server-Side Includes are permitted.


Server-Side Includes are permitted, except the #exec element.


If none of the files specified in the DirectoryIndex directive exists, a directory index will be generated by mod_autoindex.


The server allows content negotiation based on preferences from the user's browser, such as preferred language, character set, and media type.


The server will traverse symbolic links only if the owner of the target is the same as the owner of the link.


None of the features above are enabled.


All the features above are enabled, with the exception of MultiViews. This must be explicitly enabled.

Table 21-3: Special Access Features for the AllowOverride Directive




Enables authentication-related directives (AuthName, AuthType, AuthUserFile, AuthGroupFile, Require, and so on).


Enables MIME-related directives (AddType, AddEncoding, AddLanguage, LanguagePriority, and so on).


Enables directives related to directory indexing
(FancyIndexing, DirectoryIndex, IndexOptions, IndexIgnore, HeaderName, ReadmeName, AddIcon, AddDescription, and so on).


Enables directives controlling host access (Allow, Deny, and Order).


Enables the Options directive (as described in Table 21-5).


None of the access features above can be overridden.


All the access features above can be overridden.

Disabling indexes in root directory

The following directives disable indexing for the root directory (probably /var/www/html), so that your index.html, or the default one put there by the Fedora Project, is displayed when that directory is requested. (The default way of listing the contents of directories on your Apache Web server is defined in the "Defining Indexing" section later in this chapter).

#  # Disable autoindex for the root directory, and present a  # default Welcome page if no other index page is present.  #  <LocationMatch "^/$>      Options -Indexes      ErrorDocument 403 /error/noindex.html  </LocationMatch> 

Identifying user directories

If you have multiple users on your server and you want each to be able to publish their own Web content, it is common practice to identify a directory name that users can create in their own home directories to store that content. When you identify the name that is appended to a user’s home directory, that directory is used to respond to requests to the server for the user’s name(~user). This directory name used to be set to public_html by default; however, it is now turned off by default.

To allow access to your users’ personal Web pages, add a comment character (#) to the UserDir disable line. Then remove the # from the UserDir public_html line to make users’ personal public_html directories accessible through the Web server. After removing extra comment lines, the following text shows what the enabled section looks like:

# UserDir: The name of the directory which is appended onto a user's   # home directory if a ~user request is received.      <ifModule mod_userdir.c>  #  UserDir disable  UserDir public_html  </IfModule> 

Besides uncommenting the UserDir public_html line shown in the previous example, you must make both the user’s home directory and public_html directory executable by everyone in order for the UserDir directive to allow access to a particular user’s public_html directory. For example, the user cjb could type the following to make those directories accessible.

 $ chmod 711 /home/cjb $ mkdir /home/cjb/public_html  $ chmod 755 /home/cjb/public_html 

For UserDir to work, the mod_userdir module must also be loaded (which it is by default).

There are two ways in which the UserDir directive can handle an incoming request that includes a user name (for example, ~cjb). One possible format identifies the physical path name of the individual users’ publicly accessible directories. The other can specify a URL to which the request is redirected. A few examples are presented in Table 21-4, using the URL as a sample request.

Table 21-4: UserDir Path Name and URL Examples

UserDir Directive

Referenced Path or URL

UserDir public_html









The UserDir directive can also be used to explicitly allow or deny URL-to-path name translation for particular users. For example, it is a good idea to include the following line to avoid publishing data that shouldn’t be made public:

UserDir disable root 

Alternatively, use the following lines to disable the translations for all but a few users:

UserDir disable  UserDir enable wilhelm cjb jsmith 

The DirectoryIndex directive establishes a list of files that is used when an incoming request specifies a directory rather than a file. For example, a client requests the URL Because it’s a directory, it is automatically translated to Now that directory is searched for any of the files listed in the DirectoryIndex directive. The first match (from the default list of index.html and index.html.var) is used as the default document in that directory. If none of the files exist and the Indexes option (as in the httpd.conf file) is selected, the server will automatically generate an index of the files in the directory.

# DirectoryIndex: sets the file that Apache will serve if a directory  # is requested.  #  # The index.html.var file (a type-map) is used to deliver content-  # negotiated documents. The MultiViews Option can be used for the  # same purpose, but it is much slower.  #  DirectoryIndex index.html index.html.var  

Setting directory-access control

You and your users can add an access file to each directory to control access to that directory. By default, the AccessFileName directive sets .htaccess as the file containing this information. The following lines set this filename and prevent the contents of that file from being viewed by visitors to the Web site. If you change the file to a name other than .htaccess, be sure to change the line below ("^\.ht") that denies access to that file.

#  # AccessFileName: The name of the file to look for in each directory  # for access control information.  #  AccessFileName .htaccess      <Files ~ "^\.ht">      Order allow,deny      Deny from all  </Files> 

You can add the same access directives to a .htaccess file as you do to the httpd.conf file. In general, it is more efficient to use a <Directory> directive in the httpd.conf file than it is to create a .htaccess file. With a <Directory> directive, you can specifically identify the access associated with that directory alone. Because directives you put in .htaccess apply to all directories below the current directory, any time you add a .htaccess file to a directory, Apache must search all directories above that point (for example, /, /var, /var/www. and so on) to include settings from possible .htaccess files in those directories as well.

Setting MIME-type defaults

The location of the MIME type definitions file is defined by the TypesConfig directive. The DefaultType directive sets the MIME type:

# TypesConfig describes where the mime.types file (or equivalent) is  # to be found.  #  TypesConfig /etc/mime.types      #  # DefaultType is the default MIME type the server will use for a  # document if it cannot otherwise determine one, such as from filename.  # extensions If your server contains mostly text or HTML documents,  # "text/plain" is a good value. If most of the content is binary, such  # as applications or images, you may want to use "application/octet-  # stream" instead to keep browsers from trying to display binary files  # as though they are text.  #  DefaultType text/plain  

Using the mod_mime_magic module, a server can look for hints to help figure out what type of file is being requested. You must make sure this module is loaded to Apache for it to be used (it is loaded by default). The module can use hints from the /usr/share/magic.mime (off by default) and /etc/httpd/conf/magic (on by default) files to determine the contents of a requested file. Here are the directives that cause that module to be used:

<IfModule mod_mime_magic.c>  #    MIMEMagicFile /usr/share/magic.mime       MIMEMagicFile conf/magic  </IfModule> 

Setting host name lookups

With the Apache Web server, you can have the server look up addresses for incoming client requests. Turning on the HostnameLookups entry can do this:

# HostnameLookups: Log the names of clients or just their IP addresses  HostnameLookups Off 

If the HostnameLookups directive is turned on, every incoming connection will generate a DNS lookup to translate the client’s IP address into a host name. If your site receives many requests, the server’s response time could be adversely affected. The HostnameLookups should be turned off unless you use a log file analysis program or statistics package that requires fully qualified domain names and cannot perform the lookups on its own. The logresolve program that is installed with the Apache distribution can be scheduled to edit log files by performing host name lookups during off-peak hours.

Configuring HTTP logging

You can set several values related to logging of Apache information. When a relative path name is shown, the directory set by ServerRoot (/etc/httpd/ by default) is appended (for example, /etc/httpd/logs/error_log). As shown in the following example, you can set the location of error logs, the level of log warnings, and some log nicknames:

#  # ErrorLog: The location of the error log file.  # If you do not specify an ErrorLog directive within a <VirtualHost>  # container, error messages relating to that virtual host will be  # logged here. If you *do* define an error logfile for a <VirtualHost>  # container, that host's errors will be logged there and not here.  #  ErrorLog logs/error_log      #  # LogLevel: Control the number of messages logged to the error_log.  # Possible values include: debug, info, notice, warn, error, crit,  # alert, emerg.  #  LogLevel warn      #  # The following directives define some format nicknames for use with  # a CustomLog directive (see below).  #  LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"\"%{User-       Agent}i\""combined  LogFormat "%h %l %u %t \"%r\" %>s %b" common  LogFormat "%{Referer}i -> %U" referer  LogFormat "%{User-agent}i" agent      #  # Location and format of the access logfile (Common Logfile Format).  # If you do not define any access logfiles within a <VirtualHost>  # container, they will be logged here. Contrariwise, if you *do*  # define per-<VirtualHost> access logfiles, transactions will be  # logged therein and *not* in this file.  #  # CustomLog logs/access_log common      # If you would like to have agent and referer logfiles, uncomment the  # following directives.  #  #CustomLog logs/referer_log referer  #CustomLog logs/agent_log agent      #  # For a single logfile with access, agent, and referer information  # (Combined Logfile Format), use the following directive:  #  CustomLog logs/access_log combined 

These lines deal with how server errors, client tracking information, and incoming requests are logged. The ErrorLog directive, which can specify an absolute path name or a path name relative to the ServerRoot (which is /etc/httpd by default), indicates where the server should store error messages. In this case the specified file is logs/error_log, which expands to /etc/httpd/logs/error_log (which in reality is a symlink to the error_log file in the /var/log/httpd directory).

The LogLevel directive controls the severity and quantity of messages that appear in the error log. Messages can range from the particularly verbose debug log level to the particularly silent emerg log level. With debug, a message is logged anytime the configuration files are read, when an access-control mechanism is used, or if the number of active servers haschanged. With emerg, only critical system-level failures that create panic conditions for the server are logged.

The level specified by the LogLevel directive indicates the least-severe message that will be logged — all messages at that severity and above are recorded. For example, if LogLevel is set to warn, the error log will contain messages at the warn, error, crit, alert, and emerg levels. The default value of warn is a good choice for normal use (it will log only significant events that may eventually require operator intervention), but info and debug are perfect for testing a server’s configuration or tracking down the exact location of errors.

The four LogFormat lines define (for later use) four types of log file formats: combined, common, referer, and agent. The tokens available within the LogFormat directive are described in Table 21-5. The LogFormat definitions can be modified to your own personal preference, and other custom formats can be created as needed.

Table 21-5: Available Tokens within LogFormat




The IP address of the client machine.


The number of bytes sent to the client (excluding header information).


The contents of the environment variable VAR.


The filename referenced by the requested URL.


The host name of the client machine.


The contents of the specified header line in the HTTP request.


As reported by the identd daemon (if available), the user on the client machine who initiated the request.


The contents of the message Note from a different module.


The contents of the specified header line in the HTTP response.


The port number on which the request was received.


The PID of the server process that handled the request.


The actual HTTP request from the client.


The server response code generated by the request.


The current local time and date. The time format can be altered using %{Format}t, where Format is described in the strftime(3) man page.


The number of seconds required to fulfill the client request.


If access-control rules require user name and password authentication, this represents the user name supplied by the client.


The URL requested by the client.


The host name and domain name of the server according to the Domain Name System (DNS).


The host name and domain name of the server handling the request according to the ServerName directive.

The common format includes the client host’s name or IP address, the user name as reported by the ident daemon and the server’s authentication method (if applicable), the local time at which the request was made, the actual HTTP request, the server response code, and the number of bytes transferred. This format is a de facto standard among Web servers (and lately even among FTP servers).

For the purpose of connection tracking, the referer format stores the URL (from the same site or an external server) that linked to the document just delivered (relative to the ServerRoot). For example, if the page contained a link to your home page at, when a client accessed that link, the referer log on would look like: -> /linuxguy/bio.html 

This information can be used to determine which path each client took to reach your site.

The agent format stores the contents of the User-agent: HTTP header for each incoming connection. This field typically indicates the browser name and version, the language, and the operating system or architecture on which the browser was run. On a Pentium II running Fedora, Mozilla will produce the following entry:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) 

The combined format includes all the information from the other three log file formats into one line. This format is useful for storing all connection-related log entries in one centralized file.

The CustomLog directive assigns one of the defined LogFormat formats to a filename (again, specified as an absolute path name or a path name relative to the ServerRoot). The only uncommented definition assigns combined format to the /etc/httpd/logs/access_log file. To retain the agent or referer information separately, uncomment the definitions. Also, you could choose to comment out the CustomLog logs/access_log combined line and use the definition for the common format instead.

Adding a signature

Any page that is generated by the Apache server can have a signature line added to the bottom of the page. Examples of server-generated pages include a directory listing, error page, a status page, or an info page. The ServerSignature directive can be set to On, Off, or EMail. Here is how ServerSignature appears by default:

# Optionally add a line containing the server version and virtual  # host name to server-generated pages (error documents, FTP directory  # listings, mod_status and mod_info output etc., but not CGI generated  # documents).  # Set to "EMail" to also include a mailto: link to the ServerAdmin.  # Set to one of: On | Off | EMail  #  ServerSignature On 

With ServerSignature On, this line appears at the bottom of server-generated pages:

 Apache/2.0.48 (Fedora) Server at Port 80  

With ServerSignature set to EMail, a link to the Web page’s administrative e-mail account is added to the signature line (the server name becomes the link). If the directive is set to Off, the line doesn’t appear at all.

Aliasing relocated content

There are various ways to define alias content. These include the Alias and the ScriptAlias directives. Here are alias-related settings in httpd.conf (with comments removed):

#  # Aliases: Add here as many aliases as you need (with no limit). The  format is   # Alias fakename realname  #  Alias /icons/ "/var/www/icons/"       <Directory "/var/www/icons">      Options Indexes MultiViews      AllowOverride None      Order allow,deny      Allow from all  </Directory>       # ScriptAlias: This controls which directories contain server scripts.  ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"       # "/var/www/cgi-bin" should be changed to whatever your ScriptAliased  # CGI directory exists, if you have that configured.  #  <Directory "/var/www/cgi-bin">      AllowOverride None      Options None      Order allow,deny      Allow from all  </Directory>  

The Alias directive points to a file system location (not necessarily within the DocumentRoot ). For example, with the following line in place, requests for documents in /bigjob ( would result in the retrieval of /home/newguy/proj/index.html.

Alias /bigjob /home/newguy/proj 

The icons alias allows access to the Apache icons used by the Web server your Web site. The icons directory is accessible from the /var/www directory.

The ScriptAlias directive performs a related function, but directories that it aliases contain executable code (most likely CGI scripts). The syntax is the same as for the Alias directive. Pay special attention whenever you use ScriptAlias. Because ScriptAlias defines where scripts are located that can be run from Web content on the server, you should make sure that you only assign directories that contain scripts that are secured and won't open security holes in your system.

Redirecting requests for old content

As content changes on your Web server, some content will become obsolete while other content may move to a different place in the file system or to a different server. Using the Redirect directive, you can redirect requests for old content to new locations.

By default, there are no Redirect directives set for your Apache server. However, you can uncomment the following example and tailor it to your needs:

# Redirect permanent /foo 

Redirect can be used to instruct clients that the document they seek has moved elsewhere (to the same server or to an external location) by simply indicating the old and new locations. If the previous Redirect option were in place, a client’s attempt to access would redirect to

Besides using permanent as the service for Redirect (which results in a redirect status 301), you could instead use temp (a redirect status of 302), seeother (a replaced status of 303), or gone (a permanently removed status of 401). You could also give any status code between 300 and 399 as the service, which represent different error responses. (These numbers are HTTP error codes.)

Defining indexing

It’s possible to have your Apache server show different icons for different types of files. To use this feature, IndexOptions should be set to FancyIndexing, and AddIconByEncoding, AddIconByType, and AddIcon directives should be used:

# Directives controlling display of server-generated directory listings.      # FancyIndexing is if you want fancy directory indexing or standard.  # VersionSort is whether files containing version numbers should be  # compared in the natural way, so that `apache-1.3.9.tar' is placed  # before `apache-1.3.12.tar'.  #  IndexOptions FancyIndexing VersionSort NameWidth=*  #  # AddIcon* directives tell the server which icon to show for different  # files or filename extensions. These are only displayed for  # FancyIndexed directories.  #  AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip      AddIconByType (TXT,/icons/text.gif) text/*  AddIconByType (IMG,/icons/image2.gif) image/*  AddIconByType (SND,/icons/sound2.gif) audio/*  AddIconByType (VID,/icons/movie.gif) video/*      AddIcon /icons/binary.gif .bin .exe  AddIcon /icons/binhex.gif .hqx  AddIcon /icons/tar.gif .tar  AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv  AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip  AddIcon /icons/a.gif .ps .ai .eps  AddIcon /icons/layout.gif .html .shtml .htm .pdf  AddIcon /icons/text.gif .txt  AddIcon /icons/c.gif .c  AddIcon /icons/p.gif .pl .py  AddIcon /icons/f.gif .for  AddIcon /icons/dvi.gif .dvi  AddIcon /icons/uuencoded.gif .uu  AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl  AddIcon /icons/tex.gif .tex  AddIcon /icons/bomb.gif core      AddIcon /icons/back.gif ..  AddIcon /icons/hand.right.gif README  AddIcon /icons/folder.gif ^^DIRECTORY^^  AddIcon /icons/blank.gif ^^BLANKICON^^      #  # DefaultIcon: which icon to show for files which do not have an icon  # explicitly set.  #  DefaultIcon /icons/unknown.gif      #  # AddDescription: allows you to place short description after a file in  # server-generated indexes. These are only displayed for FancyIndexed  # directories.  # Format: AddDescription "description" filename  #  #AddDescription "GZIP compressed document" .gz  #AddDescription "tar archive" .tar  #AddDescription "GZIP compressed tar archive" .tgz      #  # ReadmeName: the name of the README file the server will look for by  # default, and append to directory listings.  #  # HeaderName is the name of a file which should be prepended to  # directory indexes.  #  ReadmeName README.html  HeaderName HEADER.html      #  # IndexIgnore is a set of filenames which directory indexing should  # ignore and not include in the listing. Shell-style wildcarding is  # permitted.  #  IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t  

The previous block of options deals with how server-generated directory indexes are handled. The IndexOptions FancyIndexing VersionSort NameWidth=* directive enables an autogenerated directory index to include several bits of information about each file or directory, including an icon representing the file type, the filename, the last modification time for the file, the file’s size, and a description of the file. Figure 21-2 shows an example of a directory using default FancyIndexing settings.

image from book
Figure 21-2:   Change how directories are displayed from Apache using IndexOptions.

The VersionSort option allows files that include version numbers to be sorted as would be most natural (so, for example, version-2 would come before version-10 with this option on). The NameWidth=* option allows filenames of any length to be displayed. You change the asterisk to a number representing the maximum number of characters that can be displayed in the Name column. If IndexOptions is not set to FancyIndexing, the index only lists the file’s name.

The AddIconByEncoding directive is used to configure the output of FancyIndexing. It causes a particular icon to be displayed for files matching a particular MIME encoding. In the AddIconByEncoding line in the previous example, compressed.gif (with an alternative image tag of "CMP" for browsers that don’t load images) will be displayed for files with a MIME encoding of x-compress and x-gzip. The AddIconByType directive has the same syntax but matches files based on their MIME type.

The AddIcon directive performs a similar function, but the icons are displayed based on a pattern in the filename. In the lines above, for example, bomb.gif will be displayed for files ending with core, and binary.gif will be displayed for files ending in .bin and .exe. The folder.gif icon represents a subdirectory.

If there is a conflict between the AddIcon, AddIconByEncoding, or AddIconByType directives, the AddIcon directive has precedence. The DefaultIcon directive specifies the image to be displayed (unknown.gif, according to the line above) if no previous directive has associated an icon with a particular file.

The HeaderName and ReadmeName directives specify files that will be inserted at the top and bottom of the autogenerated directory index, if they exist. Using the default values, the server first looks for HEADER.html, then HEADER, to include at the top of the "fancy index." At the end of the index, README.html or README (whichever is located first) is inserted.

The IndexIgnore directive specifies files that should not appear in an autogenerated directory index. The line above excludes:

  • Any filename starting with a dot and containing at least two additional characters.

  • Any filename ending with a tilde (~) or what is commonly called a hash mark (#) (typically used by text editors as temporary files or backup files).

  • Filenames beginning with HEADER or README (the files displayed at the top and bottom of the directory listing, according to the HeaderName and ReadmeName directives).

  • The RCS (Revision Control System) or CVS (Concurrent Versions System) directories.

Defining encoding and language

The AddEncoding directive lets you set compression definitions that can be used by browsers to encode data as it arrives. The AddLanguage directive lets you indicate the language of a document, based on its file suffix.

#  # AddEncoding: allows you to have certain browsers (Mosaic/X 2.1+)  # uncompress information on fly. Note: Not all browsers support this.  # Despite name similarity, the following Add* directives have nothing  # to do with the FancyIndexing customization directives above.  #  AddEncoding x-compress Z  AddEncoding x-gzip gz tgz      #  # DefaultLanguage and AddLanguage allows you to specify the language of  # a document. You can then use content negotiation to give a browser a  # file in a language it can understand.       .       .       .  # Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz)  # Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)  # Russian (ru)  #  AddLanguage da .dk  AddLanguage nl .nl  AddLanguage en .en  AddLanguage et .ee  AddLanguage fr .fr       .       .       .  # LanguagePriority: allows you to give precedence to some languages  # in case of a tie during content negotiation.  #  # Just list the languages in decreasing order of preference. We have  # more or less alphabetized them. You probably want to change this.  #  LanguagePriority en da nl et fr de el it ja ko no pl pt pt-br ru ltz ca          es sv tw  

The AddEncoding directive supplements or overrides mappings provided by the TypesConfig file (/etc/mime.types by default). Knowledge of the MIME type/encoding may allow certain browsers to automatically manipulate files as they are being downloaded or retrieved.

The AddLanguage directive performs similar mappings, associating a MIME language definition with a filename extension. The LanguagePriority directive determines the precedence if a particular file exists in several languages (and if the client does not specify a preference). Using the preceding definition, if the file index.html were requested from a directory that contained the files, index.html.en,, and, the index.html.en file would be sent to the client.

Using LanguagePriority, you can set which language is used in case a decision on what language to use can’t be made during content negotiation. If you are expecting multilanguage use of your Web content, you should check (and probably change) the priority here.

Choosing character sets

The default character set to use and character sets to use for files with particular file extensions are set using the AddDefaultCharset an AddCharset directives, respectively. Although UTF-8 is the default character set, it is recommended to set it here specifically (as shown). Other standard ISO fonts, as well as some nonstandard fonts, are set using AddCharset directives.

AddDefaultCharset UTF-8  #  AddCharset ISO-8859-1 .iso8859-1 .latin1  AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen  AddCharset ISO-8859-3 .iso8859-3 .latin3  AddCharset ISO-8859-4 .iso8859-4 .latin4  AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru  AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb          .          .          . 

You can retrieve an official list character sets and the file extensions that are assigned to them at

Adding MIME types and handlers

With the AddType directive, you can enhance the MIME types assigned for your Apache Web server without editing the /etc/mime.types file. With the AddHandler directive, you can map selected file extensions to handlers (that result in certain actions being taken):

# AddType allows you to add to or override the MIME configuration  # file mime.types for specific file types.      AddType application/x-tar .tgz  #  # For server-parsed imagemap files:  #  AddHandler imap-file map      #  # For type maps (negotiated resources):  # (This is enabled by default to allow the Apache "It Worked" page  # to be distributed in multiple languages.)  #  AddHandler type-map var 

Defining actions and headers

Some types of media can be set to execute a script when they are opened. Likewise, certain handler names, when opened, can be set to perform specified scripts. The Action directive can be used to configure these scripts:

# Action lets you define media types that execute a script whenever  # a matching file is called. This eliminates the need for repeated URL  # pathnames for oft-used CGI file processors.  # Format: Action media/type /cgi-script/location  # Format: Action handler-name /cgi-script/location 

The Action directive maps a CGI script to a handler or a MIME type, whereas the Script directive maps a CGI script to a particular HTTP request method (GET, POST, PUT, or DELETE). These options allow scripts to be executed whenever a file of the appropriate MIME type is requested, a handler is called, or a request method is invoked.

Customizing error responses

For different error conditions that occur, you can define specific responses. The responses can be in plain text, redirects to pages on the local server, or redirects to external pages:

#  # Customizable error responses come in three flavors:  # 1) plain text 2) local redirects 3) external redirects  #  # Some examples:  #ErrorDocument 500 "The server made a boo boo."  #ErrorDocument 404 /missing.html  #ErrorDocument 404 "/cgi-bin/"  #ErrorDocument 402  #  

As the comments suggest, the ErrorDocument directive can customize any server response code, redirecting it to an external page, a local file or CGI script, or to a simple text sentence. Table 21-6 lists the most common server response codes and their meanings.

Table 21-6: HTTP Response Codes

Response Code


200 OK

The request was successfully processed.

201 Created

Using the POST request method, a new file was successfully stored on the server

202 Accepted

The request has been received and is currently being processed.

204 No Content

The request was successful, but there is no change in the current page displayed to the client.

301 Moved

The requested page has been permanently moved, and future


references to that page should use the new URL that is displayed.

302 Moved Temporarily

The requested page has been temporarily relocated. Future references should continue to use the same URL, but the current connection is being redirected

304 Not Modified

A cached version of the page is identical to the requested page.

400 Bad Request

The client’s request contains invalid syntax.

401 Unauthorized

The client specified an invalid user name/password combination.

402 Payment Required

The client must provide a means to complete a monetary transaction.

403 Forbidden

Access-control mechanisms deny the client’s request.

404 Not Found

The requested page does not exist on the server.

500 Internal Server Error

Usually encountered when running a CGI program, this response code indicates that the program or script contains invalid code or was given input that it cannot handle.

501 Not Implemented

The request method (for example, GET, POST, PUT, DELETE, HEAD) is not understood by the server.

502 Bad Gateway

Using the Web server as a proxy, an error was encountered in fulfilling the request to an external host.

503 Service Unavailable

The server is currently processing too many requests.

505 HTTP Version Not Supported

The request version (for example, HTTP/1.0, HTTP/1.1) is not understood by the server.

To make it easier to internationalize error messages and standardize how these messages are presented, the latest version of Apache includes what are referred to as variant pages (ending in a .var suffix). These variant pages, which offer variable output based on language, are stored in the /var/www/error directory.

Alias /error/ "/var/www/error/"      <IfModule mod_negotiation.c>  <IfModule mod_include.c>      <Directory "/var/www/error">          AllowOverride None          Options IncludesNoExec          AddOutputFilter Includes html          AddHandler type-map var          Order allow,deny          Allow from all          LanguagePriority en es de fr          ForceLanguagePriority Prefer Fallback      </Directory>          ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var      ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var          ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var          ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var      ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var            .            .            . 

The ErrorDocument directive associates a particular error code number with a particular .var file that contains multiple possible responses based on language.

Setting responses to browsers

If file extensions are not enough to determine a file’s MIME type, you can define hints with the MimeMagicFile directive. With the BrowserMatch directive, you can set responses to conditions based on particular browser types:

#  # The following directives modify normal HTTP response behavior to  # handle known problems with browser implementations.  #  BrowserMatch "Mozilla/2" nokeepalive  BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0  BrowserMatch "RealPlayer 4\.0" force-response-1.0  BrowserMatch "Java/1\.0" force-response-1.0  BrowserMatch "JDK/1\.0" force-response-1.0      #  # The following directive disables redirects on non-GET requests for  # a directory that does not include the trailing slash. This fixes a  # problem with Microsoft WebFolders which does not appropriately handle  # redirects for folders with DAV methods.  # Same deal with Apple’s DAV filesystem and Gnome VFS support for DAV.  #  BrowserMatch "Microsoft Data Access Internet Publishing Provider"      redirect-carefully  BrowserMatch "^WebDrive" redirect-carefully  BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully  BrowserMatch "^gnome-vfs" redirect-carefully  

The BrowserMatch directive enables you to set environment variables based on the contents of the User-agent: header field. The force-response-1.0 variable causes a HTTP/1.0 response, indicating that Apache will respond to the browser in basic HTTP 1.0 operations.


If you are following the httpd.conf file, you notice that we are skipping descriptions of the server-status lines and server-info lines. They are described in the "Monitoring Server Activities" section later in this chapter.

Enabling proxy and caching services

Proxy and caching services are turned off by default. You can turn them on by uncommenting the following directives:

#  # Proxy Server directives. Uncomment the following lines to  # enable the proxy server:  #  #<IfModule mod_proxy.c>  #    ProxyRequests On  #  #<Proxy:*>  #    Order deny,allow  #    Deny from all  #    Allow from  #</Proxy>      #  # Enable/disable the handling of HTTP/1.1 "Via:" headers.  # ("Full" adds server version; "Block" removes outgoing Via: headers)  # Set to one of: Off | On | Full | Block  #  #ProxyVia On      # To enable a cache of proxied content, uncomment the following lines.  # See http:/ for more  details.  #  #<IfModule mod_disk_cache.c>  # CacheEnable disk /  # CacheRoot "/var/cache/mod_proxy"  #</IfModule>      #</IfModule>  # End of proxy directives.  

Apache can function as a proxy server, a caching server, or a combination of the two. If ProxyRequests is set to Off, the server will simply cache files without acting as a proxy. If CacheRoot (which specifies the directory used to contain the cache files) is undefined, no caching will be performed. Both proxy and caching services are Off (commented out) by default.

If you turn on caching, the CacheRoot should exist on a file system with enough free space to accommodate the cache, which is limited by the CacheSize directive. However, you should have 20 to 40 percent more space available in the file system because cache cleanup (to maintain the CacheSize, in kilobytes) occurs only periodically (which you can set using the CacheGcInterval directive).

You can add other directives to this example to enable other caching features. The CacheMaxExpire directive can indicate the maximum number of hours that a document will exist in the cache without checking the original document for modifications. The CacheLastModifiedFactor applies to documents that do not have an expiration time, even though the protocol would support one. To formulate an expiration date, the factor (a floating-point number) is multiplied by the number of hours since the document’s last modification. For example, if the document were modified three days ago and the CacheLastModifiedFactor were 0.25, the document would expire from the cache in 18 hours (as long as this value is still below the value of CacheMaxExpire).

The CacheDefaultExpire directive (specifying the number of hours before a document expires) applies to documents received via protocols that do not support expiration times. The NoCache directive contains a space-separated list of IP addresses, host names, or keywords in host names that should not have documents cached.

Here’s how the caching server behaves if you uncomment the previous Cache lines:

  • The cached files would exist in /var/cache/mod_proxy.

  • Cache size is limited to 500 Kbytes.

You might want to allow a much larger CacheSize, and possibly set a short CacheGcInterval, but otherwise the supplied values are reasonable. The CacheGcInterval value can be a floating-point number (for example, 1.25 indicates 75 minutes).

Configuring virtual hosting

If you have one Web server computer, but more than one domain that you want to serve with that computer, you can set up Apache to do virtual hosting. With name-based virtual hosting, a single IP address can be the access point for multiple domain names on the same computer. With IP-based virtual hosting, you have a different IP address for each virtual host.

With virtual hosting, when a request comes into your Apache server from a Web browser through a particular IP address on your computer, Apache checks the domain name being requested and displays the content associated with that domain name. As an administrator of a Web server that supports virtual hosting, you must make sure that everything that needs to be configured for that virtual server is set up properly (you must define such things as locations for the Web content, log files, administrative contact, and so on).

Virtual hosting is defined with the VirtualHost tags. Information related to virtual hosts in the /etc/httpd/conf/httpd.conf file is shown in the following code:

### Section 3: Virtual Hosts  #  # VirtualHost: If you want to maintain multiple domains/hostnames on  # your machine you can setup VirtualHost containers for them. Most  # configurations use only name-based virtual hosts so the server  # doesn't need to worry about IP addresses. This is indicated by the  # asterisks in the directives below.  #  # Please see the documentation at  # <URL:>  # for further details before you try to setup virtual hosts.  #  # You may use the command line option '-S' to verify your virtual host  # configuration.  #  # Use name-based virtual hosting.  #  #NameVirtualHost *:80  #  # NOTE: NameVirtualHost cannot be used without a port specifier  # (e.g. :80) if mod_ssl is being used, due to the nature of the  # SSL protocol.      #  # VirtualHost example:  # Almost any Apache directive may go into a VirtualHost container.  # The first VirtualHost section is used for requests without a known  # server name.  #  #<VirtualHost *:80>  #    ServerAdmin  #    DocumentRoot /www/docs/  #    ServerName  #    ErrorLog logs/  #    CustomLog logs/ common  #</VirtualHost>  

The following example lists virtual host directives that would allow you to host the domains and on the same computer:

NameVirtualHost *:80      <VirtualHost *:80>       DocumentRoot /var/www/handsonhistory       ServerName       ServerAlias       ServerAdmin       ErrorLog logs/       CustomLog logs/ common  </VirtualHost>      <VirtualHost *:80>       DocumentRoot /var/www/linuxtoys       ServerName       ServerAlias       ServerAdmin       ErrorLog logs/       CustomLog logs/ common  </VirtualHost> 

Configuring modules and related services (/etc/httpd/conf.d/*.conf)

Any module that requires special configuration will typically have a configuration file (.conf file) in the /etc/httpd/conf.d directory. Here are modular configuration files that are contained in that directory, along with some ways of using those files:

  • auth_mysql.conf — Configure authentication based on data you add to a MySQL database. Comments in the file describe how to set up the database and then use it to do user or group authentication before allowing a client to access your Web content.

  • auth_pgsql.conf — Configure authentication based on data in a PostgreSQL database.

  • htdig.conf — Identify the location of the htdig search content that can be used on your Web site (/usr/share/htdig is the default location). To see the htdig search screen from a Web browser, type http://localhost/htdig. (The htdig system lets you set up tools for indexing and searching your Web site or company intranet. It is optional for your Web server)

  • mailman.conf — Set up mailman list server software to allow features such as making mailing-list archives available from Apache.

  • original.ssl.conf — Configure SSL support so that Apache knows how to serve pages requested over a secure connection (https).

  • perl.conf — Identifies and loads the mod_perl module so that your Web pages can include Perl code.

  • php.conf — Identifies and loads the libphp4 module so that your Web pages can include PHP scripting language. There is also a DirectoryIndex setting that allows an index.php file you add to a directory to be served as a directory index.

  • python.conf — Identifies and loads the mod_python module so Web pages can include Apache handlers written in Python.

  • squirrelmail.conf — Identifies the location of the SquirrelMail Web-based mail interface so that it can be incorporated into your Apache Web server. To see the SquirrelMail login screen, type http://localhost/webmail into a browser window.

  • subversion.conf — Loads the mod_dav_svn and mod_authz_svn modules to let you access a Subversion repository from Apache. By uncommenting lines in this file, you can set /home/svnroot as the location where you hold authorization files.

  • webalizer.conf — Lets you identify who can access the webalizer data (statistics about your Web site).

  • wordtrans.conf — Identifies the location of the WordTrans language translation window so that it can be incorporated into your Apache Web server. To see the WordTrans login screen, type http://localhost/wordtrans into a browser window.

These configuration files are read when the httpd server starts. The information in these files could have been added to httpd.conf. However, files are put here so that different packages can add their own configuration settings without having the RPM software package incorporate some automated method of adding their configuration information to the httpd.conf file.

Red Hat Fedora Linux 3 Bible
Red Hat Fedora Linux 3 Bible
ISBN: 0764578723
EAN: 2147483647
Year: 2005
Pages: 286 © 2008-2017.
If you may any questions please contact us: