Configuring the Apache Server

Configuring the Apache Server

The primary file for configuring your Apache Web server is httpd.conf (located in the /etc/httpd/conf directory). For older installations, you may also have srm.conf and access.conf files configured. In recent releases, however, Apache developers recommend you put all directives into httpd.conf and not create the other two files.

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 within Apache, such as perl, php, 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 addresses modules.


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 ScoreBoard file

On some systems, a ScoreBoard file is created to store internal server process information. Red Hat Linux does not need to use the ScoreBoardFile, as the status information usually saved in that file is stored in memory instead.

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 300
# 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 for a PUT or POST HTTP request method, between the receipt of acknowledgments on sent responses, or while receiving an incoming request. The default of five minutes (300 seconds) can certainly 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 (to a different server process, most likely) 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 may wish to increase the default (15 seconds), depending on how long it may take a client to peruse your average page and select a link from it.

Setting the number of server processes

To allow Apache to dynamically change the number of server processes running to meet the demands of the server, several parameters are set to indicate:

  • How many server processes should be started (StartServers)

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

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

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

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

With the Multi-Processing Module (MPM) feature in Apache 2.0, minimum and maximum server options can be set to take advantage of more processors and threads. As load increases, the number of processes available to handle it increases, based on these settings. Because starting each process takes time, spare servers are there to handle occasional spikes in load.

## Server-Pool Size Regulation (MPM specific)
<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
MaxClients       150
MaxRequestsPerChild  1000
<IfModule worker.c>
StartServers         2
MaxClients         150
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  0
<IfModule perchild.c>
NumServers           5
StartThreads         5
MinSpareThreads      5
MaxSpareThreads     10
MaxThreadsPerChild  20
MaxRequestsPerChild  0

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) 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 MaxSpareServers).

Using the values specified above, when the daemon is started, eight server processes will run, waiting for connections (as defined by StartServers). As more requests arrive, Apache will ensure that at least eight servers 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 server processes 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 servers 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.

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 1000 requests (the value specified above), the process will be killed. It is even more accurate to say that each process can service 1000 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 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 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.


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


Used to provide filesystem 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.


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 upon 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.


The only module other than http_core that must be statically compiled in the server, this module contains the directives necessary to implement loading dynamic shared objects.


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 particular user/group.


Attempts to assign a token to each client request that is unique across all server processes on all machines within a cluster.


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 above list. Similarly, you may want to add the features or functionality of a third-party module (for example, mod_perl, which integrates the Perl run-time library for faster Perl script execution, or mod_php, which provides a scripting language embedded within HTML documents) by including those modules in the lists above.

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 servers 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 (below 65536) that is not already bound to a particular service (see the /etc/services file for a list of common services/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. It can direct mail to a user account (on the same or another machine) or redirect mail to an alias (such as Webmaster) that could distribute mail to several individuals. The default is root@localhost.

Setting the server name

If your server name is anything but your exact registered host/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 refer 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/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, as 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 DocumentRoot directive. (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

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).

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

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 FollowSysLinks. Those and other special server features are described in Table 21-2. The AllowOverride None directive instructs the server that the .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 and #include elements.


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


The server allows a content-based filename pattern-matching search.


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 Apache, 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

Identifying user directories

You can identify the name that is appended to a user's home directory when a request for a user's directory (~user) is received. This feature 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

Besides uncommenting the UserDir public_html line shown above, 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


UserDir /public/*/WWW


UserDir /usr/local/web





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 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

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. Because directives you put in .htaccess apply to all directives 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
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 /etc/httpd directory is appended (for example, /e

Part IV: Red Hat Linux Network and Server Setup