The Apache Web server's configuration file is
/etc/httpd/conf/httpd.conf. The
httpd.conf file is well-commented and somewhat
self-explanatory. Its default configuration will work for most people,
so you probably will not need to change the directives in
httpd.conf. However, you may want to be familiar
with the most important configuration options.
The empty srm.conf and
access.conf files are also in the
/etc/httpd/conf directory. The
srm.conf and access.conf files
were formerly used, along with httpd.conf, as
configuration files for Apache.
If you need to configure Apache, you simply edit
httpd.conf, and then either reload, or stop and
start the httpd process. How to reload, stop and
start Apache is covered in the section called Starting and Stopping httpd.
Before you edit httpd.conf, you should first copy
the original file to something like httpd.confold
(or to any name you want). Then, if you make a mistake while you are
editing the configuration file, you will have a backup.
If you do make a mistake, and your Web server does not work correctly,
the first place to look is at what you just edited in
httpd.conf. Make sure that you did not make a typo.
The next place to look is your Web server's error log
(/var/log/httpd/error_log). The error log may not
be easy to interpret, depending on your level of experience. If you have
just experienced a problem, however, the last entries in the error log
should provide information about what has happened.
The next sections provide short descriptions of the directives which are
included in httpd.conf, in the order that you will
find them in the file. These descriptions are not exhaustive. If you
need more information, please refer to the Apache documentation provided
in HTML format at http://your_domain/manual/
or to the Apache group documentation at http://httpd.apache.org/docs/.
For more information about mod_ssl directives, refer to the
documentation included in HTML format as
http://your_domain/manual/mod/mod_ssl/, or
see the mod_ssl User Manual at http://www.modssl.org/docs/2.7/.
Your ServerType can be either
inetd or standalone. By
default, your Web server is set to ServerType
standalone.
ServerType standalone means that the server is
started once and then that server handles all of the connections.
ServerType inetd means that for every HTTP
connection, a new instance of the server is started. Each server
instance handles the connection and exits when the connection is
ended. As you can probably imagine, using inetd is
very inefficient. Another problem is that inetd
may not work correctly, according to the Apache group. And finally,
since Red Hat Linux 7.1 uses xinetd, additional
configuration will be needed to get xinetd to start
the server. For these reasons, you will want to leave your Web server's
ServerType set to standalone.
The ServerRoot is the top-level directory which
will contain the server's files. Both your secure and non-secure
servers are set to use a ServerRoot of
/etc/httpd.
LockFile sets the path to the lockfile used when
the Apache server is compiled with either
USE_FCNTL_SERIALIZED_ACCEPT or
USE_FLOCK_SERIALIZED_ACCEPT.
LockFile should normally be left at its default
value.
PidFile names the file in which the server records
its process ID (pid). Your Web server is set to record its pid in
/var/run/httpd.pid.
The ScoreBoardFile stores internal server process
information, which is used for communication between the parent server
process and its child processes. Your Web server's
ScoreBoardFile is set to
/var/run/httpd.scoreboard.
The ResourceConfig directive instructs the server
to read the file named after ResourceConfig for
more directives. The ResourceConfig directive is
commented out, because your Web server only uses
httpd.conf for configuration directives.
The AccessConfig directive instructs the server to
read the file named after AccessConfig for more
directives, after it has read the file named by
ResourceConfig. The AccessConfig
directive is commented out, because your Web server only uses
httpd.conf for configuration directives.
Timeout defines, in seconds, the amount of time
that your server will wait for receipts and transmissions during
communications. Specifically, Timeout defines how
long your server will wait to receive a GET request, how long it will
wait to receive TCP packets on a POST or PUT request and how long it
will wait between ACKs responding to TCP packets.
Timeout is set to 300 seconds, which is appropriate
for most situations.
KeepAlive sets whether your server will allow
persistent connections (in other words, more than one request per
connection). KeepAlive can be used to prevent any
one client from consuming too much of the server's resources. By
default, KeepAlive is set to on,
which means that your server allows persistent connections. You could
set it to off, which would disable persistent
connections. See the section called MaxKeepAliveRequests for a related way to
limit requests per connection.
This directive sets the maximum number of requests allowed per
persistent connection. The Apache Group recommends a high setting,
which will improve your server's performance.
MaxKeepAliveRequests is set to
100 by default, which should be appropriate for
most situations.
KeepAliveTimeout sets the number of seconds your
server will wait for a subsequent request, after a request has been
served, before it closes the connection. Once a request has been
received, the Timeout directive applies instead.
The Apache Web server dynamically adapts to the perceived load by
maintaining an appropriate number of spare server processes based on
the traffic. The server checks the number of servers waiting for a
request and kills some if there are more than
MaxSpareServers or creates some if the number of
servers is less than MinSpareServers.
Your server's default MinSpareServers is
5; your server's default
MaxSpareServers is 20. These
default settings should be appropriate in almost all situations. You
should not increase the MinSpareServers to a very
large number, since that will create a heavy processing load on your
server even when traffic is light.
StartServers sets how many server processes are
created upon startup. Since your Web server dynamically kills and
creates server processes based on traffic load, you will not ever need to
change this parameter. Your Web server is set to start eight server
processes at startup.
MaxClients sets a limit on the total number of
server processes (i.e., simultaneously connected clients) that can run
at one time. You want to keep MaxClients at a high
number (your server's default is set to 150), because no one else will
be allowed to connect once that number of simultaneously connected
clients is reached. You can not set MaxClients to
higher than 256 without recompiling Apache. The main reason for
having MaxClients is so that a runaway Web server
does not crash your operating system.
MaxRequestsPerChild sets the total number of
requests each child server process serves before the child dies. The
main reason for setting MaxRequestsPerChild is to
avoid long-lived process induced memory leaks. The default
MaxRequestsPerChild for your server is
100.
The Listen command identifies the ports on which
your Web server will accept incoming requests. Your Web server is set
to listen to port 80 for non-secure Web communications and (in the
virtual host tags that define the secure server) to port 443 for
secure Web communications.
If you set Apache to listen to a port under 1024, you must be root to
start it. For port 1024 and above, httpd can be
started as a regular user.
Listen can also be used to specify particular IP
addresses over which the server will accept connections.
BindAddress is a way of specifying which IP
addresses your server will listen to. You should use the
Listen directive instead if you need this
functionality. BindAddress is not used by your Web
server; by default it is commented out in
httpd.conf.
LoadModule is used to load in Dynamic Shared Object
(DSO) modules. More information on the Apache's DSO support,
including exactly how to use the LoadModule
directive, can be found in the section called Adding Modules to Your Server. Note that the order of the
modules is important, so do not move them around.
The <IfDefine> and
</IfDefine> tags surround configuration
directives that are applied if the "test" stated in the
<IfDefine> tag is true. The directives are
ignored if the test is false.
The test in the <IfDefine> tags is a
parameter name (for example, HAVE_PERL). If the
parameter is defined, meaning that it is provided as an argument to
the server's start-up command, then the test is true. In this case,
when your Web server is started, the test is true and the directives
contained in the IfDefine tags are applied.
By default, <IfDefine HAVE_SSL> tags surround
the virtual host tags for your secure server. <IfDefine
HAVE_SSL> tags also surround the
LoadModule and AddModule
directives for the ssl_module.
The ClearModuleList directive is located
immediately before the long list of AddModule
directives. ClearModuleList erases the server's
built-in list of active modules. Then the list of
AddModule directives re-creates the list,
immediately after ClearModuleList.
AddModule is the directive used to create a
complete list of all available modules. You will use the
AddModule directive if you add your own module in
as a DSO. For more information on how AddModule is
used for DSO support, see the section called Adding Modules to Your Server.
The ExtendedStatus directives controls whether
Apache generates basic (off) or detailed server
status information (on), when the
server-status handler is
called. Server-status is called using
Location tags. More information on calling
server-status is included in the section called Location.
Normally, Port defines the port that your server is
listening to. Your Web server, however, is listening to more than one
port by default, since the Listen directive is also
being used. When Listen directives are in effect,
your server listens at all of those ports. See the description of the
Listen directive for more information about
Listen.
The Port command is also used to specify the port
number used to construct a canonical name for your server. See the section called UseCanonicalName for more information
about your server's canonical name.
The User directive sets the userid used by the
server to answer requests. User's setting
determines the server's access. Any files inaccessible to this user
will also be inaccessible to your website's visitors. The default for
User is apache.
The User should only have privileges so that it can
access files which are supposed to be visible to the outside world.
The User is also the owner of any CGI processes
spawned by the server. The User should not be
allowed to execute any code which is not intended to be in response to
HTTP requests.
 | Note |
|---|
| | Unless you know exactly what you are doing, do not set the
User to root. Using root as the
User will create large security holes for your
Web server.
|
The parent httpd process first runs as root during
normal operations but is then immediately handed off to the apache
user. The server must start as root because it needs to bind to a
port below 1024 (the default port for secure Web communications is
port 443; the default port for non-secure Web communications is port
80). Ports below 1024 are reserved for system use, so they can not be
used by anyone but root. Once the server has attached itself to its
port, however, it hands the process off to the User
before it accepts any connection requests.
The Group directive is similar to the
User. The Group sets the group
under which the server will answer requests. The default
Group is also apache.
ServerAdmin should be the email address of the
Web server's administrator. This email address will show up in error
messages on server-generated Web pages, so users can report a problem
by sending email to the server
administrator. ServerAdmin is set by default to
root@localhost.
Typically, a good way to set up ServerAdmin is to
set it to webmaster@your_domain.com. Then alias
webmaster to the person responsible for the Web
server in /etc/aliases. Finally, run
/usr/bin/newaliases to add the new alias.
You can use ServerName to set a hostname for your
server which is different from your host's real name. For example,
you might want to use www.your_domain.com when your server's real name
is actually foo.your_domain.com. Note that the
ServerName must be a valid Domain Name Service
(DNS) name that you have the right to use (do not just make something
up).
If you do specify a ServerName, be sure its IP
address and server name pair are included in your
/etc/hosts file.
The DocumentRoot is the directory which contains
most of the HTML files which will be served in response to requests.
The default DocumentRoot for both the non-secure
and secure Web servers is /var/www/html. For
example, the server might receive a request for the following
document:
http://your_domain/foo.html |
The server will look for the following file in the default directory:
If you want to change the DocumentRoot so that it
is not shared by the secure and the non-secure Web servers, see the section called Using Virtual Hosts.
<Directory /path/to/directory> and
</Directory> tags are used to enclose a group
of configuration directives that are meant to apply only to that
directory and all of its subdirectories. Any directive which is
applicable to a directory may be used within
<Directory>
tags. <File> tags can be used in the same
way, to apply to a specific file.
By default, very restrictive parameters are applied to the root
directory, using the Options (see the section called Options) and
AllowOverride (see the section called AllowOverride) directives. Under this
configuration, any directory on your system which needs more
permissive settings has to be explicitly given those settings.
Using Directory tags, the
DocumentRoot is defined to have less rigid
parameters, so that HTTP requests can be served from it.
The cgi-bin directory is set up to allow the
execution of CGI scripts, with the ExecCGI
option. If you need to execute a CGI script in another directory,
you will need to set ExecCGI for that directory. For
example, if your cgi-bin is
/var/www/cgi-bin, but you want to execute CGI
scripts from within /home/my_cgi_directory, add an
ExecCGI directive to a set of
Directory directives like the following to your
httpd.conf file:
<Directory /home/my_cgi_directory>
Options +ExecCGI
</Directory> |
To allow CGI script execution in
/home/my_cgi_directory, you will need to take a few
extra steps besides setting ExecCGI. You will also
need to have the AddHandler directive uncommented
to identify files with the .cgi extension as CGI
scripts. See the section called AddHandler for
instructions on setting AddHandler. Permissions for
CGI scripts, and the entire path to the scripts, must be set to 0755.
Finally, the owner of the script and the owner of the directory must
be the same user.
The Options directive controls which server
features are available in a particular directory. For example, under
the restrictive parameters specified for the root directory,
Options is set to only
FollowSymLinks. No features are enabled, except
that the server is allowed to follow symbolic links in the root
directory.
By default, in your DocumentRoot directory,
Options is set to include
Indexes, Includes and
FollowSymLinks. Indexes permits
the server to generate a directory listing for a directory if no
DirectoryIndex (for example,
index.html) is
specified. Includes means that server-side includes
are permitted. FollowSymLinks allows the server to
follow symbolic links in that directory.
You will also need to include Options statements for
directories within virtual hosts directives, if you want your virtual
hosts to recognize those Options.
For example, server side includes are already enabled inside the
/var/www/html directory, because of the
Options Includes line within the
<Directory "/var/www/html"> directives
section. However, if you want a virtual host to recognize that server
side includes are allowed within /var/www/html,
you will need to include a section like the following within your
virtual host's tags:
<Directory /var/www/html>
Options Includes
</Directory> |
The AllowOverride directive sets whether or not any
Options can be overridden by the declarations in an
.htaccess file. By default, both the root
directory and the DocumentRoot are set to allow no
.htaccess overrides.
The Order directive simply controls the order in
which allow and deny directives
are evaluated. Your server is configured to evaluate the
Allow directives before the deny
directives for your DocumentRoot directory.
Allow specifies which requester can access a given
directory. The requester can be all, a domain
name, an IP address, a partial IP address, a network/netmask pair,
etc. Your DocumentRoot directory is configured to
Allow requests from all (i.e.,
anyone).
Deny works just like Allow, but
you are specifying who is denied access. Your
DocumentRoot is not configured to
Deny requests from anyone.
UserDir is the name of the subdirectory within
each user's home directory where they should place personal HTML files
which are to be served by the Web server. By default, the subdirectory
is public_html. For example, the server might
receive the following request:
http://your_domain/~username/foo.html |
The server would look for the file:
/home/username/public_html/foo.html |
In the above example, /home/username is the
user's home directory (note that the default path to users' home
directories may be different on your system).
Make sure that the permissions on the users' home directories are set
correctly. Users' home directories must be set to 0755. The read (r)
and execute (x) bits must be set on the users'
public_html directories (0755 will work). Files
that will be served in users' public_html
directories must be set to at least 0644.
The DirectoryIndex is the default page served by
the server when a user requests an index of a directory by specifying
a forward slash (/) at the end of the directory name.
When a user requests the page
http://your_domain/this_directory/,
they are going to get either the DirectoryIndex
page if it exists, or a server-generated directory list. The default
for DirectoryIndex is
index.html index.htm
index.shtml index.php
index.php4 index.php3
index.cgi. The server will try to find any one of
these files, and will return the first one it finds. If it does not
find any of these files and Options Indexes is set
for that directory, the server will generate and return a listing, in
HTML format, of the subdirectories and files in the directory.
AccessFileName names the file which the server
should use for access control information in each directory. By
default, your Web server is set to use .htaccess,
if it exists, for access control information in each directory.
Immediately after the AccessFileName directive, a
set of Files tags apply access control to any file
beginning with a .ht. These directives deny Web
access to any .htaccess files (or other files
which begin with .ht) for security reasons.
By default, your Web server asks proxy servers not to cache any
documents which were negotiated on the basis of content (that is, they
may change over time or because of the input from the requester). If
you uncomment CacheNegotiatedDocs, you are
disabling that function and proxy servers will be allowed to cache the
documents from then on.
UseCanonicalName is set by default to
on. UseCanonicalName allows the
server to construct an URL that references itself, using
ServerName and Port. When the
server refers to itself in response to requests from clients, it uses
this URL. If you set UseCanonicalName to
off, the server will instead use the value that
came in the request from the client to refer to itself.
TypesConfig names the file which sets the default
list of MIME type mappings (filename extensions to content types).
The default TypesConfig file is
/etc/mime.types. Instead of editing
/etc/mime.types, the recommended way to add MIME
type mappings is to use the AddType directive.
DefaultType sets a default content type for the Web
server to use for documents whose MIME types can not be determined.
Your Web server defaults to assume a plain text content type for any
file with an indeterminate content type.
<IfModule> and
</IfModule> tags surround directives that are
conditional. The directives contained within the
IfModule tags are processed under one of two
conditions. The directives are processed if the module contained
within the starting <IfModule> tag is
compiled in to the Apache server. Or, if an "!" (an exclamation
point) is included before the module name, the directives are
processed only if the module in the starting
<IfModule> tag is not
compiled in.
The mod_mime_magic.c file is included in these
IfModule tags. The mod_mime_magic module can be
compared to the UNIX file command, which looks at a
few bytes of a file's contents, then uses "magic numbers" and other
hints in order to figure out the MIME type of the file.
If the mod_mime_magic module is compiled in to Apache, these
IfModule tags tell the mod_mime_magic module where
the hints definition file is: /usr/share/magic in this
case.
The mod_mime_magic module is not compiled in by default. If you would
like to use it, see the section called Adding Modules to Your Server, for
instructions on how to add modules to your server.
HostnameLookups can be set to
on, off or
double. If you allow
HostnameLookups (by setting it to
on), your server will automatically resolve the IP
address for each connection which requests a document from your Web
server. Resolving the IP address means that your server will make one
or more connections to the DNS in order to find out the hostname that
corresponds to a particular IP address. If you set
HostnameLookups to double, your
server will perform a double-reverse DNS. In other words, after a
reverse lookup is performed, a forward lookup is performed on the
result. At least one of the IP addresses in the forward lookup must
match the address from the first reverse lookup.
Generally, you should leave HostnameLookups set to
off, because the DNS requests add a load to your
server and may slow it down. If your server is busy, the effects of
HostnameLookups may be quite noticeable.
HostnameLookups are also an issue for the Internet
as a whole. All of the individual connections made to look up each
hostname add up. Therefore, for your own Web server's benefit, as
well as for the good of the Internet as a whole, you should leave
HostnameLookups set to off.
ErrorLog names the file where server errors are
logged. As this directive indicates, the error log file for your Web
server is /var/log/httpd/error_log.
The error log is a good place to look if your Web server ever
generates any errors or fails and you are not sure what happened.
LogLevel sets how verbose the error messages in the
error logs will be. LogLevel can be set (from
least verbose to most verbose) to emerg,
alert, crit,
error, warn,
notice, info or
debug. Your Web server's
LogLevel is set to warn.
The LogFormat directives in your
httpd.conf file set up a format for the messages
in your access log. Hopefully, this format will make your access log
more readable.
CustomLog identifies the log file and the log file
format. In your Web server's default configuration,
CustomLog defines the log file in which accesses to
your Web server are recorded:
/var/log/httpd/access_log. You will need to know
the location of this file if you want to generate any access-based
server performance statistics for your Web server.
CustomLog also sets the log file format
to common. The common logfile format looks like this:
remotehost rfc931 authuser [date] "request" status bytes |
- remotehost
The remote hostname. If the hostname is not available from DNS,
or if HostnameLookups is set to
Off, then
remotehost
will be the IP address of the remote host.
- rfc931
Not used. You will see a - in the log file in
its place.
- authuser
If authentication was required, this is the username with which
the user identified him or herself. Usually, this is not used, so
you will see a - in its place.
- [date]
The date and time of the request.
- "request"
The request string exactly as it came from the browser or
client.
- status
The HTTP status code which was returned to the browser or
client.
- bytes
The size of the document.
The CustomLog command can be used to set up
specific log files to record referers (the URL for the Web page which
linked to a page on your Web server) and/or agents (the browsers used
to retrieve Web pages from your Web server). The relevant
CustomLog lines are commented out, as shown, but
you should uncomment them if you want those two log files:
#CustomLog /var/log/httpd/referer_log referer
#CustomLog /var/log/httpd/agent_log agent |
Alternatively, you can also set the CommonLog
directive to use a combined log by uncommenting the
following line:
#CustomLog /var/log/httpd/access_log combined |
A combined log will add the referer and agent
fields to the end of the common log fields. If you want to use a
combined log, you will need to comment out the
CustomLog directive setting your access log to the
common logfile format.
The ServerSignature directive adds a line
containing the Apache server version and the
ServerName of the serving host to any
server-generated documents (for example, error messages sent back to
clients). ServerSignature is set to
on by default. You can change it to
off, so no signature line will be added, or you can
change it to EMail. EMail will
add a mailto:ServerAdmin HTML tag to the signature
line.
The Alias setting allows directories to be outside
the DocumentRoot directory and yet still accessible
to the Web server. Any URL ending in the alias will automatically
resolve to the alias' path. By default, one alias is already set up.
An icons directory can be accessed by the Web
server, but the directory is not in the
DocumentRoot. The icons
directory, an alias, is actually
/var/www/icons/, not
/var/www/html/icons/.
The ScriptAlias setting defines where CGI scripts
(or other types of scripts) can be found. Generally, you do not want
to leave CGI scripts within the DocumentRoot. If
CGI scripts are in DocumentRoot, they could
potentially be viewed as text documents. Even if you do not care if
people can see (and then use) your CGI scripts, revealing how they
work creates opportunities for unscrupulous people to exploit any
security holes in the script, and may create a security risk for your
server. By default, the cgi-bin directory is a
ScriptAlias of /cgi-bin/, and
is actually located in /var/www/cgi-bin/.
Your /var/www/cgi-bin directory has
Options ExecCGI set, meaning that execution of CGI
scripts is permitted within that directory.
See the section called AddHandler and the section called Directory for instructions on how to
execute CGI scripts in directories other than the
cgi-bin.
When a Web page is moved, Redirect can be used to
map the old URL to a new URL. The format is as follows:
Redirect /path/foo.html http://new_domain/path/foo.html |
So, if an HTTP request is received for a page which used to be found
at
http://your_domain/path/foo.html,
the server will send back the new URL
(http://new_domain/path/foo.html)
to the client, which should attempt to fetch the document from the new
URL.
IndexOptions controls the appearance of server
generated directing listings, by adding icons and file descriptions,
etc. If Options Indexes is set (see the section called Options), your Web server may generate a
directory listening when your Web server receives an HTTP request like
the following:
http://your_domain/this_directory/
First, your Web server looks in that directory for a file from the
list after the DirectoryIndex directive (usually,
index.html). If your Web server does not find one
of those files, it creates an HTML directory listing of the
subdirectories and files in the directory. You can modify the
appearance of this directory listing using certain directives in
httpd.conf, including
IndexOptions.
Your default configuration sets FancyIndexing on.
If FancyIndexing is turned on, clicking on the
column headers in the directory listing will sort the order of the
display by that header. Another click on the same header will switch
from ascending to descending order and
back. FancyIndexing also shows different icons for
different files, depending upon file extensions. If you use the
AddDescription directive and turn
FancyIndexing on, then a short description of a
file will be included in the server generated directory listing.
IndexOptions has a number of other parameters which
can be set to control the appearance of server generated directories.
Parameters include IconHeight and
IconWidth, to make the server include HTML
HEIGHT and WIDTH tags for the
icons in server generated Web pages; IconsAreLinks,
for making the icons act as part of the HTML link anchor along with
the filename, and others.
This directive names icons which will be displayed by files with
MIME encoding, in server generated directory listings. For example,
by default, your Web server shows the
compressed.gif icon next to MIME encoded
x-compress and x-gzip files in server generated directory listings.
This directive names icons which will be displayed next to files with
MIME types in server generated directory listings. For example, your
server is set to show the icon text.gif next to
files with a mime-type of "text," in server generated directory
listings.
AddIcon tells the server which icon to show in
server generated directory listings for certain file types or for
files with certain extensions. For example, your Web server is set to
show the icon binary.gif for files with
.bin or .exe extensions.
DefaultIcon names the icon to show in server
generated directory listings for files which have no other icon
specified. The unknown.gif image file is the
DefaultIcon for those files by default.
You can use AddDescription to show text that you
specify for certain files, in server generated directory listings
(you will also need to enable FancyIndexing as an
IndexOptions). You can name specific files,
wildcard expressions or file extensions to specify the files which
this directive should apply to. For example, you could use the
following line:
AddDescription "A file that ends in .ni" .ni |
In server generated directory listings, all files with extensions of
.ni would have the description A file
that ends in .ni after the filename. Note that you will also
need FancyIndexing turned on.
ReadmeName names the file which (if it exists in
the directory) will be appended to the end of server generated
directory listings. The Web server will first try to include the file
as an HTML document and then try to include it as plaintext. By
default, ReadmeName is set to
README.
HeaderName names the file which (if it exists in
the directory) will be prepended to the start of server generated
directory listings. Like ReadmeName, the server
will try to include it as an HTML document if possible, or in
plaintext if not.
IndexIgnore lists file extensions, partial
filenames, wildcard expressions or full filenames. The Web server
will not include any files which match any of those parameters in
server generated directory listings.
AddEncoding names filename extensions which should
specify a particular encoding type. AddEncoding
can also be used to instruct some browsers (not all) to uncompress
certain files as they are downloaded.
AddLanguage associates filename extensions with
specific content languages. This directive is mostly useful for
content negotiation, when the server returns one of several documents
based on the client's language preference as set in their browser.
LanguagePriority allows you to set precedence for
different languages in which to serve files, which will be in effect
if the client expressed no preference for language in their browser.
Use the AddType directive to define MIME type and
file extension pairs. For example, if you are using PHP4, your Web
server is using the AddType directive to make your
Web server recognize files with PHP extensions
(.php4, .php3
.phtml .php) as PHP MIME
types.
The following AddType line tells your server to
recognize the .shtml file extension (for server
side includes):
You will need to include the above line within the virtual host tags for
any virtual hosts which should allow server side includes.
AddHandler maps file extensions to specific
handlers. For example, the cgi-script handler can
be used matched with the extension .cgi to
automatically treat a file ending with .cgi as a
CGI script. This will work, even for files outside of the
ScriptAlias directory, as long as you follow the
instructions provided here.
You have a CGI AddHandler line in your
httpd.conf file:
AddHandler cgi-script .cgi |
You will have to uncomment the line. Then Apache will execute CGI
scripts for files ending in .cgi, even if they
are outside of the ScriptAlias, which is set by
default to locate your /cgi-bin/ directory in
/var/www/cgi-bin/.
You will also need to set ExecCGI as an
Options for any directory containing a CGI
script. See the section called Directory for more
information about setting ExecCGI for a
directory. Additionally, you will need to make sure the permissions are
set correctly for the CGI scripts and the directories containing CGI
scripts. CGI scripts and the entire directory path to the scripts
must be set to 0755. Finally, the owner of the directory and the owner
of the script file must be the same user.
You will need to add the same AddHandler line to your
VirtualHost setup, if you are using virtual hosts
and you want them to also recognize CGI scripts outside the
ScriptAlias.
In addition to CGI scripts, your Web server also uses
AddHandler to process server-parsed HTML and
imagemap files.
Action allows you to specify a MIME content type
and CGI script pair, so that whenever a file of that media type is
requested, a particular CGI script will be executed.
MetaDir specifies the name of a directory where
your Web server should look for files containing meta information
(extra HTTP headers) to include when serving documents.
MetaSuffix specifies the filename suffix for the
file that contains meta information (extra HTTP headers), which should
be located in the MetaDir directory.
By default, in the event of a problem or error, your Web server
outputs a simple (and usually cryptic) error message back to the
requesting client. Instead of using the default, you can use
ErrorDocument to configure your Web server so that
it outputs a customized message or redirects the client to a local or
external URL. The ErrorDocument directive simply
associates a HTTP response code with a message or a URL which will be
sent back to the client.
The BrowserMatch directive allows your server to
define environment variables and/or take appropriate actions based on
the User-Agent HTTP header field, which identifies the client's
browser. By default, your Web server uses
BrowserMatch to deny connections to specific
browsers with known problems and also to disable keepalives and HTTP
header flushes for browsers that are known to have problems with those
actions.
<Location> and
</Location> tags allow you to specify access
control based on the URL.
The next use of Location tags is located within
IfModule mod_perl.c tags. These configuration
directives are in effect if the mod_perl.so DSO
is loaded. See the section called Adding Modules to Your Server for more
information about adding modules to Apache.
The Location tags name the
/var/www/perl directory (an
Alias for /perl) as the
directory from which Perl scripts will be served. If a document is
requested with an URL containing /perl in the
path, your Web server will look in
/var/www/perl/ for the appropriate Perl
script.
Several other <Location> options are
commented out in your httpd.conf file. If you
want to enable the functionality they provide, you will need to
uncomment the appropriate section of directives.
Immediately after the Perl directives discussed previously, your
httpd.conf file includes a section of directives
for enabling HTTP PUT (used by Netscape Gold's publish feature, which
can post Web pages to a Web server). If you want to allow HTTP PUT,
you will need to uncomment this entire section:
#Alias /upload /tmp
#<Location /upload>
# EnablePut On
# AuthType Basic
# AuthName Temporary
# AuthUserFile /etc/httpd/conf/passwd
# EnableDelete Off
# umask 007
# <Limit PUT>
# require valid-user
# </Limit>
#</Location> |
You will also need to uncomment the following lines at the beginning of
httpd.conf so that the mod_put module is loaded
in to Apache:
#LoadModule put_module modules/mod_put.so
#AddModule mod_put.c |
If you want to allow people connecting from your domain to see server
status reports, you should uncomment the next section of directives:
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
#</Location> |
You must replace .your_domain.com with your second
level domain name.
If you want to provide server configuration reports (including
installed modules and configuration directives) to requests from
inside your domain, you will need to uncomment the following lines:
#<Location /server-info>
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
#</Location> |
Again, you must fill in .your_domain.com.
The next section of directives use Location tags to
allow access to the documentation in
/usr/share/doc (for example, with a URL like
http://your_domain/doc/whatever.html). These directives only allow
this access to requests made from the localhost.
Another use of the Location tags is a commented-out
section which is intended to track attacks on your Web server which
exploit an old bug from pre-Apache 1.1 days. If you want to track
these requests, uncomment the following lines:
#<Location /cgi-bin/phf*>
# Deny from all
# ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
#</Location> |
If these lines are uncommented, your Web server will redirect any
requests which end in /cgi-bin/phf* to a
logging CGI script run by the Apache Group.
If you uncomment the IfModule tags surrounding the
ProxyRequests directives, your Apache server will
also function as a proxy server. You will also need to load the
mod_proxy module. For instructions on how to load
in modules, see the section called Adding Modules to Your Server.
The ProxyVia command controls whether or not an
HTTP Via: header line is sent along with requests or replies which go
through the Apache proxy server. The Via: header will show the
hostname if ProxyVia is set to
On, the hostname and Apache version for
Full, any Via: lines will be passed along unchanged
for Off, and Via: lines will be removed for
Block.
A number of cache directives are commented out in the proxy
IfModule tags mentioned above. If you are using
the proxy server functionality and you want to also enable the proxy
cache, you should uncomment the cache directives as described. The
default settings for your cache directives should be appropriate for
most configurations.
CacheRoot sets the name of the directory which will
contain cached files. The default CacheRoot is
/var/cache/httpd.
CacheSize sets how much space the cache can use, in
KB. The default CacheSize is 5
KB.
CacheGcInterval sets a number of hours. After that
number of hours, files in the cache will be deleted if the cache is
using more space than allowed by CacheSize. The
default for CacheGcInterval is four hours.
Cached HTML documents will be retained (without a reload from the
originating Web server) in the cache for a maximum number of hours set
by CacheMaxExpire. The default is
24 hours.
The CacheLastModifiedFactor affects the creation of
an expiry (expiration) date for a document which did not come from its
originating server with its own expiry set. The default
CacheLastModifiedFactor is set to
0.1, meaning that the expiry date for such
documents equals one-tenth of the amount of time since the document
was last modified.
CacheDefaultExpire is the expiry time in hours for
a document that was received using a protocol that does not support
expiry times. The default is set to one hour.
Any document that is retrieved from a host and/or domain that matches
one set in NoCache will not be cached. If you know
of hosts or domains from which you do not want to cache documents,
uncomment NoCache and set their domains or
hostnames here.
You will need to use the NameVirtualHost directive
for the IP address (and port number if necessary) of any name-based
virtual hosts you are setting up. The name-based virtual hosts
configuration is used when you want to set up different virtual hosts
for different domains, but you do not have (or do not want to use)
different IP addresses for all of the different domain names for which
your Web server serves documents.
 | Note |
|---|
| | You cannot use name-based virtual hosts with your secure server. Any
name-based virtual hosts you set up will only work with non-secure
HTTP connections and not with SSL connections.
You cannot use name-based virtual hosts with your secure server
because the SSL handshake (when the browser accepts the secure Web
server's authenticating certificate) occurs before the HTTP request
which identifies the correct name-based virtual host. In other
words, authentication occurs before there is any identification of
different name-based virtual hosts. If you want to use virtual
hosts with your secure server, you will need to use IP address-based
virtual hosts.
|
If you are using name-based virtual hosts, uncomment the
NameVirtualHost configuration directive and add the
correct IP address for your server after
NameVirtualHost. Then add more information about
the different domains using the Virtual Host tags
which surround the ServerName for each virtual
host, plus any other configuration directives which are only
applicable to that virtual host.
<VirtualHost> and
</VirtualHost> tags surround any
configuration directives which are intended to apply to a virtual
host. Most configuration directives can be used within virtual host
tags, and then they only apply to that particular virtual host.
A set of commented out VirtualHost tags surround
some example configuration directives and placeholders for the
information you would need to fill in to set up a virtual host. Please
see the section called Using Virtual Hosts, for more
information about virtual hosts.
The Apache configuration directive SetEnvIf is used
to disable HTTP keepalive and to allow SSL to close the connection
without a close notify alert from the client browser. This setting is
necessary for certain browsers that do not reliably shut down the SSL
connection.
The SSL directives in your server's httpd.conf
file are included to enable secure Web communications using SSL and
TLS.
For more information on SSL directives, please point your browser to
http://your_domain/manual/mod/mod_ssl/.
More information on SSL directives is also available at http://www.modssl.org/docs/2.7/ssl_reference.html,
a chapter in a Web document about mod_ssl by Ralf Engelschall. The
same document, the mod_ssl User Manual, begins
at http://www.modssl.org/docs/2.7/
and is a great reference source for mod_ssl and for Web cryptography
in general. This manual provides general information about securing
your Web server in Chapter 13.
 | Note |
|---|
| | Do not modify your SSL directives unless you are absolutely sure about
what you are doing. In most cases, the SSL directives are configured
appropriately as installed.
|