|Red Hat Linux 7.2: The Official Red Hat Linux Reference Guide|
|Chapter 13. Apache|
The Apache Web server 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 should 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, 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, for example. By creating a backup, you can recover potential mistakes made while editing the new configuration file.
If you do make a mistake, and your Web server does not work correctly, first review what you have recently 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 included in httpd.conf. These descriptions are not exhaustive. If you need more information, 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 at http://your_domain/manual/mod/mod_ssl/, or see the mod_ssl User Manual at http://www.modssl.org/docs/2.7/.
Your ServerType must be set to 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.
The ServerRoot is the top-level directory which contains 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 be left at its default value.
PidFile names the file where 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. Red Hat Linux uses shared memory to store the ScoreBoardFile, the default of /var/run/httpd.scoreboard is only used as a fallback.
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 more than one request per connection (in other words, it will allow persistent connections). KeepAlive can be used to prevent any one client from consuming too much of the server's resources.
By default Keepalive is set to off, which means that your server does not allow persistant connections. You could set it to on, which would enable persistant connections. In most cases you want Keepalive set to off because Apache can only have a limited number of child processes and these processes would be hanging around doing nothing waiting for a possible future connection from the same client. If you do enable Keepalives you should set the the KeepAliveTimeout (see the section called KeepAliveTimeout) low and monitor your servers error_log which will warn you if you are running out of child processes to handle requests.
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 most situations. You should not increase the MinSpareServers to a large number. Doing so 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 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 should 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 to keep a runaway Web server from crashing 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 1000.
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, 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.
For security reasons, Apache will refuse to run as User 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 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:
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 or files.
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.
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:
The server would look for the file:
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 0711. 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 will 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.
For more information about AddType, refer to the section called AddType.
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 loaded 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 will 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.
If you like to see the hostnames in your log files, consider running one of the many log analyser tools that perform the DNS lookups more efficiently and in bulk when you come to rotate your log files.
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 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. The actual LogFormat used will depend on the settings given in the CustomLog directive (see the section called CustomLog).
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 combined. The common logfile format looks like this:
remotehost rfc931 authuser [date] "request" status bytes referer user-agent
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.
Not used. You will see a - in the log file in its place.
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.
The date and time of the request.
The request string exactly as it came from the browser or client.
The HTTP status code which was returned to the browser or client.
The size of the document.
This can give the URL of the Web page which linked to the the current request.
This gives the name of the browser or client making the request.
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.
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.
For more advanced Redirection you can use the mod_rewrite module included with the server.
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:
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):
AddType text/html .shtml
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.
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.
The put module is no longer distributed as part of the Apache package. You will have to load the mod_put package separately.
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.
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 VirtualHost 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 can be used to set environment variables based on headers in the request. In the supplied httpd.conf file, it 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.
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.