-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Setting which addresses and ports Apache uses</TITLE>
-</HEAD>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
-<p>When Apache starts, it connects to some port and address on the
-local machine and waits for incoming requests. By default, it
-listens to all addresses on the machine, and to the port
-as specified by the <code>Port</code> directive in the server configuration.
-However, it can be told to listen to more the one port, or to listen
-to only selected addresses, or a combination. This is often combined
-with the Virtual Host feature which determines how Apache
-responds to different IP addresses, hostnames and ports.</p>
+ <title>Setting which addresses and ports Apache uses</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<p>The <code>Listen</code> directive tells the server to accept
-incoming requests only on the specified port or address-and-port
-combinations. If only a port number is specified in the
-<code>Listen</code> directive, the server listens to the given port on
-all interfaces, instead of the port given by the <code>Port</code>
-directive. If an IP address is given as well as a port, the server
-will listen on the given port and interface. Multiple Listen
-directives may be used to specify a number of addresses and ports to
-listen to. The server will respond to requests from any of the listed
-addresses and ports.</P>
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
-<p>For example, to make the server accept connections on both port
-80 and port 8000, use:
-<PRE>
+ <h1 align="CENTER">Setting which addresses and ports Apache
+ uses</h1>
+
+ <p>When Apache starts, it connects to some port and address on
+ the local machine and waits for incoming requests. By default,
+ it listens to all addresses on the machine, and to the port as
+ specified by the <code>Port</code> directive in the server
+ configuration. However, it can be told to listen to more the
+ one port, or to listen to only selected addresses, or a
+ combination. This is often combined with the Virtual Host
+ feature which determines how Apache responds to different IP
+ addresses, hostnames and ports.</p>
+
+ <p>The <code>Listen</code> directive tells the server to accept
+ incoming requests only on the specified port or
+ address-and-port combinations. If only a port number is
+ specified in the <code>Listen</code> directive, the server
+ listens to the given port on all interfaces, instead of the
+ port given by the <code>Port</code> directive. If an IP address
+ is given as well as a port, the server will listen on the given
+ port and interface. Multiple Listen directives may be used to
+ specify a number of addresses and ports to listen to. The
+ server will respond to requests from any of the listed
+ addresses and ports.</p>
+
+ <p>For example, to make the server accept connections on both
+ port 80 and port 8000, use:</p>
+<pre>
Listen 80
Listen 8000
-</PRE>
-
-To make the server accept connections on two specified
-interfaces and port numbers, use
-<PRE>
+</pre>
+ To make the server accept connections on two specified
+ interfaces and port numbers, use
+<pre>
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
-</PRE>
-
-<H2>How this works with Virtual Hosts</H2>
-
-<p>Listen does not implement Virtual Hosts. It only tells the
-main server what addresses and ports to listen to. If no
-<VirtualHost> directives are used, the server will behave the
-same for all accepted requests. However, <VirtualHost> can be
-used to specify a different behavior for one or more of the addresses
-and ports. To implement a VirtualHost, the server must first be told
-to listen to the address and port to be used. Then a
-<VirtualHost> section should be created for a specified address
-and port to set the behavior of this virtual host. Note that if the
-<VirtualHost> is set for an address and port that the server is
-not listening to, it cannot be accessed.
+</pre>
-<H2>See also</H2>
+ <h2>How this works with Virtual Hosts</h2>
-See also the documentation on
-<a href="mod/mpm_common.html#listen">Listen directive</a>,
-<A HREF="vhosts/">Virtual Hosts</A>,
-<A HREF="mod/core.html#port">Port directive</A>,
-<A HREF="dns-caveats.html">DNS Issues</A>
-and
-<A HREF="mod/core.html#virtualhost"><VirtualHost> section</A>.
+ <p>Listen does not implement Virtual Hosts. It only tells the
+ main server what addresses and ports to listen to. If no
+ <VirtualHost> directives are used, the server will behave
+ the same for all accepted requests. However,
+ <VirtualHost> can be used to specify a different behavior
+ for one or more of the addresses and ports. To implement a
+ VirtualHost, the server must first be told to listen to the
+ address and port to be used. Then a <VirtualHost> section
+ should be created for a specified address and port to set the
+ behavior of this virtual host. Note that if the
+ <VirtualHost> is set for an address and port that the
+ server is not listening to, it cannot be accessed.</p>
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+ <h2>See also</h2>
+ See also the documentation on <a
+ href="mod/mpm_common.html#listen">Listen directive</a>, <a
+ href="vhosts/">Virtual Hosts</a>, <a
+ href="mod/core.html#port">Port directive</a>, <a
+ href="dns-caveats.html">DNS Issues</a> and <a
+ href="mod/core.html#virtualhost"><VirtualHost>
+ section</a>. <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Setting which addresses and ports Apache uses</TITLE>
-</HEAD>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
-<p>When Apache starts, it connects to some port and address on the
-local machine and waits for incoming requests. By default, it
-listens to all addresses on the machine, and to the port
-as specified by the <code>Port</code> directive in the server configuration.
-However, it can be told to listen to more the one port, or to listen
-to only selected addresses, or a combination. This is often combined
-with the Virtual Host feature which determines how Apache
-responds to different IP addresses, hostnames and ports.</p>
+ <title>Setting which addresses and ports Apache uses</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<p>The <code>Listen</code> directive tells the server to accept
-incoming requests only on the specified port or address-and-port
-combinations. If only a port number is specified in the
-<code>Listen</code> directive, the server listens to the given port on
-all interfaces, instead of the port given by the <code>Port</code>
-directive. If an IP address is given as well as a port, the server
-will listen on the given port and interface. Multiple Listen
-directives may be used to specify a number of addresses and ports to
-listen to. The server will respond to requests from any of the listed
-addresses and ports.</P>
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
-<p>For example, to make the server accept connections on both port
-80 and port 8000, use:
-<PRE>
+ <h1 align="CENTER">Setting which addresses and ports Apache
+ uses</h1>
+
+ <p>When Apache starts, it connects to some port and address on
+ the local machine and waits for incoming requests. By default,
+ it listens to all addresses on the machine, and to the port as
+ specified by the <code>Port</code> directive in the server
+ configuration. However, it can be told to listen to more the
+ one port, or to listen to only selected addresses, or a
+ combination. This is often combined with the Virtual Host
+ feature which determines how Apache responds to different IP
+ addresses, hostnames and ports.</p>
+
+ <p>The <code>Listen</code> directive tells the server to accept
+ incoming requests only on the specified port or
+ address-and-port combinations. If only a port number is
+ specified in the <code>Listen</code> directive, the server
+ listens to the given port on all interfaces, instead of the
+ port given by the <code>Port</code> directive. If an IP address
+ is given as well as a port, the server will listen on the given
+ port and interface. Multiple Listen directives may be used to
+ specify a number of addresses and ports to listen to. The
+ server will respond to requests from any of the listed
+ addresses and ports.</p>
+
+ <p>For example, to make the server accept connections on both
+ port 80 and port 8000, use:</p>
+<pre>
Listen 80
Listen 8000
-</PRE>
-
-To make the server accept connections on two specified
-interfaces and port numbers, use
-<PRE>
+</pre>
+ To make the server accept connections on two specified
+ interfaces and port numbers, use
+<pre>
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
-</PRE>
-
-<H2>How this works with Virtual Hosts</H2>
-
-<p>Listen does not implement Virtual Hosts. It only tells the
-main server what addresses and ports to listen to. If no
-<VirtualHost> directives are used, the server will behave the
-same for all accepted requests. However, <VirtualHost> can be
-used to specify a different behavior for one or more of the addresses
-and ports. To implement a VirtualHost, the server must first be told
-to listen to the address and port to be used. Then a
-<VirtualHost> section should be created for a specified address
-and port to set the behavior of this virtual host. Note that if the
-<VirtualHost> is set for an address and port that the server is
-not listening to, it cannot be accessed.
+</pre>
-<H2>See also</H2>
+ <h2>How this works with Virtual Hosts</h2>
-See also the documentation on
-<a href="mod/mpm_common.html#listen">Listen directive</a>,
-<A HREF="vhosts/">Virtual Hosts</A>,
-<A HREF="mod/core.html#port">Port directive</A>,
-<A HREF="dns-caveats.html">DNS Issues</A>
-and
-<A HREF="mod/core.html#virtualhost"><VirtualHost> section</A>.
+ <p>Listen does not implement Virtual Hosts. It only tells the
+ main server what addresses and ports to listen to. If no
+ <VirtualHost> directives are used, the server will behave
+ the same for all accepted requests. However,
+ <VirtualHost> can be used to specify a different behavior
+ for one or more of the addresses and ports. To implement a
+ VirtualHost, the server must first be told to listen to the
+ address and port to be used. Then a <VirtualHost> section
+ should be created for a specified address and port to set the
+ behavior of this virtual host. Note that if the
+ <VirtualHost> is set for an address and port that the
+ server is not listening to, it cannot be accessed.</p>
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+ <h2>See also</h2>
+ See also the documentation on <a
+ href="mod/mpm_common.html#listen">Listen directive</a>, <a
+ href="vhosts/">Virtual Hosts</a>, <a
+ href="mod/core.html#port">Port directive</a>, <a
+ href="dns-caveats.html">DNS Issues</a> and <a
+ href="mod/core.html#virtualhost"><VirtualHost>
+ section</a>. <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>PATH_INFO Changes in the CGI Environment</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</H1>
-
-<HR>
-
-<H2><A NAME="over">Overview</A></H2>
-
-<P>As implemented in Apache 1.1.1 and earlier versions, the method
-Apache used to create PATH_INFO in the CGI environment was
-counterintuitive, and could result in crashes in certain cases. In
-Apache 1.2 and beyond, this behavior has changed. Although this
-results in some compatibility problems with certain legacy CGI
-applications, the Apache 1.2 behavior is still compatible with the
-CGI/1.1 specification, and CGI scripts can be easily modified (<A
-HREF="#compat">see below</A>).
-
-<H2><A NAME="prob">The Problem</A></H2>
-
-<P>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME
-environment variables by looking at the filename, not the URL. While
-this resulted in the correct values in many cases, when the filesystem
-path was overloaded to contain path information, it could result in
-errant behavior. For example, if the following appeared in a config
-file:
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>PATH_INFO Changes in the CGI Environment</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">PATH_INFO Changes in the CGI
+ Environment</h1>
+ <hr />
+
+ <h2><a id="over" name="over">Overview</a></h2>
+
+ <p>As implemented in Apache 1.1.1 and earlier versions, the
+ method Apache used to create PATH_INFO in the CGI environment
+ was counterintuitive, and could result in crashes in certain
+ cases. In Apache 1.2 and beyond, this behavior has changed.
+ Although this results in some compatibility problems with
+ certain legacy CGI applications, the Apache 1.2 behavior is
+ still compatible with the CGI/1.1 specification, and CGI
+ scripts can be easily modified (<a href="#compat">see
+ below</a>).</p>
+
+ <h2><a id="prob" name="prob">The Problem</a></h2>
+
+ <p>Apache 1.1.1 and earlier implemented the PATH_INFO and
+ SCRIPT_NAME environment variables by looking at the filename,
+ not the URL. While this resulted in the correct values in many
+ cases, when the filesystem path was overloaded to contain path
+ information, it could result in errant behavior. For example,
+ if the following appeared in a config file:</p>
+<pre>
Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph
-</PRE>
-<P>In this case, <CODE>user.cgi</CODE> is the CGI script, the "/ralph"
-is information to be passed onto the CGI. If this configuration was in
-place, and a request came for "<CODE>/cgi-ralph/script/</CODE>", the
-code would set PATH_INFO to "<CODE>/ralph/script</CODE>", and
-SCRIPT_NAME to "<CODE>/cgi-</CODE>". Obviously, the latter is
-incorrect. In certain cases, this could even cause the server to
-crash.</P>
-
-<H2><A NAME="solution">The Solution</A></H2>
-
-<P>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by
-looking directly at the URL, and determining how much of the URL is
-client-modifiable, and setting PATH_INFO to it. To use the above
-example, PATH_INFO would be set to "<CODE>/script</CODE>", and
-SCRIPT_NAME to "<CODE>/cgi-ralph</CODE>". This makes sense and results
-in no server behavior problems. It also permits the script to be
-guaranteed that
-"<CODE>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</CODE>"
-will always be an accessible URL that points to the current script,
-something which was not necessarily true with previous versions of
-Apache.
-
-<P>However, the "<CODE>/ralph</CODE>"
-information from the <CODE>Alias</CODE> directive is lost. This is
-unfortunate, but we feel that using the filesystem to pass along this
-sort of information is not a recommended method, and a script making
-use of it "deserves" not to work. Apache 1.2b3 and later, however, do
-provide <A HREF="#compat">a workaround.</A>
-
-<H2><A NAME="compat">Compatibility with Previous Servers</A></H2>
-
-<P>It may be necessary for a script that was designed for earlier
-versions of Apache or other servers to need the information that the
-old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3
-and later) sets an additional variable, FILEPATH_INFO. This
-environment variable contains the value that PATH_INFO would have had
-with Apache 1.1.1.</P>
-
-<P>A script that wishes to work with both Apache 1.2 and earlier
-versions can simply test for the existence of FILEPATH_INFO, and use
-it if available. Otherwise, it can use PATH_INFO. For example, in
-Perl, one might use:
-<PRE>
- $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-</PRE>
+</pre>
+
+ <p>In this case, <code>user.cgi</code> is the CGI script, the
+ "/ralph" is information to be passed onto the CGI. If this
+ configuration was in place, and a request came for
+ "<code>/cgi-ralph/script/</code>", the code would set PATH_INFO
+ to "<code>/ralph/script</code>", and SCRIPT_NAME to
+ "<code>/cgi-</code>". Obviously, the latter is incorrect. In
+ certain cases, this could even cause the server to crash.</p>
+
+ <h2><a id="solution" name="solution">The Solution</a></h2>
+
+ <p>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO
+ by looking directly at the URL, and determining how much of the
+ URL is client-modifiable, and setting PATH_INFO to it. To use
+ the above example, PATH_INFO would be set to
+ "<code>/script</code>", and SCRIPT_NAME to
+ "<code>/cgi-ralph</code>". This makes sense and results in no
+ server behavior problems. It also permits the script to be
+ guaranteed that
+ "<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"
+ will always be an accessible URL that points to the current
+ script, something which was not necessarily true with previous
+ versions of Apache.</p>
-<P>By doing this, a script can work with all servers supporting the
-CGI/1.1 specification, including all versions of Apache.</P>
+ <p>However, the "<code>/ralph</code>" information from the
+ <code>Alias</code> directive is lost. This is unfortunate, but
+ we feel that using the filesystem to pass along this sort of
+ information is not a recommended method, and a script making
+ use of it "deserves" not to work. Apache 1.2b3 and later,
+ however, do provide <a href="#compat">a workaround.</a></p>
+
+ <h2><a id="compat" name="compat">Compatibility with Previous
+ Servers</a></h2>
+
+ <p>It may be necessary for a script that was designed for
+ earlier versions of Apache or other servers to need the
+ information that the old PATH_INFO variable provided. For this
+ purpose, Apache 1.2 (1.2b3 and later) sets an additional
+ variable, FILEPATH_INFO. This environment variable contains the
+ value that PATH_INFO would have had with Apache 1.1.1.</p>
+
+ <p>A script that wishes to work with both Apache 1.2 and
+ earlier versions can simply test for the existence of
+ FILEPATH_INFO, and use it if available. Otherwise, it can use
+ PATH_INFO. For example, in Perl, one might use:</p>
+<pre>
+ $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
+</pre>
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+ <p>By doing this, a script can work with all servers supporting
+ the CGI/1.1 specification, including all versions of
+ Apache.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>PATH_INFO Changes in the CGI Environment</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</H1>
-
-<HR>
-
-<H2><A NAME="over">Overview</A></H2>
-
-<P>As implemented in Apache 1.1.1 and earlier versions, the method
-Apache used to create PATH_INFO in the CGI environment was
-counterintuitive, and could result in crashes in certain cases. In
-Apache 1.2 and beyond, this behavior has changed. Although this
-results in some compatibility problems with certain legacy CGI
-applications, the Apache 1.2 behavior is still compatible with the
-CGI/1.1 specification, and CGI scripts can be easily modified (<A
-HREF="#compat">see below</A>).
-
-<H2><A NAME="prob">The Problem</A></H2>
-
-<P>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME
-environment variables by looking at the filename, not the URL. While
-this resulted in the correct values in many cases, when the filesystem
-path was overloaded to contain path information, it could result in
-errant behavior. For example, if the following appeared in a config
-file:
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>PATH_INFO Changes in the CGI Environment</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">PATH_INFO Changes in the CGI
+ Environment</h1>
+ <hr />
+
+ <h2><a id="over" name="over">Overview</a></h2>
+
+ <p>As implemented in Apache 1.1.1 and earlier versions, the
+ method Apache used to create PATH_INFO in the CGI environment
+ was counterintuitive, and could result in crashes in certain
+ cases. In Apache 1.2 and beyond, this behavior has changed.
+ Although this results in some compatibility problems with
+ certain legacy CGI applications, the Apache 1.2 behavior is
+ still compatible with the CGI/1.1 specification, and CGI
+ scripts can be easily modified (<a href="#compat">see
+ below</a>).</p>
+
+ <h2><a id="prob" name="prob">The Problem</a></h2>
+
+ <p>Apache 1.1.1 and earlier implemented the PATH_INFO and
+ SCRIPT_NAME environment variables by looking at the filename,
+ not the URL. While this resulted in the correct values in many
+ cases, when the filesystem path was overloaded to contain path
+ information, it could result in errant behavior. For example,
+ if the following appeared in a config file:</p>
+<pre>
Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph
-</PRE>
-<P>In this case, <CODE>user.cgi</CODE> is the CGI script, the "/ralph"
-is information to be passed onto the CGI. If this configuration was in
-place, and a request came for "<CODE>/cgi-ralph/script/</CODE>", the
-code would set PATH_INFO to "<CODE>/ralph/script</CODE>", and
-SCRIPT_NAME to "<CODE>/cgi-</CODE>". Obviously, the latter is
-incorrect. In certain cases, this could even cause the server to
-crash.</P>
-
-<H2><A NAME="solution">The Solution</A></H2>
-
-<P>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by
-looking directly at the URL, and determining how much of the URL is
-client-modifiable, and setting PATH_INFO to it. To use the above
-example, PATH_INFO would be set to "<CODE>/script</CODE>", and
-SCRIPT_NAME to "<CODE>/cgi-ralph</CODE>". This makes sense and results
-in no server behavior problems. It also permits the script to be
-guaranteed that
-"<CODE>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</CODE>"
-will always be an accessible URL that points to the current script,
-something which was not necessarily true with previous versions of
-Apache.
-
-<P>However, the "<CODE>/ralph</CODE>"
-information from the <CODE>Alias</CODE> directive is lost. This is
-unfortunate, but we feel that using the filesystem to pass along this
-sort of information is not a recommended method, and a script making
-use of it "deserves" not to work. Apache 1.2b3 and later, however, do
-provide <A HREF="#compat">a workaround.</A>
-
-<H2><A NAME="compat">Compatibility with Previous Servers</A></H2>
-
-<P>It may be necessary for a script that was designed for earlier
-versions of Apache or other servers to need the information that the
-old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3
-and later) sets an additional variable, FILEPATH_INFO. This
-environment variable contains the value that PATH_INFO would have had
-with Apache 1.1.1.</P>
-
-<P>A script that wishes to work with both Apache 1.2 and earlier
-versions can simply test for the existence of FILEPATH_INFO, and use
-it if available. Otherwise, it can use PATH_INFO. For example, in
-Perl, one might use:
-<PRE>
- $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-</PRE>
+</pre>
+
+ <p>In this case, <code>user.cgi</code> is the CGI script, the
+ "/ralph" is information to be passed onto the CGI. If this
+ configuration was in place, and a request came for
+ "<code>/cgi-ralph/script/</code>", the code would set PATH_INFO
+ to "<code>/ralph/script</code>", and SCRIPT_NAME to
+ "<code>/cgi-</code>". Obviously, the latter is incorrect. In
+ certain cases, this could even cause the server to crash.</p>
+
+ <h2><a id="solution" name="solution">The Solution</a></h2>
+
+ <p>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO
+ by looking directly at the URL, and determining how much of the
+ URL is client-modifiable, and setting PATH_INFO to it. To use
+ the above example, PATH_INFO would be set to
+ "<code>/script</code>", and SCRIPT_NAME to
+ "<code>/cgi-ralph</code>". This makes sense and results in no
+ server behavior problems. It also permits the script to be
+ guaranteed that
+ "<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"
+ will always be an accessible URL that points to the current
+ script, something which was not necessarily true with previous
+ versions of Apache.</p>
-<P>By doing this, a script can work with all servers supporting the
-CGI/1.1 specification, including all versions of Apache.</P>
+ <p>However, the "<code>/ralph</code>" information from the
+ <code>Alias</code> directive is lost. This is unfortunate, but
+ we feel that using the filesystem to pass along this sort of
+ information is not a recommended method, and a script making
+ use of it "deserves" not to work. Apache 1.2b3 and later,
+ however, do provide <a href="#compat">a workaround.</a></p>
+
+ <h2><a id="compat" name="compat">Compatibility with Previous
+ Servers</a></h2>
+
+ <p>It may be necessary for a script that was designed for
+ earlier versions of Apache or other servers to need the
+ information that the old PATH_INFO variable provided. For this
+ purpose, Apache 1.2 (1.2b3 and later) sets an additional
+ variable, FILEPATH_INFO. This environment variable contains the
+ value that PATH_INFO would have had with Apache 1.1.1.</p>
+
+ <p>A script that wishes to work with both Apache 1.2 and
+ earlier versions can simply test for the existence of
+ FILEPATH_INFO, and use it if available. Otherwise, it can use
+ PATH_INFO. For example, in Perl, one might use:</p>
+<pre>
+ $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
+</pre>
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+ <p>By doing this, a script can work with all servers supporting
+ the CGI/1.1 specification, including all versions of
+ Apache.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Configuration Files</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Configuration Files</H1>
-
-<ul>
-<li><a href="#main">Main Configuration Files</a></li>
-<li><a href="#syntax">Syntax of the Configuration Files</a></li>
-<li><a href="#modules">Modules</a></li>
-<li><a href="#scope">Scope of Directives</a></li>
-<li><a href="#htaccess">.htaccess Files</a></li>
-</ul>
-
-<hr>
-
-<H2><a name="main">Main Configuration Files</a></H2>
-
-<table border="1"><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-<a href="mod/mod_mime.html">mod_mime</a><br>
-</td>
-
-<td valign="top">
-<strong>Related Directives</strong><br><br>
-<A HREF="mod/core.html#ifdefine"><IfDefine></A><br>
-<a href="mod/core.html#include">Include</a><br>
-<A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A><br>
-</td></tr></table>
-
-<P>Apache is configured by placing <A HREF="mod/directives.html"
->directives</A> in plain text configuration files. The main
-configuration file is usually called <CODE>httpd.conf</CODE>. The
-location of this file is set at compile-time, but may be overridden
-with the <CODE>-f</CODE> command line flag. In addition, other
-configuration files may be added using the <CODE><A
-HREF="mod/core.html#include">Include</A></CODE> directive. Any
-directive may be placed in any of these configuration files. Changes
-to the main configuration files are only recognized by Apache when it
-is started or restarted.</p>
-
-<P>New with Apache 1.3.13 is a feature where if any configuration
-file is actually a directory, Apache will enter that directory
-and parse any files (and subdirectories) found there as configuration
-files. One possible use for this would be to add VirtualHosts
-by creating small configuration files for each host, and placing
-them in such a configuration directory. Thus, you can add or
-remove VirtualHosts without editing any files at all, simply
-adding or deleting them. This makes automating such processes
-much easier.
-
-<P>
-The server also reads a file containing mime document types; the
-filename is set by the <A HREF="mod/mod_mime.html#typesconfig"
->TypesConfig</A> directive, and is <CODE>mime.types</CODE> by default.
-
-<hr>
-
-<H2><a name="syntax">Syntax of the Configuration Files</a></H2>
-
-<P>Apache configuration files contain one directive per line. The
-back-slash "\" may be used as the last character on a line to indicate
-that the directive continues onto the next line. There must be no
-other characters or white space between the back-slash and the end of
-the line.
-
-<P>Directives in the configuration files are case-insensitive, but
-arguments to directives are often case sensitive. Lines which begin
-with the hash character "#" are considered comments, and are ignored.
-Comments may <STRONG>not</STRONG> be included on a line after a
-configuration directive. Blank lines and white space occurring before
-a directive are ignored, so you may indent directives for clarity.
-
-<P>You can check your configuration files for syntax errors without
-starting the server by using <CODE>apachectl configtest</CODE>
-or the <CODE>-t</CODE> command line option.
-
-<hr>
-
-<H2><a name="modules">Modules</a></H2>
-
-<table border="1"><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-<a href="mod/mod_so.html">mod_so</a><br>
-</td>
-<td valign="top">
-<strong>Related Directives</strong><br><br>
-<A HREF="mod/core.html#addmodule">AddModule</A><br>
-<A HREF="mod/core.html#clearmodulelist">ClearModuleList</A><br>
-<A HREF="mod/core.html#ifmodule"><IfModule></A><br>
-<a href="mod/mod_so.html#loadmodule">LoadModule</a><br>
-</td></tr></table>
-
-<P>Apache is a modular server. This implies that only the most basic
-functionality is included in the core server. Extended features are
-available through <A HREF="mod/index-bytype.html">modules</A> which
-can be loaded into Apache. By default, a <A
-HREF="mod/module-dict.html#Status">base</A> set of modules is
-included in the server at compile-time. If the server is compiled to
-use <A HREF="dso.html">dynamically loaded</A> modules, then modules
-can be compiled separately and added at any time using the <A
-HREF="mod/mod_so.html#loadmodule">LoadModule</A> directive.
-Otherwise, Apache must be recompiled to add or remove modules.
-Configuration directives may be included conditional on a presence of
-a particular module by enclosing them in an <A
-HREF="mod/core.html#ifmodule"><IfModule></A> block.
-
-<P>To see which modules are currently compiled into the server,
-you can use the <CODE>-l</CODE> command line option.
-
-<hr>
-
-<H2><a name="scope">Scope of Directives</a></H2>
-
-<table border="1"><tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-<A HREF="mod/core.html#directory"><Directory></A><br>
-<A HREF="mod/core.html#directorymatch"><DirectoryMatch></A><br>
-<A HREF="mod/core.html#files"><Files></A><br>
-<A HREF="mod/core.html#filesmatch"><FilesMatch></A><br>
-<A HREF="mod/core.html#location"><Location></A><br>
-<A HREF="mod/core.html#locationmatch"><LocationMatch></A><br>
-<a href="mod/core.html#virtualhost"><VirtualHost></a><br>
-</td></tr></table>
-
-<P>Directives placed in the main configuration files apply to the entire
-server. If you wish to change the configuration for only a part of
-the server, you can scope your directives by placing them in
-<CODE><A HREF="mod/core.html#directory"><Directory></A>,
-<A HREF="mod/core.html#directorymatch"><DirectoryMatch></A>,
-<A HREF="mod/core.html#files"><Files></A>,
-<A HREF="mod/core.html#filesmatch"><FilesMatch></A>,
-<A HREF="mod/core.html#location"><Location></A>,
-</CODE> and <CODE>
-<A HREF="mod/core.html#locationmatch"><LocationMatch></A>
-</CODE>
-sections. These sections limit the application of the directives
-which they enclose to particular filesystem locations or URLs. They
-can also be nested, allowing for very fine grained configuration.
-
-<P>Apache has the capability to serve many different websites
-simultaneously. This is called <A HREF="vhosts/">Virtual Hosting</A>.
-Directives can also be scoped by placing them inside
-<CODE><A HREF="mod/core.html#virtualhost"><VirtualHost></A></CODE>
-sections, so that they will only apply to requests for a particular
-website.
-
-<P>Although most directives can be placed in any of these sections,
-some directives do not make sense in some contexts. For example,
-directives controlling process creation can only be placed in the main
-server context. To find which directives can be placed in which
-sections, check the <A
-HREF="mod/directive-dict.html#Context">Context</A> of the directive.
-For further information, we provide details on <A
-HREF="sections.html">How Directory, Location and Files sections
-work</A>.
-
-<hr>
-
-<H2><a name="htaccess">.htaccess Files</a></H2>
-
-<table border="1"><tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-<A HREF="mod/core.html#accessfilename">AccessFileName</A><br>
-<A HREF="mod/core.html#allowoverride">AllowOverride</A><br>
-</td></tr></table>
-
-<P>Apache allows for decentralized management of configuration via
-special files placed inside the web tree. The special files are
-usually called <CODE>.htaccess</CODE>, but any name can be specified
-in the <A HREF="mod/core.html#accessfilename"><CODE
->AccessFileName</CODE></A> directive. Directives placed in
-<CODE>.htaccess</CODE> files apply to the directory where you place
-the file, and all sub-directories. The <CODE>.htaccess</CODE> files
-follow the same syntax as the main configuration files. Since
-<CODE>.htaccess</CODE> files are read on every request, changes made
-in these files take immediate effect.
-
-<P>To find which directives can be placed in <CODE>.htaccess</CODE>
-files, check the <A HREF="mod/directive-dict.html#Context">Context</A>
-of the directive. The server administrator further controls what
-directives may be placed in <CODE>.htaccess</CODE> files by
-configuring the <A
-HREF="mod/core.html#allowoverride"><CODE>AllowOverride</CODE></A>
-directive in the main configuration files.
-
-<p>For more information on <code>.htaccess</code> files, see Ken
-Coar's tutorial on <a
-href="http://apache-server.com/tutorials/ATusing-htaccess.html">Using
-.htaccess Files with Apache</a>.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Configuration Files</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Configuration Files</h1>
+
+ <ul>
+ <li><a href="#main">Main Configuration Files</a></li>
+
+ <li><a href="#syntax">Syntax of the Configuration
+ Files</a></li>
+
+ <li><a href="#modules">Modules</a></li>
+
+ <li><a href="#scope">Scope of Directives</a></li>
+
+ <li><a href="#htaccess">.htaccess Files</a></li>
+ </ul>
+ <hr />
+
+ <h2><a id="main" name="main">Main Configuration Files</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_mime.html">mod_mime</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/core.html#ifdefine"><IfDefine></a><br />
+ <a href="mod/core.html#include">Include</a><br />
+ <a
+ href="mod/mod_mime.html#typesconfig">TypesConfig</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>Apache is configured by placing <a
+ href="mod/directives.html">directives</a> in plain text
+ configuration files. The main configuration file is usually
+ called <code>httpd.conf</code>. The location of this file is
+ set at compile-time, but may be overridden with the
+ <code>-f</code> command line flag. In addition, other
+ configuration files may be added using the <code><a
+ href="mod/core.html#include">Include</a></code> directive. Any
+ directive may be placed in any of these configuration files.
+ Changes to the main configuration files are only recognized by
+ Apache when it is started or restarted.</p>
+
+ <p>New with Apache 1.3.13 is a feature where if any
+ configuration file is actually a directory, Apache will enter
+ that directory and parse any files (and subdirectories) found
+ there as configuration files. One possible use for this would
+ be to add VirtualHosts by creating small configuration files
+ for each host, and placing them in such a configuration
+ directory. Thus, you can add or remove VirtualHosts without
+ editing any files at all, simply adding or deleting them. This
+ makes automating such processes much easier.</p>
+
+ <p>The server also reads a file containing mime document types;
+ the filename is set by the <a
+ href="mod/mod_mime.html#typesconfig">TypesConfig</a> directive,
+ and is <code>mime.types</code> by default.</p>
+ <hr />
+
+ <h2><a id="syntax" name="syntax">Syntax of the Configuration
+ Files</a></h2>
+
+ <p>Apache configuration files contain one directive per line.
+ The back-slash "\" may be used as the last character on a line
+ to indicate that the directive continues onto the next line.
+ There must be no other characters or white space between the
+ back-slash and the end of the line.</p>
+
+ <p>Directives in the configuration files are case-insensitive,
+ but arguments to directives are often case sensitive. Lines
+ which begin with the hash character "#" are considered
+ comments, and are ignored. Comments may <strong>not</strong> be
+ included on a line after a configuration directive. Blank lines
+ and white space occurring before a directive are ignored, so
+ you may indent directives for clarity.</p>
+
+ <p>You can check your configuration files for syntax errors
+ without starting the server by using <code>apachectl
+ configtest</code> or the <code>-t</code> command line
+ option.</p>
+ <hr />
+
+ <h2><a id="modules" name="modules">Modules</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_so.html">mod_so</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/core.html#addmodule">AddModule</a><br />
+ <a
+ href="mod/core.html#clearmodulelist">ClearModuleList</a><br />
+ <a
+ href="mod/core.html#ifmodule"><IfModule></a><br />
+ <a href="mod/mod_so.html#loadmodule">LoadModule</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>Apache is a modular server. This implies that only the most
+ basic functionality is included in the core server. Extended
+ features are available through <a
+ href="mod/index-bytype.html">modules</a> which can be loaded
+ into Apache. By default, a <a
+ href="mod/module-dict.html#Status">base</a> set of modules is
+ included in the server at compile-time. If the server is
+ compiled to use <a href="dso.html">dynamically loaded</a>
+ modules, then modules can be compiled separately and added at
+ any time using the <a
+ href="mod/mod_so.html#loadmodule">LoadModule</a> directive.
+ Otherwise, Apache must be recompiled to add or remove modules.
+ Configuration directives may be included conditional on a
+ presence of a particular module by enclosing them in an <a
+ href="mod/core.html#ifmodule"><IfModule></a> block.</p>
+
+ <p>To see which modules are currently compiled into the server,
+ you can use the <code>-l</code> command line option.</p>
+ <hr />
+
+ <h2><a id="scope" name="scope">Scope of Directives</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/core.html#directory"><Directory></a><br />
+ <a
+ href="mod/core.html#directorymatch"><DirectoryMatch></a><br />
+ <a href="mod/core.html#files"><Files></a><br />
+ <a
+ href="mod/core.html#filesmatch"><FilesMatch></a><br />
+ <a
+ href="mod/core.html#location"><Location></a><br />
+ <a
+ href="mod/core.html#locationmatch"><LocationMatch></a><br />
+ <a
+ href="mod/core.html#virtualhost"><VirtualHost></a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>Directives placed in the main configuration files apply to
+ the entire server. If you wish to change the configuration for
+ only a part of the server, you can scope your directives by
+ placing them in <code><a
+ href="mod/core.html#directory"><Directory></a>, <a
+ href="mod/core.html#directorymatch"><DirectoryMatch></a>,
+ <a href="mod/core.html#files"><Files></a>, <a
+ href="mod/core.html#filesmatch"><FilesMatch></a>, <a
+ href="mod/core.html#location"><Location></a>,</code> and
+ <code><a
+ href="mod/core.html#locationmatch"><LocationMatch></a></code>
+ sections. These sections limit the application of the
+ directives which they enclose to particular filesystem
+ locations or URLs. They can also be nested, allowing for very
+ fine grained configuration.</p>
+
+ <p>Apache has the capability to serve many different websites
+ simultaneously. This is called <a href="vhosts/">Virtual
+ Hosting</a>. Directives can also be scoped by placing them
+ inside <code><a
+ href="mod/core.html#virtualhost"><VirtualHost></a></code>
+ sections, so that they will only apply to requests for a
+ particular website.</p>
+
+ <p>Although most directives can be placed in any of these
+ sections, some directives do not make sense in some contexts.
+ For example, directives controlling process creation can only
+ be placed in the main server context. To find which directives
+ can be placed in which sections, check the <a
+ href="mod/directive-dict.html#Context">Context</a> of the
+ directive. For further information, we provide details on <a
+ href="sections.html">How Directory, Location and Files sections
+ work</a>.</p>
+ <hr />
+
+ <h2><a id="htaccess" name="htaccess">.htaccess Files</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/core.html#accessfilename">AccessFileName</a><br />
+ <a
+ href="mod/core.html#allowoverride">AllowOverride</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>Apache allows for decentralized management of configuration
+ via special files placed inside the web tree. The special files
+ are usually called <code>.htaccess</code>, but any name can be
+ specified in the <a
+ href="mod/core.html#accessfilename"><code>AccessFileName</code></a>
+ directive. Directives placed in <code>.htaccess</code> files
+ apply to the directory where you place the file, and all
+ sub-directories. The <code>.htaccess</code> files follow the
+ same syntax as the main configuration files. Since
+ <code>.htaccess</code> files are read on every request, changes
+ made in these files take immediate effect.</p>
+
+ <p>To find which directives can be placed in
+ <code>.htaccess</code> files, check the <a
+ href="mod/directive-dict.html#Context">Context</a> of the
+ directive. The server administrator further controls what
+ directives may be placed in <code>.htaccess</code> files by
+ configuring the <a
+ href="mod/core.html#allowoverride"><code>AllowOverride</code></a>
+ directive in the main configuration files.</p>
+
+ <p>For more information on <code>.htaccess</code> files, see
+ Ken Coar's tutorial on <a
+ href="http://apache-server.com/tutorials/ATusing-htaccess.html">
+ Using .htaccess Files with Apache</a>.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>\e$B@_Dj%U%!%$%k\e(B</title>
-</head>
-<!-- English revision: 1.8 -->
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000FF"
- vlink="#000080"
- alink="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="CENTER">\e$B%U%!%$%k$N@_Dj\e(B</h1>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
-<ul>
-<li><a href="#main">\e$B%a%$%s$N@_Dj%U%!%$%k\e(B</a></li>
-<li><a href="#syntax">\e$B@_Dj%U%!%$%k$N9=J8\e(B</a></li>
-<li><a href="#modules">\e$B%b%8%e!<%k\e(B</a></li>
-<li><a href="#scope">\e$B%G%#%l%/%F%#%V$NE,MQHO0O\e(B</a></li>
-<li><a href="#htaccess">.htaccess \e$B%U%!%$%k\e(B</a></li>
-<li><a href="#logs">\e$B%m%0%U%!%$%k\e(B</a></li>
-</ul>
+ <title>$B@_Dj%U%!%$%k(B</title>
+ </head>
+ <!-- English revision: 1.8 -->
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<hr>
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
-<h2><a name="main">\e$B%a%$%s$N@_Dj%U%!%$%k\e(B</a></h2>
+ <h1 align="CENTER">$B%U%!%$%k$N@_Dj(B</h1>
-<table border="1"><tr><td valign="top">
-<strong>\e$B4XO"%b%8%e!<%k\e(B</strong><br><br>
-<a href="mod/mod_mime.html">mod_mime</a><br>
-</td>
+ <ul>
+ <li><a
+ href="#main">$B%a%$%s$N@_Dj%U%!%$%k(B</a></li>
-<td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-<a href="mod/core.html#ifdefine"><IfDefine></a><br>
-<a href="mod/core.html#include">Include</a><br>
-<a href="mod/mod_mime.html#typesconfig">TypesConfig</a><br>
-</td></tr></table>
+ <li><a
+ href="#syntax">$B@_Dj%U%!%$%k$N9=J8(B</a></li>
-<p>Apache
\e$B$O
\e(B <a href="mod/directives.html">
\e$B%G%#%l%/%F%#%V
\e(B</a>
\e$B$r
\e(B
-\e$B@_Dj%U%!%$%k$KJ?J8$G=q$/$3$H$K$h$j@_Dj$7$^$9!#%a%$%s$N\e(B
-\e$B@_Dj%U%!%$%k$OIaDL$O\e(B <code>httpd.conf</code> \e$B$H$$$&L>A0$G$9!#\e(B
-\e$B$3$N%U%!%$%k$N0LCV$O%3%s%Q%$%k;~$K@_Dj$5$l$^$9$,!"%3%^%s%I%i%$%s$N\e(B
-<code>-f</code> \e$B%U%i%0$K$h$j>e=q$-$G$-$^$9!#$=$N>e!"B>$N@_Dj%U%!%$%k$,\e(B
-<code><a href="mod/core.html#include">Include</a></code> \e$B%G%#%l%/%F%#%V\e(B
-\e$B$K$h$C$FDI2C$5$l$F$$$k$+$b$7$l$^$;$s!#$I$N%G%#%l%/%F%#%V$b\e(B
-\e$B$3$l$i$N@_Dj%U%!%$%k$N$I$l$K$G$bF~$l$i$l$^$9!#\e(BApache \e$B$O5/F0;~$+\e(B
-\e$B:F5/F0;~$N$_%a%$%s@_Dj%U%!%$%k$NJQ99$rG'<1$7$^$9!#\e(B</p>
-
-<p>Apache 1.3.13 \e$B$N?7$7$$5!G=$H$7$F!"@_Dj%U%!%$%k$,<B:]$O%G%#%l%/%H%j$G\e(B
-\e$B$"$k$H$-$K$O$=$N%G%#%l%/%H%j$G8+$D$+$C$?$9$Y$F$N%U%!%$%k\e(B
-(\e$B$H%5%V%G%#%l%/%H%j\e(B) \e$B$r2r@O$9$k$H$$$&$b$N$,$"$j$^$9!#MxMQK!$H$7$F$O!"\e(B
-\e$B%P!<%A%c%k%[%9%H$rDI2C$9$k$H$-$K!"$=$l$>$l$N%[%9%H$KBP$7$F>.$5$J@_Dj\e(B
-\e$B%U%!%$%k$r:n$j!"@_Dj%G%#%l%/%H%j$KCV$/$H$$$&$b$N$,5s$2$i$l$^$9!#\e(B
-\e$B$3$&$9$k$H!"C1$K%U%!%$%k$NDI2C!":o=|$r$9$k$3$H$K$h$jA4$/%U%!%$%k$r\e(B
-\e$BJT=8$9$k$3$H$J$/%P!<%A%c%k%[%9%H$NDI2C!":o=|$,$G$-$^$9!#$3$l$O<+F02=$r\e(B
-\e$B$:$C$H4JC1$K$7$^$9!#\e(B</p>
-
-<p>
-\e$B%5!<%P$O\e(B mime \e$B%I%-%e%a%s%H%?%$%W$r4^$s$G$$$k%U%!%$%k$bFI$_9~$_$^$9!#\e(B
-
\e$B%U%!%$%kL>$O
\e(B <a href="mod/mod_mime.html#typesconfig"
->TypesConfig</a> \e$B$G@_Dj$5$l!"%G%U%)%k%H$G\e(B <code>mime.types</code>
-\e$B$K$J$C$F$$$^$9!#\e(B</p>
-<hr>
-
-<h2><a name="syntax">\e$B@_Dj%U%!%$%k$N9=J8\e(B</a></h2>
-
-<p>Apache \e$B@_Dj%U%!%$%k$O\e(B1\e$B9T$K\e(B1\e$B$D$N%G%#%l%/%F%#%V$+$i$J$j$^$9!#\e(B
-\e$B%P%C%/%9%i%C%7%e\e(B "\" \e$B$O%G%#%l%/%F%#%V$,<!$N9T$K7QB3$7$F$$$k$3$H$r\e(B
-\e$B<($9$?$a$K9T$N:G8e$NJ8;z$H$7$F;H$o$l$F$$$k$+$b$7$l$^$;$s!#\e(B
-\e$B9T$N:G8e$H%P%C%/%9%i%C%7%e$N4V$KB>$NJ8;z$d6uGr$,$"$C$F$O$$$1$^$;$s!#\e(B</p>
-
-<p>\e$B@_Dj%U%!%$%k$N%G%#%l%/%F%#%V$OBgJ8;z>.J8;z$r6hJL$7$^$;$s$,!"\e(B
-\e$B0z?t$K$O$7$P$7$P6hJL$9$k$b$N$,$"$j$^$9!#%O%C%7%eJ8;z\e(B "#" \e$B$G;O$^$k9T$O\e(B
-\e$B%3%a%s%H$H8+$J$5$l$FL5;k$5$l$^$9!#@_Dj%G%#%l%/%F%#%V$N8e$N9T$G$O\e(B
-\e$B%3%a%s%H$,4^$^$l$F$$$F$O\e(B<strong>\e$B$$$1$^$;$s\e(B</strong>\e$B!#%G%#%l%/%F%#%V$N\e(B
-\e$BA0$N6u9T$H6uGr$OL5;k$5$l$^$9$N$G!"$o$+$j$d$9$/$9$k$?$a$K%G%#%l%/%F%#%V$r\e(B
-\e$B%$%s%G%s%H$9$k$3$H$,$G$-$^$9!#\e(B</p>
-
-<p>\e$B@_Dj%U%!%$%k$N9=J8%(%i!<$O\e(B
-<code>apachectl configtest</code> \e$B$+%3%^%s%I%i%$%s%*%W%7%g%s\e(B
-<code>-t</code> \e$B$r;H$C$FD4$Y$i$l$^$9!#\e(B</p>
-
-<hr>
-
-<h2><a name="modules">\e$B%b%8%e!<%k\e(B</a></h2>
-
-<table border="1"><tr><td valign="top">
-<strong>\e$B4XO"%b%8%e!<%k\e(B</strong><br><br>
-<a href="mod/mod_so.html">mod_so</a><br>
-</td>
-<td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-<a href="mod/core.html#addmodule">AddModule</a><br>
-<a href="mod/core.html#clearmodulelist">ClearModuleList</a><br>
-<a href="mod/core.html#ifmodule"><IfModule></a><br>
-<a href="mod/mod_so.html#loadmodule">LoadModule</a><br>
-</td></tr></table>
-
-<p>Apache \e$B$O%b%8%e!<%k2=$5$l$?%5!<%P$G$9!#%3%"%5!<%P$K$O\e(B
-\e$B0lHV4pK\E*$J5!G=$@$1$,4^$^$l$F$$$^$9!#3HD%5!G=$O\e(B Apache \e$B$K\e(B
-
\e$B%m!<%I$5$l$k
\e(B<a href="mod/index-bytype.html">
\e$B%b%8%e!<%k
\e(B</a>
\e$B$H$7$F
\e(B
-
\e$BMxMQ2DG=$G$9!#%G%U%)%k%H$G$O%3%s%Q%$%k;~$K%b%8%e!<%k$N
\e(B<a
-href="mod/module-dict.html#Status">\e$B4pK\\e(B</a>\e$B%;%C%H$,\e(B
-
\e$B%5!<%P$K4^$^$l$^$9!#%5!<%P$,
\e(B<a href="dso.html">
\e$BF0E*%m!<%I
\e(B</a>
\e$B%b%8%e!<%k$r
\e(B
-\e$B;H$&$h$&$K%3%s%Q%$%k$5$l$F$$$k>l9g$O!"%b%8%e!<%k$rJL$K%3%s%Q%$%k$7$F!"\e(B
-
\e$B$$$D$G$b
\e(B <a href="mod/mod_so.html#loadmodule">LoadModule</a>
-\e$B%G%#%l%/%F%#%V$r;H$C$FDI2C$G$-$^$9!#$=$&$G$J$$>l9g$O!"%b%8%e!<%k$N\e(B
-\e$BDI2C$d:o=|$r$9$k$?$a$K$O\e(B Apache \e$B$r:F%3%s%Q%$%k$9$kI,MW$,$"$j$^$9!#\e(B
-
\e$B@_Dj%G%#%l%/%F%#%V$O
\e(B <a
-href="mod/core.html#ifmodule"><IfModule></a> \e$B%V%m%C%/$K\e(B
-\e$BF~$l$k$3$H$GFCDj$N%b%8%e!<%k$,B8:_$9$k$H$-$@$1\e(B
-\e$B@_Dj%U%!%$%k$K4^$^$l$k$h$&$K$9$k$3$H$,$G$-$^$9!#\e(B</p>
-
-<p>\e$B%3%^%s%I%i%$%s%*%W%7%g%s\e(B <code>-l</code> \e$B$r;H$C$F\e(B
-\e$B8=;~E@$G$I$N%b%8%e!<%k$,%5!<%P$K%3%s%Q%$%k$5$l$F$$$k$+$r\e(B
-\e$BCN$k$3$H$,$G$-$^$9!#\e(B
-
-<hr>
-
-<h2><a name="scope">\e$B%G%#%l%/%F%#%V$NE,MQHO0O\e(B</a></h2>
-
-<table border="1"><tr><td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-<a href="mod/core.html#directory"><Directory></a><br>
-<a href="mod/core.html#directorymatch"><DirectoryMatch></a><br>
-<a href="mod/core.html#files"><Files></a><br>
-<a href="mod/core.html#filesmatch"><FilesMatch></a><br>
-<a href="mod/core.html#location"><Location></a><br>
-<a href="mod/core.html#locationmatch"><LocationMatch></a><br>
-<a href="mod/core.html#virtualhost"><VirtualHost></a><br>
-</td></tr></table>
-
-<p>\e$B%a%$%s@_Dj%U%!%$%k$K$"$k%G%#%l%/%F%#%V$O%5!<%PA4BN$KE,MQ$5$l$^$9!#\e(B
-\e$B%5!<%P$N0lItJ,$N@_Dj$@$1$rJQ99$7$?$$>l9g$O\e(B
-<code><a href="mod/core.html#directory"><Directory></a>,
-<a href="mod/core.html#directorymatch"><DirectoryMatch></a>,
-<a href="mod/core.html#files"><Files></a>,
-<a href="mod/core.html#filesmatch"><FilesMatch></a>,
-<a href="mod/core.html#location"><Location></a>,
-<a href="mod/core.html#locationmatch"><LocationMatch></a>
-</code>
-\e$B%;%/%7%g%s$NCf$KCV$/$3$H$GE,MQHO0O$r7h$a$i$l$^$9!#$3$l$i$N%;%/%7%g%s$O\e(B
-\e$B$=$NCf$K$"$k%G%#%l%/%F%#%V$NE,MQHO0O$rFCDj$N%U%!%$%k%7%9%F%`$N0LCV$d\e(B
-URL \e$B$K8BDj$7$^$9!#Hs>o$K:YN3EY$N@_Dj$r2DG=$K$9$k$?$a$K!"%;%/%7%g%s$r\e(B
-\e$BF~$l;R$K$9$k$3$H$b$G$-$^$9!#\e(B</p>
-
-<p>Apache \e$B$OF1;~$KB?$/$N0c$&%&%'%V%5%$%H$r07$&G=NO$,$"$j$^$9!#\e(B
-
\e$B$3$l$O
\e(B <a href="vhosts/">
\e$B%P!<%A%c%k%[%9%H
\e(B</a>
\e$B$H8F$P$l$F$$$^$9!#
\e(B
-\e$BFCDj$N%&%'%V%5%$%H$K$N$_E,MQ$5$l$k$h$&$K$9$k$?$a$K!"%G%#%l%/%F%#%V$O\e(B
-<code><a href="mod/core.html#virtualhost"><VirtualHost></a></code>
-\e$B%;%/%7%g%s$NCf$KCV$/$3$H$G$bE,MQHO0O$rJQ$($k$3$H$,$G$-$^$9!#\e(B</p>
-
-<p>\e$B$[$H$s$I$N%G%#%l%/%F%#%V$O$I$N%;%/%7%g%s$K$G$b=q$1$^$9$,!"\e(B
-\e$BCf$K$O%3%s%F%-%9%H$K$h$C$F$O0UL#$r$J$5$J$$$b$N$b$"$j$^$9!#Nc$($P!"\e(B
-\e$B%W%m%;%9$N:n@.$r@)8f$7$F$$$k%G%#%l%/%F%#%V$O%a%$%s%5!<%P$N%3%s%F%-%9%H$K\e(B
-\e$B$N$_=q$/$3$H$,$G$-$^$9!#$I$N%G%#%l%/%F%#%V$r$I$N%;%/%7%g%s$K=q$/$3$H$,\e(B
-\e$B$G$-$k$+$rCN$k$?$a$K$O%G%#%l%/%F%#%V$N\e(B
-<a href="mod/directive-dict.html#Context">\e$B%3%s%F%-%9%H\e(B</a>\e$B$rD4$Y$F$/$@$5$$!#\e(B
-
\e$B>\$7$$>pJs$O!"
\e(B<a
-href="sections.html">Directory, Location, Files \e$B%;%/%7%g%s$NF0:nK!\e(B</a>
-\e$B$K$"$j$^$9!#\e(B</p>
-
-<hr>
-
-<h2><a name="htaccess">.htaccess \e$B%U%!%$%k\e(B</a></h2>
-
-<table border="1"><tr><td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-<a href="mod/core.html#accessfilename">AccessFileName</a><br>
-<a href="mod/core.html#allowoverride">AllowOverride</a><br>
-</td></tr></table>
-
-<p>Apache \e$B$G$O%&%'%V%D%j!<$NCf$KCV$+$l$?FCJL$J%U%!%$%k$r;H$C$F\e(B
-\e$BHsCf1{=88"E*$J@_Dj4IM}$r$G$-$^$9!#$=$NFCJL$J%U%!%$%k$OIaDL$O\e(B
-<code>.htaccess</code> \e$B$H$$$&L>A0$G!"\e(B
-<a href="mod/core.html#accessfilename"><code
->AccessFileName</code></a> \e$B%G%#%l%/%F%#%V$G$I$s$JL>A0$G$b;XDj$G$-$^$9!#\e(B
-<code>.htaccess</code> \e$B%U%!%$%k$K=q$+$l$?%G%#%l%/%F%#%V$O%U%!%$%k$r\e(B
-\e$BCV$$$?%G%#%l%/%H%j$H$=$NA4$F$N%5%V%G%#%l%/%H%j$KE,MQ$5$l$^$9!#\e(B
-<code>.htaccess</code> \e$B%U%!%$%k$O$9$Y$F$N%j%/%(%9%H$G\e(B
-\e$BFI$_9~$^$l$k$?$a!"JQ99$O$9$0$KH?1G$5$l$^$9!#\e(B
-
-<p>\e$B$I$N%G%#%l%/%F%#%V$,\e(B <code>.htaccess</code> \e$B%U%!%$%k$K=q$1$k$+$r\e(B
-\e$BD4$Y$k$K$O!"%G%#%l%/%F%#%V$N\e(B
-<a href="mod/directive-dict.html#Context">\e$B%3%s%F%-%9%H\e(B</a> \e$B$rD4$Y$F$/$@$5$$!#\e(B
-
\e$B%5!<%P4IM}<T$O$5$i$K%a%$%s@_Dj%U%!%$%k$N
\e(B <a
-href="mod/core.html#allowoverride"><code>AllowOverride</code></a>
-\e$B$r@_Dj$9$k$3$H$G$I$N%G%#%l%/%F%#%V$r\e(B <code>.htaccess</code> \e$B%U%!%$%k$K\e(B
-\e$B=q$1$k$h$&$K$9$k$+$r@)8f$9$k$3$H$,$G$-$^$9!#\e(B</p>
-
-<hr>
-
-<h2><a name="logs">\e$B%m%0%U%!%$%k\e(B</a></h2>
-<!-- XXX: This section should be moved to its own file -->
-<h3>\e$B%;%-%e%j%F%#$K4X$9$k7Y9p\e(B</h3>
-<p>
-Apache \e$B$,%m%0%U%!%$%k$r=q$$$F$$$k%G%#%l%/%H%j$K=q$-9~$a$k?M$OC/$G$b\e(B
-\e$B$[$\3N<B$K%5!<%P$,5/F0$5$l$?\e(B uid \e$B$N%"%/%;%9$r<hF@$G$-$^$9!#\e(B
-\e$B$=$7$F$=$l$OIaDL\e(B root \e$B$G$9!#$=$N7k2L$r$h$/$o$+$i$:$K%m%0$,J]4I$5$l$F$$$k\e(B
-\e$B%G%#%l%/%H%j$K=q$-9~$_8"8B$rM?$($?$j\e(B<em>\e$B$7$J$$\e(B</em>\e$B$G$/$@$5$$!#>\:Y$O\e(B
-<a href="misc/security_tips.html">\e$B%;%-%e%j%F%#>pJs\e(B</a>\e$B$r;2>H$7$F$/$@$5$$!#\e(B</p>
-
-<h3>pid \e$B%U%!%$%k\e(B</h3>
-
-<p>\e$B5/F0;~$K\e(B Apache \e$B$O?F\e(B httpd \e$B%W%m%;%9$N%W%m%;%9\e(B ID \e$B$r\e(B
-<code>logs/httpd.pid</code> \e$B%U%!%$%k$KJ]B8$7$^$9!#$3$N%U%!%$%kL>$O\e(B
-<a href="mod/core.html#pidfile">PidFile</a>
-\e$B%G%#%l%/%F%#%V$GJQ99$9$k$3$H$,$G$-$^$9!#%W%m%;%9\e(B ID \e$B$O4IM}<T$,%G!<%b%s$r\e(B
-\e$B:F5/F0$7$?$j=*N;$7$?$j$9$k$?$a$K;H$$$^$9!#\e(BUnix \e$B$G$O\e(B HUP \e$B$H\e(B USR1 \e$B%7%0%J%k$G\e(B
-\e$B%G!<%b%s$,@_Dj%U%!%$%k$r:FFI$_9~$_$7$^$9!#\e(BTERM \e$B%7%0%J%k$O%G!<%b%s$r\e(B
-\e$BM%2m$K=*N;$5$;$^$9!#\e(BWindows \e$B$G$O!"Be$o$j$K%3%^%s%I%i%$%s%*%W%7%g%s\e(B -k \e$B$r\e(B
-\e$B;H$$$^$9!#\e(B
-
\e$B>\$7$$>pJs$O
\e(B<a href="stopping.html">
\e$B5/F0$H=*N;
\e(B</a>
\e$B$r;2>H$7$F$/$@$5$$!#
\e(B</p>
-
-<p>
-\e$B%W%m%;%9$,0[>o=*N;$9$k\e(B (\e$B$b$7$/$O\e(B kill \e$B$5$l$k\e(B) \e$B$H!";R\e(B httpd \e$B%W%m%;%9$r\e(B
-kill \e$B$9$kI,MW$,$"$j$^$9!#\e(B</p>
-
-<h3>\e$B%(%i!<%m%0\e(B</h3>
-
-<p>\e$B%5!<%P$O%(%i!<%a%C%;!<%8$r%m%0%U%!%$%k$K5-O?$7$^$9!#%G%U%)%k%H$O!"\e(BUnix
-\e$B$G$O\e(B <code>logs/error_log</code> \e$B$G\e(B Windows \e$B$H\e(B OS/2 \e$B$G$O\e(B
-<code>logs/error.log</code>
\e$B$G$9!#%U%!%$%kL>$O
\e(B <a
-href="mod/core.html#errorlog">ErrorLog</a> \e$B%G%#%l%/%F%#%V$G@_Dj$G$-$^$9!#\e(B
-href="mod/core.html#virtualhost">\e$B%P!<%A%c%k%[%9%H\e(B</a>
-\e$B$K0c$&%(%i!<%m%0$r@_Dj$9$k$3$H$,$G$-$^$9!#\e(B</p>
-
-<h3>\e$BE>Aw%m%0\e(B</h3>
-
-<p>\e$B%5!<%P$OIaDL$=$l$>$l$N%j%/%(%9%H$rE>Aw%U%!%$%k$K%m%0$r<h$j$^$9!#\e(B
-\e$B%G%U%)%k%H$O\e(B Unix \e$B$G$O\e(B <code>logs/access_log</code> \e$B$G\e(B Windows \e$B$H\e(B
-OS/2 \e$B$G$O\e(B <code>logs/access.log</code> \e$B$G$9!#%U%!%$%kL>$O\e(B
-<a href="mod/mod_log_config.html#customlog">CustomLog</a>
-
\e$B%G%#%l%/%F%#%V$r$G@_Dj$G$-$^$9!#0c$&
\e(B<a
-href="mod/core.html#virtualhost">\e$B%P!<%A%c%k%[%9%H\e(B</a>\e$B$K\e(B
-\e$B0c$&E>Aw%m%0$r@_Dj$9$k$3$H$,$G$-$^$9!#\e(B</p>
-
-
-<!--#include virtual="footer.html" -->
-</body>
+ <li><a href="#modules">$B%b%8%e!</a></li>
+ </ul>
+ </body>
</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Content Negotiation</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Content Negotiation</H1>
-
-<P>
-Apache's support for content negotiation has been updated to meet the
-HTTP/1.1 specification. It can choose the best representation of a
-resource based on the browser-supplied preferences for media type,
-languages, character set and encoding. It is also implements a
-couple of features to give more intelligent handling of requests from
-browsers which send incomplete negotiation information. <P>
-
-Content negotiation is provided by the
-<A HREF="mod/mod_negotiation.html">mod_negotiation</A> module,
-which is compiled in by default.
-
-<HR>
-
-<H2>About Content Negotiation</H2>
-
-<P>
-A resource may be available in several different representations. For
-example, it might be available in different languages or different
-media types, or a combination. One way of selecting the most
-appropriate choice is to give the user an index page, and let them
-select. However it is often possible for the server to choose
-automatically. This works because browsers can send as part of each
-request information about what representations they prefer. For
-example, a browser could indicate that it would like to see
-information in French, if possible, else English will do. Browsers
-indicate their preferences by headers in the request. To request only
-French representations, the browser would send
-
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache Content Negotiation</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Content Negotiation</h1>
+
+ <p>Apache's support for content negotiation has been updated to
+ meet the HTTP/1.1 specification. It can choose the best
+ representation of a resource based on the browser-supplied
+ preferences for media type, languages, character set and
+ encoding. It is also implements a couple of features to give
+ more intelligent handling of requests from browsers which send
+ incomplete negotiation information.</p>
+
+ <p>Content negotiation is provided by the <a
+ href="mod/mod_negotiation.html">mod_negotiation</a> module,
+ which is compiled in by default.</p>
+ <hr />
+
+ <h2>About Content Negotiation</h2>
+
+ <p>A resource may be available in several different
+ representations. For example, it might be available in
+ different languages or different media types, or a combination.
+ One way of selecting the most appropriate choice is to give the
+ user an index page, and let them select. However it is often
+ possible for the server to choose automatically. This works
+ because browsers can send as part of each request information
+ about what representations they prefer. For example, a browser
+ could indicate that it would like to see information in French,
+ if possible, else English will do. Browsers indicate their
+ preferences by headers in the request. To request only French
+ representations, the browser would send</p>
+<pre>
Accept-Language: fr
-</PRE>
-
-<P>
-Note that this preference will only be applied when there is a choice
-of representations and they vary by language.
-<P>
-
-As an example of a more complex request, this browser has been
-configured to accept French and English, but prefer French, and to
-accept various media types, preferring HTML over plain text or other
-text types, and preferring GIF or JPEG over other media types, but also
-allowing any other media type as a last resort:
-
-<PRE>
+</pre>
+
+ <p>Note that this preference will only be applied when there is
+ a choice of representations and they vary by language.</p>
+
+ <p>As an example of a more complex request, this browser has
+ been configured to accept French and English, but prefer
+ French, and to accept various media types, preferring HTML over
+ plain text or other text types, and preferring GIF or JPEG over
+ other media types, but also allowing any other media type as a
+ last resort:</p>
+<pre>
Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6,
image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
-</PRE>
-
-Apache 1.2 supports 'server driven' content negotiation, as defined in
-the HTTP/1.1 specification. It fully supports the Accept,
-Accept-Language, Accept-Charset and Accept-Encoding request headers.
-Apache 1.3.4 also supports 'transparent' content negotiation, which is
-an experimental negotiation protocol defined in RFC 2295 and RFC 2296.
-It does not offer support for 'feature negotiation' as defined in
-these RFCs.
-<P>
-
-A <STRONG>resource</STRONG> is a conceptual entity identified by a URI
-(RFC 2396). An HTTP server like Apache provides access to
-<STRONG>representations</STRONG> of the resource(s) within its namespace,
-with each representation in the form of a sequence of bytes with a
-defined media type, character set, encoding, etc. Each resource may be
-associated with zero, one, or more than one representation
-at any given time. If multiple representations are available,
-the resource is referred to as <STRONG>negotiable</STRONG> and each of its
-representations is termed a <STRONG>variant</STRONG>. The ways in which the
-variants for a negotiable resource vary are called the
-<STRONG>dimensions</STRONG> of negotiation.
-
-<H2>Negotiation in Apache</H2>
-
-<P>
-In order to negotiate a resource, the server needs to be given
-information about each of the variants. This is done in one of two
-ways:
-
-<UL>
- <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which
- names the files containing the variants explicitly, or
- <LI> Using a 'MultiViews' search, where the server does an implicit
- filename pattern match and chooses from among the results.
-</UL>
-
-<H3>Using a type-map file</H3>
-
-<P>
-A type map is a document which is associated with the handler
-named <CODE>type-map</CODE> (or, for backwards-compatibility with
-older Apache configurations, the mime type
-<CODE>application/x-type-map</CODE>). Note that to use this feature,
-you must have a handler set in the configuration that defines a
-file suffix as <CODE>type-map</CODE>; this is best done with a
-
-<PRE>
+</pre>
+ Apache 1.2 supports 'server driven' content negotiation, as
+ defined in the HTTP/1.1 specification. It fully supports the
+ Accept, Accept-Language, Accept-Charset and Accept-Encoding
+ request headers. Apache 1.3.4 also supports 'transparent'
+ content negotiation, which is an experimental negotiation
+ protocol defined in RFC 2295 and RFC 2296. It does not offer
+ support for 'feature negotiation' as defined in these RFCs.
+
+ <p>A <strong>resource</strong> is a conceptual entity
+ identified by a URI (RFC 2396). An HTTP server like Apache
+ provides access to <strong>representations</strong> of the
+ resource(s) within its namespace, with each representation in
+ the form of a sequence of bytes with a defined media type,
+ character set, encoding, etc. Each resource may be associated
+ with zero, one, or more than one representation at any given
+ time. If multiple representations are available, the resource
+ is referred to as <strong>negotiable</strong> and each of its
+ representations is termed a <strong>variant</strong>. The ways
+ in which the variants for a negotiable resource vary are called
+ the <strong>dimensions</strong> of negotiation.</p>
+
+ <h2>Negotiation in Apache</h2>
+
+ <p>In order to negotiate a resource, the server needs to be
+ given information about each of the variants. This is done in
+ one of two ways:</p>
+
+ <ul>
+ <li>Using a type map (<em>i.e.</em>, a <code>*.var</code>
+ file) which names the files containing the variants
+ explicitly, or</li>
+
+ <li>Using a 'MultiViews' search, where the server does an
+ implicit filename pattern match and chooses from among the
+ results.</li>
+ </ul>
+
+ <h3>Using a type-map file</h3>
+
+ <p>A type map is a document which is associated with the
+ handler named <code>type-map</code> (or, for
+ backwards-compatibility with older Apache configurations, the
+ mime type <code>application/x-type-map</code>). Note that to
+ use this feature, you must have a handler set in the
+ configuration that defines a file suffix as
+ <code>type-map</code>; this is best done with a</p>
+<pre>
AddHandler type-map .var
-</PRE>
-
-in the server configuration file.<p>
-
-Type map files should have the same name as the resource which they are
-describing, and have an entry for each available variant; these entries
-consist of contiguous HTTP-format header lines. Entries for
-different variants are separated by blank lines. Blank lines are
-illegal within an entry. It is conventional to begin a map file with
-an entry for the combined entity as a whole (although this
-is not required, and if present will be ignored). An example
-map file is shown below. This file would be named <code>foo.html</code>,
-as it describes a resource named <code>foo</code>.
-
-<PRE>
+</pre>
+ in the server configuration file.
+
+ <p>Type map files should have the same name as the resource
+ which they are describing, and have an entry for each available
+ variant; these entries consist of contiguous HTTP-format header
+ lines. Entries for different variants are separated by blank
+ lines. Blank lines are illegal within an entry. It is
+ conventional to begin a map file with an entry for the combined
+ entity as a whole (although this is not required, and if
+ present will be ignored). An example map file is shown below.
+ This file would be named <code>foo.html</code>, as it describes
+ a resource named <code>foo</code>.</p>
+<pre>
URI: foo
URI: foo.en.html
URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de
-</PRE>
-
-Note also that a typemap file will take precedence over the filename's
-extension, even when Multiviews is on.
-
-If the variants have different source qualities, that may be indicated
-by the "qs" parameter to the media type, as in this picture (available
-as jpeg, gif, or ASCII-art):
-
-<PRE>
+</pre>
+ Note also that a typemap file will take precedence over the
+ filename's extension, even when Multiviews is on. If the
+ variants have different source qualities, that may be indicated
+ by the "qs" parameter to the media type, as in this picture
+ (available as jpeg, gif, or ASCII-art):
+<pre>
URI: foo
URI: foo.jpeg
URI: foo.txt
Content-type: text/plain; qs=0.01
-</PRE>
-<P>
-
-qs values can vary in the range 0.000 to 1.000. Note that any variant with
-a qs value of 0.000 will never be chosen. Variants with no 'qs'
-parameter value are given a qs factor of 1.0. The qs parameter indicates
-the relative 'quality' of this variant compared to the other available
-variants, independent of the client's capabilities. For example, a jpeg
-file is usually of higher source quality than an ascii file if it is
-attempting to represent a photograph. However, if the resource being
-represented is an original ascii art, then an ascii representation would
-have a higher source quality than a jpeg representation. A qs value
-is therefore specific to a given variant depending on the nature of
-the resource it represents.
-
-<P>
-The full list of headers recognized is:
-
-<DL>
- <DT> <CODE>URI:</CODE>
- <DD> uri of the file containing the variant (of the given media
- type, encoded with the given content encoding). These are
- interpreted as URLs relative to the map file; they must be on
- the same server (!), and they must refer to files to which the
- client would be granted access if they were to be requested
- directly.
- <DT> <CODE>Content-Type:</CODE>
- <DD> media type --- charset, level and "qs" parameters may be given. These
- are often referred to as MIME types; typical media types are
- <CODE>image/gif</CODE>, <CODE>text/plain</CODE>, or
- <CODE>text/html; level=3</CODE>.
- <DT> <CODE>Content-Language:</CODE>
- <DD> The languages of the variant, specified as an Internet standard
- language tag from RFC 1766 (<EM>e.g.</EM>, <CODE>en</CODE> for English,
- <CODE>kr</CODE> for Korean, <EM>etc.</EM>).
- <DT> <CODE>Content-Encoding:</CODE>
- <DD> If the file is compressed, or otherwise encoded, rather than
- containing the actual raw data, this says how that was done.
- Apache only recognizes encodings that are defined by an
- <A HREF="mod/mod_mime.html#addencoding">AddEncoding</A> directive.
- This normally includes the encodings <CODE>x-compress</CODE>
- for compress'd files, and <CODE>x-gzip</CODE> for gzip'd files.
- The <CODE>x-</CODE> prefix is ignored for encoding comparisons.
- <DT> <CODE>Content-Length:</CODE>
- <DD> The size of the file in bytes. Specifying content
- lengths in the type-map allows the server to compare file sizes
- without checking the actual files.
- <DT> <CODE>Description:</CODE>
- <DD> A human-readable textual description of the variant. If Apache cannot
- find any appropriate variant to return, it will return an error
- response which lists all available variants instead. Such a variant
- list will include the human-readable variant descriptions.
-</DL>
-
-Using a type map file is preferred over <code>MultiViews</code> because
-it requires less CPU time, and less file access, to parse a file
-explicitly listing the various resource variants, than to have to look
-at every matching file, and parse its file extensions.
-
-<H3>Multiviews</H3>
-
-<P>
-<CODE>MultiViews</CODE> is a per-directory option, meaning it can be set with
-an <CODE>Options</CODE> directive within a <CODE><Directory></CODE>,
-<CODE><Location></CODE> or <CODE><Files></CODE>
-section in <CODE>access.conf</CODE>, or (if <CODE>AllowOverride</CODE>
-is properly set) in <CODE>.htaccess</CODE> files. Note that
-<CODE>Options All</CODE> does not set <CODE>MultiViews</CODE>; you
-have to ask for it by name.
-
-<P>
-The effect of <CODE>MultiViews</CODE> is as follows: if the server
-receives a request for <CODE>/some/dir/foo</CODE>, if
-<CODE>/some/dir</CODE> has <CODE>MultiViews</CODE> enabled, and
-<CODE>/some/dir/foo</CODE> does <EM>not</EM> exist, then the server reads the
-directory looking for files named foo.*, and effectively fakes up a
-type map which names all those files, assigning them the same media
-types and content-encodings it would have if the client had asked for
-one of them by name. It then chooses the best match to the client's
-requirements.
-
-<P>
-<CODE>MultiViews</CODE> may also apply to searches for the file named by the
-<CODE>DirectoryIndex</CODE> directive, if the server is trying to
-index a directory. If the configuration files specify
-
-<PRE>
+</pre>
+
+ <p>qs values can vary in the range 0.000 to 1.000. Note that
+ any variant with a qs value of 0.000 will never be chosen.
+ Variants with no 'qs' parameter value are given a qs factor of
+ 1.0. The qs parameter indicates the relative 'quality' of this
+ variant compared to the other available variants, independent
+ of the client's capabilities. For example, a jpeg file is
+ usually of higher source quality than an ascii file if it is
+ attempting to represent a photograph. However, if the resource
+ being represented is an original ascii art, then an ascii
+ representation would have a higher source quality than a jpeg
+ representation. A qs value is therefore specific to a given
+ variant depending on the nature of the resource it
+ represents.</p>
+
+ <p>The full list of headers recognized is:</p>
+
+ <dl>
+ <dt><code>URI:</code></dt>
+
+ <dd>uri of the file containing the variant (of the given
+ media type, encoded with the given content encoding). These
+ are interpreted as URLs relative to the map file; they must
+ be on the same server (!), and they must refer to files to
+ which the client would be granted access if they were to be
+ requested directly.</dd>
+
+ <dt><code>Content-Type:</code></dt>
+
+ <dd>media type --- charset, level and "qs" parameters may be
+ given. These are often referred to as MIME types; typical
+ media types are <code>image/gif</code>,
+ <code>text/plain</code>, or
+ <code>text/html; level=3</code>.</dd>
+
+ <dt><code>Content-Language:</code></dt>
+
+ <dd>The languages of the variant, specified as an Internet
+ standard language tag from RFC 1766 (<em>e.g.</em>,
+ <code>en</code> for English, <code>kr</code> for Korean,
+ <em>etc.</em>).</dd>
+
+ <dt><code>Content-Encoding:</code></dt>
+
+ <dd>If the file is compressed, or otherwise encoded, rather
+ than containing the actual raw data, this says how that was
+ done. Apache only recognizes encodings that are defined by an
+ <a href="mod/mod_mime.html#addencoding">AddEncoding</a>
+ directive. This normally includes the encodings
+ <code>x-compress</code> for compress'd files, and
+ <code>x-gzip</code> for gzip'd files. The <code>x-</code>
+ prefix is ignored for encoding comparisons.</dd>
+
+ <dt><code>Content-Length:</code></dt>
+
+ <dd>The size of the file in bytes. Specifying content lengths
+ in the type-map allows the server to compare file sizes
+ without checking the actual files.</dd>
+
+ <dt><code>Description:</code></dt>
+
+ <dd>A human-readable textual description of the variant. If
+ Apache cannot find any appropriate variant to return, it will
+ return an error response which lists all available variants
+ instead. Such a variant list will include the human-readable
+ variant descriptions.</dd>
+ </dl>
+ Using a type map file is preferred over <code>MultiViews</code>
+ because it requires less CPU time, and less file access, to
+ parse a file explicitly listing the various resource variants,
+ than to have to look at every matching file, and parse its file
+ extensions.
+
+ <h3>Multiviews</h3>
+
+ <p><code>MultiViews</code> is a per-directory option, meaning
+ it can be set with an <code>Options</code> directive within a
+ <code><Directory></code>, <code><Location></code>
+ or <code><Files></code> section in
+ <code>access.conf</code>, or (if <code>AllowOverride</code> is
+ properly set) in <code>.htaccess</code> files. Note that
+ <code>Options All</code> does not set <code>MultiViews</code>;
+ you have to ask for it by name.</p>
+
+ <p>The effect of <code>MultiViews</code> is as follows: if the
+ server receives a request for <code>/some/dir/foo</code>, if
+ <code>/some/dir</code> has <code>MultiViews</code> enabled, and
+ <code>/some/dir/foo</code> does <em>not</em> exist, then the
+ server reads the directory looking for files named foo.*, and
+ effectively fakes up a type map which names all those files,
+ assigning them the same media types and content-encodings it
+ would have if the client had asked for one of them by name. It
+ then chooses the best match to the client's requirements.</p>
+
+ <p><code>MultiViews</code> may also apply to searches for the
+ file named by the <code>DirectoryIndex</code> directive, if the
+ server is trying to index a directory. If the configuration
+ files specify</p>
+<pre>
DirectoryIndex index
-</PRE>
-
-then the server will arbitrate between <CODE>index.html</CODE>
-and <CODE>index.html3</CODE> if both are present. If neither are
-present, and <CODE>index.cgi</CODE> is there, the server will run it.
-
-<P>
-If one of the files found when reading the directive is a CGI script,
-it's not obvious what should happen. The code gives that case
-special treatment --- if the request was a POST, or a GET with
-QUERY_ARGS or PATH_INFO, the script is given an extremely high quality
-rating, and generally invoked; otherwise it is given an extremely low
-quality rating, which generally causes one of the other views (if any)
-to be retrieved.
-
-<H2>The Negotiation Methods</H2>
-
-After Apache has obtained a list of the variants for a given resource,
-either from a type-map file or from the filenames in the directory, it
-invokes one of two methods to decide on the 'best' variant to
-return, if any. It is not necessary to know any of the details of how
-negotiation actually takes place in order to use Apache's content
-negotiation features. However the rest of this document explains the
-methods used for those interested.
-<P>
-
-There are two negotiation methods:
-
-<OL>
-
-<LI><STRONG>Server driven negotiation with the Apache
-algorithm</STRONG> is used in the normal case. The Apache algorithm is
-explained in more detail below. When this algorithm is used, Apache
-can sometimes 'fiddle' the quality factor of a particular dimension to
-achieve a better result. The ways Apache can fiddle quality factors is
-explained in more detail below.
-
-<LI><STRONG>Transparent content negotiation</STRONG> is used when the
-browser specifically requests this through the mechanism defined in RFC
-2295. This negotiation method gives the browser full control over
-deciding on the 'best' variant, the result is therefore dependent on
-the specific algorithms used by the browser. As part of the
-transparent negotiation process, the browser can ask Apache to run the
-'remote variant selection algorithm' defined in RFC 2296.
-
-</OL>
-
-
-<H3>Dimensions of Negotiation</H3>
-
-<TABLE>
-<TR valign="top">
-<TH>Dimension
-<TH>Notes
-<TR valign="top">
-<TD>Media Type
-<TD>Browser indicates preferences with the Accept header field. Each item
-can have an associated quality factor. Variant description can also
-have a quality factor (the "qs" parameter).
-<TR valign="top">
-<TD>Language
-<TD>Browser indicates preferences with the Accept-Language header field.
-Each item can have a quality factor. Variants can be associated with none, one
-or more than one language.
-<TR valign="top">
-<TD>Encoding
-<TD>Browser indicates preference with the Accept-Encoding header field.
-Each item can have a quality factor.
-<TR valign="top">
-<TD>Charset
-<TD>Browser indicates preference with the Accept-Charset header field.
-Each item can have a quality factor.
-Variants can indicate a charset as a parameter of the media type.
-</TABLE>
-
-<H3>Apache Negotiation Algorithm</H3>
-
-<P>
-Apache can use the following algorithm to select the 'best' variant
-(if any) to return to the browser. This algorithm is not
-further configurable. It operates as follows:
-
-<OL>
-<LI>First, for each dimension of the negotiation, check the appropriate
-<EM>Accept*</EM> header field and assign a quality to each
-variant. If the <EM>Accept*</EM> header for any dimension implies that this
-variant is not acceptable, eliminate it. If no variants remain, go
-to step 4.
-
-<LI>Select the 'best' variant by a process of elimination. Each of the
-following tests is applied in order. Any variants not selected at each
-test are eliminated. After each test, if only one variant remains,
-select it as the best match and proceed to step 3. If more than one
-variant remains, move on to the next test.
-
-<OL>
-<LI>Multiply the quality factor from the Accept header with the
- quality-of-source factor for this variant's media type, and select
- the variants with the highest value.
-
-<LI>Select the variants with the highest language quality factor.
-
-<LI>Select the variants with the best language match, using either the
- order of languages in the Accept-Language header (if present), or else
- the order of languages in the <CODE>LanguagePriority</CODE>
- directive (if present).
-
-<LI>Select the variants with the highest 'level' media parameter
- (used to give the version of text/html media types).
-
-<LI>Select variants with the best charset media parameters,
- as given on the Accept-Charset header line. Charset ISO-8859-1
- is acceptable unless explicitly excluded. Variants with a
- <CODE>text/*</CODE> media type but not explicitly associated
- with a particular charset are assumed to be in ISO-8859-1.
-
-<LI>Select those variants which have associated
- charset media parameters that are <EM>not</EM> ISO-8859-1.
- If there are no such variants, select all variants instead.
-
-<LI>Select the variants with the best encoding. If there are
- variants with an encoding that is acceptable to the user-agent,
- select only these variants. Otherwise if there is a mix of encoded
- and non-encoded variants, select only the unencoded variants.
- If either all variants are encoded or all variants are not encoded,
- select all variants.
-
-<LI>Select the variants with the smallest content length.
-
-<LI>Select the first variant of those remaining. This will be either the
- first listed in the type-map file, or when variants are read from
- the directory, the one whose file name comes first when sorted using
- ASCII code order.
-
-</OL>
-
-<LI>The algorithm has now selected one 'best' variant, so return
- it as the response. The HTTP response header Vary is set to indicate the
- dimensions of negotiation (browsers and caches can use this
- information when caching the resource). End.
-
-<LI>To get here means no variant was selected (because none are acceptable
- to the browser). Return a 406 status (meaning "No acceptable representation")
- with a response body consisting of an HTML document listing the
- available variants. Also set the HTTP Vary header to indicate the
- dimensions of variance.
-
-</OL>
-
-<H2><A NAME="better">Fiddling with Quality Values</A></H2>
-
-<P>
-Apache sometimes changes the quality values from what would be
-expected by a strict interpretation of the Apache negotiation
-algorithm above. This is to get a better result from the algorithm for
-browsers which do not send full or accurate information. Some of the
-most popular browsers send Accept header information which would
-otherwise result in the selection of the wrong variant in many
-cases. If a browser sends full and correct information these fiddles
-will not be applied.
-<P>
-
-<H3>Media Types and Wildcards</H3>
-
-<P>
-The Accept: request header indicates preferences for media types. It
-can also include 'wildcard' media types, such as "image/*" or "*/*"
-where the * matches any string. So a request including:
-<PRE>
+</pre>
+ then the server will arbitrate between <code>index.html</code>
+ and <code>index.html3</code> if both are present. If neither
+ are present, and <code>index.cgi</code> is there, the server
+ will run it.
+
+ <p>If one of the files found when reading the directive is a
+ CGI script, it's not obvious what should happen. The code gives
+ that case special treatment --- if the request was a POST, or a
+ GET with QUERY_ARGS or PATH_INFO, the script is given an
+ extremely high quality rating, and generally invoked; otherwise
+ it is given an extremely low quality rating, which generally
+ causes one of the other views (if any) to be retrieved.</p>
+
+ <h2>The Negotiation Methods</h2>
+ After Apache has obtained a list of the variants for a given
+ resource, either from a type-map file or from the filenames in
+ the directory, it invokes one of two methods to decide on the
+ 'best' variant to return, if any. It is not necessary to know
+ any of the details of how negotiation actually takes place in
+ order to use Apache's content negotiation features. However the
+ rest of this document explains the methods used for those
+ interested.
+
+ <p>There are two negotiation methods:</p>
+
+ <ol>
+ <li><strong>Server driven negotiation with the Apache
+ algorithm</strong> is used in the normal case. The Apache
+ algorithm is explained in more detail below. When this
+ algorithm is used, Apache can sometimes 'fiddle' the quality
+ factor of a particular dimension to achieve a better result.
+ The ways Apache can fiddle quality factors is explained in
+ more detail below.</li>
+
+ <li><strong>Transparent content negotiation</strong> is used
+ when the browser specifically requests this through the
+ mechanism defined in RFC 2295. This negotiation method gives
+ the browser full control over deciding on the 'best' variant,
+ the result is therefore dependent on the specific algorithms
+ used by the browser. As part of the transparent negotiation
+ process, the browser can ask Apache to run the 'remote
+ variant selection algorithm' defined in RFC 2296.</li>
+ </ol>
+
+ <h3>Dimensions of Negotiation</h3>
+
+ <table>
+ <tr valign="top">
+ <th>Dimension</th>
+
+ <th>Notes</th>
+ </tr>
+
+ <tr valign="top">
+ <td>Media Type</td>
+
+ <td>Browser indicates preferences with the Accept header
+ field. Each item can have an associated quality factor.
+ Variant description can also have a quality factor (the
+ "qs" parameter).</td>
+ </tr>
+
+ <tr valign="top">
+ <td>Language</td>
+
+ <td>Browser indicates preferences with the Accept-Language
+ header field. Each item can have a quality factor. Variants
+ can be associated with none, one or more than one
+ language.</td>
+ </tr>
+
+ <tr valign="top">
+ <td>Encoding</td>
+
+ <td>Browser indicates preference with the Accept-Encoding
+ header field. Each item can have a quality factor.</td>
+ </tr>
+
+ <tr valign="top">
+ <td>Charset</td>
+
+ <td>Browser indicates preference with the Accept-Charset
+ header field. Each item can have a quality factor. Variants
+ can indicate a charset as a parameter of the media
+ type.</td>
+ </tr>
+ </table>
+
+ <h3>Apache Negotiation Algorithm</h3>
+
+ <p>Apache can use the following algorithm to select the 'best'
+ variant (if any) to return to the browser. This algorithm is
+ not further configurable. It operates as follows:</p>
+
+ <ol>
+ <li>First, for each dimension of the negotiation, check the
+ appropriate <em>Accept*</em> header field and assign a
+ quality to each variant. If the <em>Accept*</em> header for
+ any dimension implies that this variant is not acceptable,
+ eliminate it. If no variants remain, go to step 4.</li>
+
+ <li>
+ Select the 'best' variant by a process of elimination. Each
+ of the following tests is applied in order. Any variants
+ not selected at each test are eliminated. After each test,
+ if only one variant remains, select it as the best match
+ and proceed to step 3. If more than one variant remains,
+ move on to the next test.
+
+ <ol>
+ <li>Multiply the quality factor from the Accept header
+ with the quality-of-source factor for this variant's
+ media type, and select the variants with the highest
+ value.</li>
+
+ <li>Select the variants with the highest language quality
+ factor.</li>
+
+ <li>Select the variants with the best language match,
+ using either the order of languages in the
+ Accept-Language header (if present), or else the order of
+ languages in the <code>LanguagePriority</code> directive
+ (if present).</li>
+
+ <li>Select the variants with the highest 'level' media
+ parameter (used to give the version of text/html media
+ types).</li>
+
+ <li>Select variants with the best charset media
+ parameters, as given on the Accept-Charset header line.
+ Charset ISO-8859-1 is acceptable unless explicitly
+ excluded. Variants with a <code>text/*</code> media type
+ but not explicitly associated with a particular charset
+ are assumed to be in ISO-8859-1.</li>
+
+ <li>Select those variants which have associated charset
+ media parameters that are <em>not</em> ISO-8859-1. If
+ there are no such variants, select all variants
+ instead.</li>
+
+ <li>Select the variants with the best encoding. If there
+ are variants with an encoding that is acceptable to the
+ user-agent, select only these variants. Otherwise if
+ there is a mix of encoded and non-encoded variants,
+ select only the unencoded variants. If either all
+ variants are encoded or all variants are not encoded,
+ select all variants.</li>
+
+ <li>Select the variants with the smallest content
+ length.</li>
+
+ <li>Select the first variant of those remaining. This
+ will be either the first listed in the type-map file, or
+ when variants are read from the directory, the one whose
+ file name comes first when sorted using ASCII code
+ order.</li>
+ </ol>
+ </li>
+
+ <li>The algorithm has now selected one 'best' variant, so
+ return it as the response. The HTTP response header Vary is
+ set to indicate the dimensions of negotiation (browsers and
+ caches can use this information when caching the resource).
+ End.</li>
+
+ <li>To get here means no variant was selected (because none
+ are acceptable to the browser). Return a 406 status (meaning
+ "No acceptable representation") with a response body
+ consisting of an HTML document listing the available
+ variants. Also set the HTTP Vary header to indicate the
+ dimensions of variance.</li>
+ </ol>
+
+ <h2><a id="better" name="better">Fiddling with Quality
+ Values</a></h2>
+
+ <p>Apache sometimes changes the quality values from what would
+ be expected by a strict interpretation of the Apache
+ negotiation algorithm above. This is to get a better result
+ from the algorithm for browsers which do not send full or
+ accurate information. Some of the most popular browsers send
+ Accept header information which would otherwise result in the
+ selection of the wrong variant in many cases. If a browser
+ sends full and correct information these fiddles will not be
+ applied.</p>
+
+ <h3>Media Types and Wildcards</h3>
+
+ <p>The Accept: request header indicates preferences for media
+ types. It can also include 'wildcard' media types, such as
+ "image/*" or "*/*" where the * matches any string. So a request
+ including:</p>
+<pre>
Accept: image/*, */*
-</PRE>
-
-would indicate that any type starting "image/" is acceptable,
-as is any other type (so the first "image/*" is redundant). Some
-browsers routinely send wildcards in addition to explicit types they
-can handle. For example:
-<PRE>
+</pre>
+ would indicate that any type starting "image/" is acceptable,
+ as is any other type (so the first "image/*" is redundant).
+ Some browsers routinely send wildcards in addition to explicit
+ types they can handle. For example:
+<pre>
Accept: text/html, text/plain, image/gif, image/jpeg, */*
-</PRE>
-
-The intention of this is to indicate that the explicitly
-listed types are preferred, but if a different representation is
-available, that is ok too. However under the basic algorithm, as given
-above, the */* wildcard has exactly equal preference to all the other
-types, so they are not being preferred. The browser should really have
-sent a request with a lower quality (preference) value for *.*, such
-as:
-<PRE>
+</pre>
+ The intention of this is to indicate that the explicitly listed
+ types are preferred, but if a different representation is
+ available, that is ok too. However under the basic algorithm,
+ as given above, the */* wildcard has exactly equal preference
+ to all the other types, so they are not being preferred. The
+ browser should really have sent a request with a lower quality
+ (preference) value for *.*, such as:
+<pre>
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-</PRE>
-
-The explicit types have no quality factor, so they default to a
-preference of 1.0 (the highest). The wildcard */* is given
-a low preference of 0.01, so other types will only be returned if
-no variant matches an explicitly listed type.
-<P>
-
-If the Accept: header contains <EM>no</EM> q factors at all, Apache sets
-the q value of "*/*", if present, to 0.01 to emulate the desired
-behavior. It also sets the q value of wildcards of the format
-"type/*" to 0.02 (so these are preferred over matches against
-"*/*". If any media type on the Accept: header contains a q factor,
-these special values are <EM>not</EM> applied, so requests from browsers
-which send the correct information to start with work as expected.
-
-<H3>Variants with no Language</H3>
-
-<P>
-If some of the variants for a particular resource have a language
-attribute, and some do not, those variants with no language
-are given a very low language quality factor of 0.001.<P>
-
-The reason for setting this language quality factor for
-variant with no language to a very low value is to allow
-for a default variant which can be supplied if none of the
-other variants match the browser's language preferences.
-
-For example, consider the situation with three variants:
-
-<UL>
-<LI>foo.en.html, language en
-<LI>foo.fr.html, language en
-<LI>foo.html, no language
-</UL>
-
-<P>
-The meaning of a variant with no language is that it is
-always acceptable to the browser. If the request Accept-Language
-header includes either en or fr (or both) one of foo.en.html
-or foo.fr.html will be returned. If the browser does not list
-either en or fr as acceptable, foo.html will be returned instead.
-
-<H2>Extensions to Transparent Content Negotiation</H2>
-
-Apache extends the transparent content negotiation protocol (RFC 2295)
-as follows. A new <CODE> {encoding ..}</CODE> element is used in
-variant lists to label variants which are available with a specific
-content-encoding only. The implementation of the
-RVSA/1.0 algorithm (RFC 2296) is extended to recognize encoded
-variants in the list, and to use them as candidate variants whenever
-their encodings are acceptable according to the Accept-Encoding
-request header. The RVSA/1.0 implementation does not round computed
-quality factors to 5 decimal places before choosing the best variant.
-
-<H2>Note on hyperlinks and naming conventions</H2>
-
-<P>
-If you are using language negotiation you can choose between
-different naming conventions, because files can have more than one
-extension, and the order of the extensions is normally irrelevant
-(see the <A HREF="mod/mod_mime.html#multipleext">mod_mime</A>
-documentation for details).
-<P>
-A typical file has a MIME-type extension (<EM>e.g.</EM>, <SAMP>html</SAMP>),
-maybe an encoding extension (<EM>e.g.</EM>, <SAMP>gz</SAMP>), and of course a
-language extension (<EM>e.g.</EM>, <SAMP>en</SAMP>) when we have different
-language variants of this file.
-
-<P>
-Examples:
-<UL>
-<LI>foo.en.html
-<LI>foo.html.en
-<LI>foo.en.html.gz
-</UL>
-
-<P>
-Here some more examples of filenames together with valid and invalid
-hyperlinks:
-</P>
-
-<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0>
-<TR>
- <TH>Filename</TH>
- <TH>Valid hyperlink</TH>
- <TH>Invalid hyperlink</TH>
-</TR>
-<TR>
- <TD><EM>foo.html.en</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>-</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html</EM></TD>
- <TD>foo</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.en.gz</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>foo.gz<BR>
- foo.html.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html.gz</EM></TD>
- <TD>foo</TD>
- <TD>foo.html<BR>
- foo.html.gz<BR>
- foo.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.gz.html.en</EM></TD>
- <TD>foo<BR>
- foo.gz<BR>
- foo.gz.html</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.gz.en</EM></TD>
- <TD>foo<BR>
- foo.html<BR>
- foo.html.gz</TD>
- <TD>foo.gz</TD>
-</TR>
-</TABLE>
-
-<P>
-Looking at the table above you will notice that it is always possible to
-use the name without any extensions in an hyperlink (<EM>e.g.</EM>, <SAMP>foo</SAMP>).
-The advantage is that you can hide the actual type of a
-document rsp. file and can change it later, <EM>e.g.</EM>, from <SAMP>html</SAMP>
-to <SAMP>shtml</SAMP> or <SAMP>cgi</SAMP> without changing any
-hyperlink references.
-
-<P>
-If you want to continue to use a MIME-type in your hyperlinks (<EM>e.g.</EM>
-<SAMP>foo.html</SAMP>) the language extension (including an encoding extension
-if there is one) must be on the right hand side of the MIME-type extension
-(<EM>e.g.</EM>, <SAMP>foo.html.en</SAMP>).
-
-
-<H2>Note on Caching</H2>
-
-<P>
-When a cache stores a representation, it associates it with the request URL.
-The next time that URL is requested, the cache can use the stored
-representation. But, if the resource is negotiable at the server,
-this might result in only the first requested variant being cached and
-subsequent cache hits might return the wrong response. To prevent this,
-Apache normally marks all responses that are returned after content negotiation
-as non-cacheable by HTTP/1.0 clients. Apache also supports the HTTP/1.1
-protocol features to allow caching of negotiated responses. <P>
-
-For requests which come from a HTTP/1.0 compliant client (either a
-browser or a cache), the directive <TT>CacheNegotiatedDocs</TT> can be
-used to allow caching of responses which were subject to negotiation.
-This directive can be given in the server config or virtual host, and
-takes no arguments. It has no effect on requests from HTTP/1.1 clients.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ The explicit types have no quality factor, so they default to a
+ preference of 1.0 (the highest). The wildcard */* is given a
+ low preference of 0.01, so other types will only be returned if
+ no variant matches an explicitly listed type.
+
+ <p>If the Accept: header contains <em>no</em> q factors at all,
+ Apache sets the q value of "*/*", if present, to 0.01 to
+ emulate the desired behavior. It also sets the q value of
+ wildcards of the format "type/*" to 0.02 (so these are
+ preferred over matches against "*/*". If any media type on the
+ Accept: header contains a q factor, these special values are
+ <em>not</em> applied, so requests from browsers which send the
+ correct information to start with work as expected.</p>
+
+ <h3>Variants with no Language</h3>
+
+ <p>If some of the variants for a particular resource have a
+ language attribute, and some do not, those variants with no
+ language are given a very low language quality factor of
+ 0.001.</p>
+
+ <p>The reason for setting this language quality factor for
+ variant with no language to a very low value is to allow for a
+ default variant which can be supplied if none of the other
+ variants match the browser's language preferences. For example,
+ consider the situation with three variants:</p>
+
+ <ul>
+ <li>foo.en.html, language en</li>
+
+ <li>foo.fr.html, language en</li>
+
+ <li>foo.html, no language</li>
+ </ul>
+
+ <p>The meaning of a variant with no language is that it is
+ always acceptable to the browser. If the request
+ Accept-Language header includes either en or fr (or both) one
+ of foo.en.html or foo.fr.html will be returned. If the browser
+ does not list either en or fr as acceptable, foo.html will be
+ returned instead.</p>
+
+ <h2>Extensions to Transparent Content Negotiation</h2>
+ Apache extends the transparent content negotiation protocol
+ (RFC 2295) as follows. A new <code>{encoding ..}</code> element
+ is used in variant lists to label variants which are available
+ with a specific content-encoding only. The implementation of
+ the RVSA/1.0 algorithm (RFC 2296) is extended to recognize
+ encoded variants in the list, and to use them as candidate
+ variants whenever their encodings are acceptable according to
+ the Accept-Encoding request header. The RVSA/1.0 implementation
+ does not round computed quality factors to 5 decimal places
+ before choosing the best variant.
+
+ <h2>Note on hyperlinks and naming conventions</h2>
+
+ <p>If you are using language negotiation you can choose between
+ different naming conventions, because files can have more than
+ one extension, and the order of the extensions is normally
+ irrelevant (see the <a
+ href="mod/mod_mime.html#multipleext">mod_mime</a> documentation
+ for details).</p>
+
+ <p>A typical file has a MIME-type extension (<em>e.g.</em>,
+ <samp>html</samp>), maybe an encoding extension (<em>e.g.</em>,
+ <samp>gz</samp>), and of course a language extension
+ (<em>e.g.</em>, <samp>en</samp>) when we have different
+ language variants of this file.</p>
+
+ <p>Examples:</p>
+
+ <ul>
+ <li>foo.en.html</li>
+
+ <li>foo.html.en</li>
+
+ <li>foo.en.html.gz</li>
+ </ul>
+
+ <p>Here some more examples of filenames together with valid and
+ invalid hyperlinks:</p>
+
+ <table border="1" cellpadding="8" cellspacing="0">
+ <tr>
+ <th>Filename</th>
+
+ <th>Valid hyperlink</th>
+
+ <th>Invalid hyperlink</th>
+ </tr>
+
+ <tr>
+ <td><em>foo.html.en</em></td>
+
+ <td>foo<br />
+ foo.html</td>
+
+ <td>-</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.en.html</em></td>
+
+ <td>foo</td>
+
+ <td>foo.html</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.html.en.gz</em></td>
+
+ <td>foo<br />
+ foo.html</td>
+
+ <td>foo.gz<br />
+ foo.html.gz</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.en.html.gz</em></td>
+
+ <td>foo</td>
+
+ <td>foo.html<br />
+ foo.html.gz<br />
+ foo.gz</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.gz.html.en</em></td>
+
+ <td>foo<br />
+ foo.gz<br />
+ foo.gz.html</td>
+
+ <td>foo.html</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.html.gz.en</em></td>
+
+ <td>foo<br />
+ foo.html<br />
+ foo.html.gz</td>
+
+ <td>foo.gz</td>
+ </tr>
+ </table>
+
+ <p>Looking at the table above you will notice that it is always
+ possible to use the name without any extensions in an hyperlink
+ (<em>e.g.</em>, <samp>foo</samp>). The advantage is that you
+ can hide the actual type of a document rsp. file and can change
+ it later, <em>e.g.</em>, from <samp>html</samp> to
+ <samp>shtml</samp> or <samp>cgi</samp> without changing any
+ hyperlink references.</p>
+
+ <p>If you want to continue to use a MIME-type in your
+ hyperlinks (<em>e.g.</em> <samp>foo.html</samp>) the language
+ extension (including an encoding extension if there is one)
+ must be on the right hand side of the MIME-type extension
+ (<em>e.g.</em>, <samp>foo.html.en</samp>).</p>
+
+ <h2>Note on Caching</h2>
+
+ <p>When a cache stores a representation, it associates it with
+ the request URL. The next time that URL is requested, the cache
+ can use the stored representation. But, if the resource is
+ negotiable at the server, this might result in only the first
+ requested variant being cached and subsequent cache hits might
+ return the wrong response. To prevent this, Apache normally
+ marks all responses that are returned after content negotiation
+ as non-cacheable by HTTP/1.0 clients. Apache also supports the
+ HTTP/1.1 protocol features to allow caching of negotiated
+ responses.</p>
+
+ <p>For requests which come from a HTTP/1.0 compliant client
+ (either a browser or a cache), the directive
+ <tt>CacheNegotiatedDocs</tt> can be used to allow caching of
+ responses which were subject to negotiation. This directive can
+ be given in the server config or virtual host, and takes no
+ arguments. It has no effect on requests from HTTP/1.1 clients.
+ <!--#include virtual="footer.html" -->
+ </p>
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Content Negotiation</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Content Negotiation</H1>
-
-<P>
-Apache's support for content negotiation has been updated to meet the
-HTTP/1.1 specification. It can choose the best representation of a
-resource based on the browser-supplied preferences for media type,
-languages, character set and encoding. It is also implements a
-couple of features to give more intelligent handling of requests from
-browsers which send incomplete negotiation information. <P>
-
-Content negotiation is provided by the
-<A HREF="mod/mod_negotiation.html">mod_negotiation</A> module,
-which is compiled in by default.
-
-<HR>
-
-<H2>About Content Negotiation</H2>
-
-<P>
-A resource may be available in several different representations. For
-example, it might be available in different languages or different
-media types, or a combination. One way of selecting the most
-appropriate choice is to give the user an index page, and let them
-select. However it is often possible for the server to choose
-automatically. This works because browsers can send as part of each
-request information about what representations they prefer. For
-example, a browser could indicate that it would like to see
-information in French, if possible, else English will do. Browsers
-indicate their preferences by headers in the request. To request only
-French representations, the browser would send
-
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache Content Negotiation</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Content Negotiation</h1>
+
+ <p>Apache's support for content negotiation has been updated to
+ meet the HTTP/1.1 specification. It can choose the best
+ representation of a resource based on the browser-supplied
+ preferences for media type, languages, character set and
+ encoding. It is also implements a couple of features to give
+ more intelligent handling of requests from browsers which send
+ incomplete negotiation information.</p>
+
+ <p>Content negotiation is provided by the <a
+ href="mod/mod_negotiation.html">mod_negotiation</a> module,
+ which is compiled in by default.</p>
+ <hr />
+
+ <h2>About Content Negotiation</h2>
+
+ <p>A resource may be available in several different
+ representations. For example, it might be available in
+ different languages or different media types, or a combination.
+ One way of selecting the most appropriate choice is to give the
+ user an index page, and let them select. However it is often
+ possible for the server to choose automatically. This works
+ because browsers can send as part of each request information
+ about what representations they prefer. For example, a browser
+ could indicate that it would like to see information in French,
+ if possible, else English will do. Browsers indicate their
+ preferences by headers in the request. To request only French
+ representations, the browser would send</p>
+<pre>
Accept-Language: fr
-</PRE>
-
-<P>
-Note that this preference will only be applied when there is a choice
-of representations and they vary by language.
-<P>
-
-As an example of a more complex request, this browser has been
-configured to accept French and English, but prefer French, and to
-accept various media types, preferring HTML over plain text or other
-text types, and preferring GIF or JPEG over other media types, but also
-allowing any other media type as a last resort:
-
-<PRE>
+</pre>
+
+ <p>Note that this preference will only be applied when there is
+ a choice of representations and they vary by language.</p>
+
+ <p>As an example of a more complex request, this browser has
+ been configured to accept French and English, but prefer
+ French, and to accept various media types, preferring HTML over
+ plain text or other text types, and preferring GIF or JPEG over
+ other media types, but also allowing any other media type as a
+ last resort:</p>
+<pre>
Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6,
image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
-</PRE>
-
-Apache 1.2 supports 'server driven' content negotiation, as defined in
-the HTTP/1.1 specification. It fully supports the Accept,
-Accept-Language, Accept-Charset and Accept-Encoding request headers.
-Apache 1.3.4 also supports 'transparent' content negotiation, which is
-an experimental negotiation protocol defined in RFC 2295 and RFC 2296.
-It does not offer support for 'feature negotiation' as defined in
-these RFCs.
-<P>
-
-A <STRONG>resource</STRONG> is a conceptual entity identified by a URI
-(RFC 2396). An HTTP server like Apache provides access to
-<STRONG>representations</STRONG> of the resource(s) within its namespace,
-with each representation in the form of a sequence of bytes with a
-defined media type, character set, encoding, etc. Each resource may be
-associated with zero, one, or more than one representation
-at any given time. If multiple representations are available,
-the resource is referred to as <STRONG>negotiable</STRONG> and each of its
-representations is termed a <STRONG>variant</STRONG>. The ways in which the
-variants for a negotiable resource vary are called the
-<STRONG>dimensions</STRONG> of negotiation.
-
-<H2>Negotiation in Apache</H2>
-
-<P>
-In order to negotiate a resource, the server needs to be given
-information about each of the variants. This is done in one of two
-ways:
-
-<UL>
- <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which
- names the files containing the variants explicitly, or
- <LI> Using a 'MultiViews' search, where the server does an implicit
- filename pattern match and chooses from among the results.
-</UL>
-
-<H3>Using a type-map file</H3>
-
-<P>
-A type map is a document which is associated with the handler
-named <CODE>type-map</CODE> (or, for backwards-compatibility with
-older Apache configurations, the mime type
-<CODE>application/x-type-map</CODE>). Note that to use this feature,
-you must have a handler set in the configuration that defines a
-file suffix as <CODE>type-map</CODE>; this is best done with a
-
-<PRE>
+</pre>
+ Apache 1.2 supports 'server driven' content negotiation, as
+ defined in the HTTP/1.1 specification. It fully supports the
+ Accept, Accept-Language, Accept-Charset and Accept-Encoding
+ request headers. Apache 1.3.4 also supports 'transparent'
+ content negotiation, which is an experimental negotiation
+ protocol defined in RFC 2295 and RFC 2296. It does not offer
+ support for 'feature negotiation' as defined in these RFCs.
+
+ <p>A <strong>resource</strong> is a conceptual entity
+ identified by a URI (RFC 2396). An HTTP server like Apache
+ provides access to <strong>representations</strong> of the
+ resource(s) within its namespace, with each representation in
+ the form of a sequence of bytes with a defined media type,
+ character set, encoding, etc. Each resource may be associated
+ with zero, one, or more than one representation at any given
+ time. If multiple representations are available, the resource
+ is referred to as <strong>negotiable</strong> and each of its
+ representations is termed a <strong>variant</strong>. The ways
+ in which the variants for a negotiable resource vary are called
+ the <strong>dimensions</strong> of negotiation.</p>
+
+ <h2>Negotiation in Apache</h2>
+
+ <p>In order to negotiate a resource, the server needs to be
+ given information about each of the variants. This is done in
+ one of two ways:</p>
+
+ <ul>
+ <li>Using a type map (<em>i.e.</em>, a <code>*.var</code>
+ file) which names the files containing the variants
+ explicitly, or</li>
+
+ <li>Using a 'MultiViews' search, where the server does an
+ implicit filename pattern match and chooses from among the
+ results.</li>
+ </ul>
+
+ <h3>Using a type-map file</h3>
+
+ <p>A type map is a document which is associated with the
+ handler named <code>type-map</code> (or, for
+ backwards-compatibility with older Apache configurations, the
+ mime type <code>application/x-type-map</code>). Note that to
+ use this feature, you must have a handler set in the
+ configuration that defines a file suffix as
+ <code>type-map</code>; this is best done with a</p>
+<pre>
AddHandler type-map .var
-</PRE>
-
-in the server configuration file.<p>
-
-Type map files should have the same name as the resource which they are
-describing, and have an entry for each available variant; these entries
-consist of contiguous HTTP-format header lines. Entries for
-different variants are separated by blank lines. Blank lines are
-illegal within an entry. It is conventional to begin a map file with
-an entry for the combined entity as a whole (although this
-is not required, and if present will be ignored). An example
-map file is shown below. This file would be named <code>foo.html</code>,
-as it describes a resource named <code>foo</code>.
-
-<PRE>
+</pre>
+ in the server configuration file.
+
+ <p>Type map files should have the same name as the resource
+ which they are describing, and have an entry for each available
+ variant; these entries consist of contiguous HTTP-format header
+ lines. Entries for different variants are separated by blank
+ lines. Blank lines are illegal within an entry. It is
+ conventional to begin a map file with an entry for the combined
+ entity as a whole (although this is not required, and if
+ present will be ignored). An example map file is shown below.
+ This file would be named <code>foo.html</code>, as it describes
+ a resource named <code>foo</code>.</p>
+<pre>
URI: foo
URI: foo.en.html
URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de
-</PRE>
-
-Note also that a typemap file will take precedence over the filename's
-extension, even when Multiviews is on.
-
-If the variants have different source qualities, that may be indicated
-by the "qs" parameter to the media type, as in this picture (available
-as jpeg, gif, or ASCII-art):
-
-<PRE>
+</pre>
+ Note also that a typemap file will take precedence over the
+ filename's extension, even when Multiviews is on. If the
+ variants have different source qualities, that may be indicated
+ by the "qs" parameter to the media type, as in this picture
+ (available as jpeg, gif, or ASCII-art):
+<pre>
URI: foo
URI: foo.jpeg
URI: foo.txt
Content-type: text/plain; qs=0.01
-</PRE>
-<P>
-
-qs values can vary in the range 0.000 to 1.000. Note that any variant with
-a qs value of 0.000 will never be chosen. Variants with no 'qs'
-parameter value are given a qs factor of 1.0. The qs parameter indicates
-the relative 'quality' of this variant compared to the other available
-variants, independent of the client's capabilities. For example, a jpeg
-file is usually of higher source quality than an ascii file if it is
-attempting to represent a photograph. However, if the resource being
-represented is an original ascii art, then an ascii representation would
-have a higher source quality than a jpeg representation. A qs value
-is therefore specific to a given variant depending on the nature of
-the resource it represents.
-
-<P>
-The full list of headers recognized is:
-
-<DL>
- <DT> <CODE>URI:</CODE>
- <DD> uri of the file containing the variant (of the given media
- type, encoded with the given content encoding). These are
- interpreted as URLs relative to the map file; they must be on
- the same server (!), and they must refer to files to which the
- client would be granted access if they were to be requested
- directly.
- <DT> <CODE>Content-Type:</CODE>
- <DD> media type --- charset, level and "qs" parameters may be given. These
- are often referred to as MIME types; typical media types are
- <CODE>image/gif</CODE>, <CODE>text/plain</CODE>, or
- <CODE>text/html; level=3</CODE>.
- <DT> <CODE>Content-Language:</CODE>
- <DD> The languages of the variant, specified as an Internet standard
- language tag from RFC 1766 (<EM>e.g.</EM>, <CODE>en</CODE> for English,
- <CODE>kr</CODE> for Korean, <EM>etc.</EM>).
- <DT> <CODE>Content-Encoding:</CODE>
- <DD> If the file is compressed, or otherwise encoded, rather than
- containing the actual raw data, this says how that was done.
- Apache only recognizes encodings that are defined by an
- <A HREF="mod/mod_mime.html#addencoding">AddEncoding</A> directive.
- This normally includes the encodings <CODE>x-compress</CODE>
- for compress'd files, and <CODE>x-gzip</CODE> for gzip'd files.
- The <CODE>x-</CODE> prefix is ignored for encoding comparisons.
- <DT> <CODE>Content-Length:</CODE>
- <DD> The size of the file in bytes. Specifying content
- lengths in the type-map allows the server to compare file sizes
- without checking the actual files.
- <DT> <CODE>Description:</CODE>
- <DD> A human-readable textual description of the variant. If Apache cannot
- find any appropriate variant to return, it will return an error
- response which lists all available variants instead. Such a variant
- list will include the human-readable variant descriptions.
-</DL>
-
-Using a type map file is preferred over <code>MultiViews</code> because
-it requires less CPU time, and less file access, to parse a file
-explicitly listing the various resource variants, than to have to look
-at every matching file, and parse its file extensions.
-
-<H3>Multiviews</H3>
-
-<P>
-<CODE>MultiViews</CODE> is a per-directory option, meaning it can be set with
-an <CODE>Options</CODE> directive within a <CODE><Directory></CODE>,
-<CODE><Location></CODE> or <CODE><Files></CODE>
-section in <CODE>access.conf</CODE>, or (if <CODE>AllowOverride</CODE>
-is properly set) in <CODE>.htaccess</CODE> files. Note that
-<CODE>Options All</CODE> does not set <CODE>MultiViews</CODE>; you
-have to ask for it by name.
-
-<P>
-The effect of <CODE>MultiViews</CODE> is as follows: if the server
-receives a request for <CODE>/some/dir/foo</CODE>, if
-<CODE>/some/dir</CODE> has <CODE>MultiViews</CODE> enabled, and
-<CODE>/some/dir/foo</CODE> does <EM>not</EM> exist, then the server reads the
-directory looking for files named foo.*, and effectively fakes up a
-type map which names all those files, assigning them the same media
-types and content-encodings it would have if the client had asked for
-one of them by name. It then chooses the best match to the client's
-requirements.
-
-<P>
-<CODE>MultiViews</CODE> may also apply to searches for the file named by the
-<CODE>DirectoryIndex</CODE> directive, if the server is trying to
-index a directory. If the configuration files specify
-
-<PRE>
+</pre>
+
+ <p>qs values can vary in the range 0.000 to 1.000. Note that
+ any variant with a qs value of 0.000 will never be chosen.
+ Variants with no 'qs' parameter value are given a qs factor of
+ 1.0. The qs parameter indicates the relative 'quality' of this
+ variant compared to the other available variants, independent
+ of the client's capabilities. For example, a jpeg file is
+ usually of higher source quality than an ascii file if it is
+ attempting to represent a photograph. However, if the resource
+ being represented is an original ascii art, then an ascii
+ representation would have a higher source quality than a jpeg
+ representation. A qs value is therefore specific to a given
+ variant depending on the nature of the resource it
+ represents.</p>
+
+ <p>The full list of headers recognized is:</p>
+
+ <dl>
+ <dt><code>URI:</code></dt>
+
+ <dd>uri of the file containing the variant (of the given
+ media type, encoded with the given content encoding). These
+ are interpreted as URLs relative to the map file; they must
+ be on the same server (!), and they must refer to files to
+ which the client would be granted access if they were to be
+ requested directly.</dd>
+
+ <dt><code>Content-Type:</code></dt>
+
+ <dd>media type --- charset, level and "qs" parameters may be
+ given. These are often referred to as MIME types; typical
+ media types are <code>image/gif</code>,
+ <code>text/plain</code>, or
+ <code>text/html; level=3</code>.</dd>
+
+ <dt><code>Content-Language:</code></dt>
+
+ <dd>The languages of the variant, specified as an Internet
+ standard language tag from RFC 1766 (<em>e.g.</em>,
+ <code>en</code> for English, <code>kr</code> for Korean,
+ <em>etc.</em>).</dd>
+
+ <dt><code>Content-Encoding:</code></dt>
+
+ <dd>If the file is compressed, or otherwise encoded, rather
+ than containing the actual raw data, this says how that was
+ done. Apache only recognizes encodings that are defined by an
+ <a href="mod/mod_mime.html#addencoding">AddEncoding</a>
+ directive. This normally includes the encodings
+ <code>x-compress</code> for compress'd files, and
+ <code>x-gzip</code> for gzip'd files. The <code>x-</code>
+ prefix is ignored for encoding comparisons.</dd>
+
+ <dt><code>Content-Length:</code></dt>
+
+ <dd>The size of the file in bytes. Specifying content lengths
+ in the type-map allows the server to compare file sizes
+ without checking the actual files.</dd>
+
+ <dt><code>Description:</code></dt>
+
+ <dd>A human-readable textual description of the variant. If
+ Apache cannot find any appropriate variant to return, it will
+ return an error response which lists all available variants
+ instead. Such a variant list will include the human-readable
+ variant descriptions.</dd>
+ </dl>
+ Using a type map file is preferred over <code>MultiViews</code>
+ because it requires less CPU time, and less file access, to
+ parse a file explicitly listing the various resource variants,
+ than to have to look at every matching file, and parse its file
+ extensions.
+
+ <h3>Multiviews</h3>
+
+ <p><code>MultiViews</code> is a per-directory option, meaning
+ it can be set with an <code>Options</code> directive within a
+ <code><Directory></code>, <code><Location></code>
+ or <code><Files></code> section in
+ <code>access.conf</code>, or (if <code>AllowOverride</code> is
+ properly set) in <code>.htaccess</code> files. Note that
+ <code>Options All</code> does not set <code>MultiViews</code>;
+ you have to ask for it by name.</p>
+
+ <p>The effect of <code>MultiViews</code> is as follows: if the
+ server receives a request for <code>/some/dir/foo</code>, if
+ <code>/some/dir</code> has <code>MultiViews</code> enabled, and
+ <code>/some/dir/foo</code> does <em>not</em> exist, then the
+ server reads the directory looking for files named foo.*, and
+ effectively fakes up a type map which names all those files,
+ assigning them the same media types and content-encodings it
+ would have if the client had asked for one of them by name. It
+ then chooses the best match to the client's requirements.</p>
+
+ <p><code>MultiViews</code> may also apply to searches for the
+ file named by the <code>DirectoryIndex</code> directive, if the
+ server is trying to index a directory. If the configuration
+ files specify</p>
+<pre>
DirectoryIndex index
-</PRE>
-
-then the server will arbitrate between <CODE>index.html</CODE>
-and <CODE>index.html3</CODE> if both are present. If neither are
-present, and <CODE>index.cgi</CODE> is there, the server will run it.
-
-<P>
-If one of the files found when reading the directive is a CGI script,
-it's not obvious what should happen. The code gives that case
-special treatment --- if the request was a POST, or a GET with
-QUERY_ARGS or PATH_INFO, the script is given an extremely high quality
-rating, and generally invoked; otherwise it is given an extremely low
-quality rating, which generally causes one of the other views (if any)
-to be retrieved.
-
-<H2>The Negotiation Methods</H2>
-
-After Apache has obtained a list of the variants for a given resource,
-either from a type-map file or from the filenames in the directory, it
-invokes one of two methods to decide on the 'best' variant to
-return, if any. It is not necessary to know any of the details of how
-negotiation actually takes place in order to use Apache's content
-negotiation features. However the rest of this document explains the
-methods used for those interested.
-<P>
-
-There are two negotiation methods:
-
-<OL>
-
-<LI><STRONG>Server driven negotiation with the Apache
-algorithm</STRONG> is used in the normal case. The Apache algorithm is
-explained in more detail below. When this algorithm is used, Apache
-can sometimes 'fiddle' the quality factor of a particular dimension to
-achieve a better result. The ways Apache can fiddle quality factors is
-explained in more detail below.
-
-<LI><STRONG>Transparent content negotiation</STRONG> is used when the
-browser specifically requests this through the mechanism defined in RFC
-2295. This negotiation method gives the browser full control over
-deciding on the 'best' variant, the result is therefore dependent on
-the specific algorithms used by the browser. As part of the
-transparent negotiation process, the browser can ask Apache to run the
-'remote variant selection algorithm' defined in RFC 2296.
-
-</OL>
-
-
-<H3>Dimensions of Negotiation</H3>
-
-<TABLE>
-<TR valign="top">
-<TH>Dimension
-<TH>Notes
-<TR valign="top">
-<TD>Media Type
-<TD>Browser indicates preferences with the Accept header field. Each item
-can have an associated quality factor. Variant description can also
-have a quality factor (the "qs" parameter).
-<TR valign="top">
-<TD>Language
-<TD>Browser indicates preferences with the Accept-Language header field.
-Each item can have a quality factor. Variants can be associated with none, one
-or more than one language.
-<TR valign="top">
-<TD>Encoding
-<TD>Browser indicates preference with the Accept-Encoding header field.
-Each item can have a quality factor.
-<TR valign="top">
-<TD>Charset
-<TD>Browser indicates preference with the Accept-Charset header field.
-Each item can have a quality factor.
-Variants can indicate a charset as a parameter of the media type.
-</TABLE>
-
-<H3>Apache Negotiation Algorithm</H3>
-
-<P>
-Apache can use the following algorithm to select the 'best' variant
-(if any) to return to the browser. This algorithm is not
-further configurable. It operates as follows:
-
-<OL>
-<LI>First, for each dimension of the negotiation, check the appropriate
-<EM>Accept*</EM> header field and assign a quality to each
-variant. If the <EM>Accept*</EM> header for any dimension implies that this
-variant is not acceptable, eliminate it. If no variants remain, go
-to step 4.
-
-<LI>Select the 'best' variant by a process of elimination. Each of the
-following tests is applied in order. Any variants not selected at each
-test are eliminated. After each test, if only one variant remains,
-select it as the best match and proceed to step 3. If more than one
-variant remains, move on to the next test.
-
-<OL>
-<LI>Multiply the quality factor from the Accept header with the
- quality-of-source factor for this variant's media type, and select
- the variants with the highest value.
-
-<LI>Select the variants with the highest language quality factor.
-
-<LI>Select the variants with the best language match, using either the
- order of languages in the Accept-Language header (if present), or else
- the order of languages in the <CODE>LanguagePriority</CODE>
- directive (if present).
-
-<LI>Select the variants with the highest 'level' media parameter
- (used to give the version of text/html media types).
-
-<LI>Select variants with the best charset media parameters,
- as given on the Accept-Charset header line. Charset ISO-8859-1
- is acceptable unless explicitly excluded. Variants with a
- <CODE>text/*</CODE> media type but not explicitly associated
- with a particular charset are assumed to be in ISO-8859-1.
-
-<LI>Select those variants which have associated
- charset media parameters that are <EM>not</EM> ISO-8859-1.
- If there are no such variants, select all variants instead.
-
-<LI>Select the variants with the best encoding. If there are
- variants with an encoding that is acceptable to the user-agent,
- select only these variants. Otherwise if there is a mix of encoded
- and non-encoded variants, select only the unencoded variants.
- If either all variants are encoded or all variants are not encoded,
- select all variants.
-
-<LI>Select the variants with the smallest content length.
-
-<LI>Select the first variant of those remaining. This will be either the
- first listed in the type-map file, or when variants are read from
- the directory, the one whose file name comes first when sorted using
- ASCII code order.
-
-</OL>
-
-<LI>The algorithm has now selected one 'best' variant, so return
- it as the response. The HTTP response header Vary is set to indicate the
- dimensions of negotiation (browsers and caches can use this
- information when caching the resource). End.
-
-<LI>To get here means no variant was selected (because none are acceptable
- to the browser). Return a 406 status (meaning "No acceptable representation")
- with a response body consisting of an HTML document listing the
- available variants. Also set the HTTP Vary header to indicate the
- dimensions of variance.
-
-</OL>
-
-<H2><A NAME="better">Fiddling with Quality Values</A></H2>
-
-<P>
-Apache sometimes changes the quality values from what would be
-expected by a strict interpretation of the Apache negotiation
-algorithm above. This is to get a better result from the algorithm for
-browsers which do not send full or accurate information. Some of the
-most popular browsers send Accept header information which would
-otherwise result in the selection of the wrong variant in many
-cases. If a browser sends full and correct information these fiddles
-will not be applied.
-<P>
-
-<H3>Media Types and Wildcards</H3>
-
-<P>
-The Accept: request header indicates preferences for media types. It
-can also include 'wildcard' media types, such as "image/*" or "*/*"
-where the * matches any string. So a request including:
-<PRE>
+</pre>
+ then the server will arbitrate between <code>index.html</code>
+ and <code>index.html3</code> if both are present. If neither
+ are present, and <code>index.cgi</code> is there, the server
+ will run it.
+
+ <p>If one of the files found when reading the directive is a
+ CGI script, it's not obvious what should happen. The code gives
+ that case special treatment --- if the request was a POST, or a
+ GET with QUERY_ARGS or PATH_INFO, the script is given an
+ extremely high quality rating, and generally invoked; otherwise
+ it is given an extremely low quality rating, which generally
+ causes one of the other views (if any) to be retrieved.</p>
+
+ <h2>The Negotiation Methods</h2>
+ After Apache has obtained a list of the variants for a given
+ resource, either from a type-map file or from the filenames in
+ the directory, it invokes one of two methods to decide on the
+ 'best' variant to return, if any. It is not necessary to know
+ any of the details of how negotiation actually takes place in
+ order to use Apache's content negotiation features. However the
+ rest of this document explains the methods used for those
+ interested.
+
+ <p>There are two negotiation methods:</p>
+
+ <ol>
+ <li><strong>Server driven negotiation with the Apache
+ algorithm</strong> is used in the normal case. The Apache
+ algorithm is explained in more detail below. When this
+ algorithm is used, Apache can sometimes 'fiddle' the quality
+ factor of a particular dimension to achieve a better result.
+ The ways Apache can fiddle quality factors is explained in
+ more detail below.</li>
+
+ <li><strong>Transparent content negotiation</strong> is used
+ when the browser specifically requests this through the
+ mechanism defined in RFC 2295. This negotiation method gives
+ the browser full control over deciding on the 'best' variant,
+ the result is therefore dependent on the specific algorithms
+ used by the browser. As part of the transparent negotiation
+ process, the browser can ask Apache to run the 'remote
+ variant selection algorithm' defined in RFC 2296.</li>
+ </ol>
+
+ <h3>Dimensions of Negotiation</h3>
+
+ <table>
+ <tr valign="top">
+ <th>Dimension</th>
+
+ <th>Notes</th>
+ </tr>
+
+ <tr valign="top">
+ <td>Media Type</td>
+
+ <td>Browser indicates preferences with the Accept header
+ field. Each item can have an associated quality factor.
+ Variant description can also have a quality factor (the
+ "qs" parameter).</td>
+ </tr>
+
+ <tr valign="top">
+ <td>Language</td>
+
+ <td>Browser indicates preferences with the Accept-Language
+ header field. Each item can have a quality factor. Variants
+ can be associated with none, one or more than one
+ language.</td>
+ </tr>
+
+ <tr valign="top">
+ <td>Encoding</td>
+
+ <td>Browser indicates preference with the Accept-Encoding
+ header field. Each item can have a quality factor.</td>
+ </tr>
+
+ <tr valign="top">
+ <td>Charset</td>
+
+ <td>Browser indicates preference with the Accept-Charset
+ header field. Each item can have a quality factor. Variants
+ can indicate a charset as a parameter of the media
+ type.</td>
+ </tr>
+ </table>
+
+ <h3>Apache Negotiation Algorithm</h3>
+
+ <p>Apache can use the following algorithm to select the 'best'
+ variant (if any) to return to the browser. This algorithm is
+ not further configurable. It operates as follows:</p>
+
+ <ol>
+ <li>First, for each dimension of the negotiation, check the
+ appropriate <em>Accept*</em> header field and assign a
+ quality to each variant. If the <em>Accept*</em> header for
+ any dimension implies that this variant is not acceptable,
+ eliminate it. If no variants remain, go to step 4.</li>
+
+ <li>
+ Select the 'best' variant by a process of elimination. Each
+ of the following tests is applied in order. Any variants
+ not selected at each test are eliminated. After each test,
+ if only one variant remains, select it as the best match
+ and proceed to step 3. If more than one variant remains,
+ move on to the next test.
+
+ <ol>
+ <li>Multiply the quality factor from the Accept header
+ with the quality-of-source factor for this variant's
+ media type, and select the variants with the highest
+ value.</li>
+
+ <li>Select the variants with the highest language quality
+ factor.</li>
+
+ <li>Select the variants with the best language match,
+ using either the order of languages in the
+ Accept-Language header (if present), or else the order of
+ languages in the <code>LanguagePriority</code> directive
+ (if present).</li>
+
+ <li>Select the variants with the highest 'level' media
+ parameter (used to give the version of text/html media
+ types).</li>
+
+ <li>Select variants with the best charset media
+ parameters, as given on the Accept-Charset header line.
+ Charset ISO-8859-1 is acceptable unless explicitly
+ excluded. Variants with a <code>text/*</code> media type
+ but not explicitly associated with a particular charset
+ are assumed to be in ISO-8859-1.</li>
+
+ <li>Select those variants which have associated charset
+ media parameters that are <em>not</em> ISO-8859-1. If
+ there are no such variants, select all variants
+ instead.</li>
+
+ <li>Select the variants with the best encoding. If there
+ are variants with an encoding that is acceptable to the
+ user-agent, select only these variants. Otherwise if
+ there is a mix of encoded and non-encoded variants,
+ select only the unencoded variants. If either all
+ variants are encoded or all variants are not encoded,
+ select all variants.</li>
+
+ <li>Select the variants with the smallest content
+ length.</li>
+
+ <li>Select the first variant of those remaining. This
+ will be either the first listed in the type-map file, or
+ when variants are read from the directory, the one whose
+ file name comes first when sorted using ASCII code
+ order.</li>
+ </ol>
+ </li>
+
+ <li>The algorithm has now selected one 'best' variant, so
+ return it as the response. The HTTP response header Vary is
+ set to indicate the dimensions of negotiation (browsers and
+ caches can use this information when caching the resource).
+ End.</li>
+
+ <li>To get here means no variant was selected (because none
+ are acceptable to the browser). Return a 406 status (meaning
+ "No acceptable representation") with a response body
+ consisting of an HTML document listing the available
+ variants. Also set the HTTP Vary header to indicate the
+ dimensions of variance.</li>
+ </ol>
+
+ <h2><a id="better" name="better">Fiddling with Quality
+ Values</a></h2>
+
+ <p>Apache sometimes changes the quality values from what would
+ be expected by a strict interpretation of the Apache
+ negotiation algorithm above. This is to get a better result
+ from the algorithm for browsers which do not send full or
+ accurate information. Some of the most popular browsers send
+ Accept header information which would otherwise result in the
+ selection of the wrong variant in many cases. If a browser
+ sends full and correct information these fiddles will not be
+ applied.</p>
+
+ <h3>Media Types and Wildcards</h3>
+
+ <p>The Accept: request header indicates preferences for media
+ types. It can also include 'wildcard' media types, such as
+ "image/*" or "*/*" where the * matches any string. So a request
+ including:</p>
+<pre>
Accept: image/*, */*
-</PRE>
-
-would indicate that any type starting "image/" is acceptable,
-as is any other type (so the first "image/*" is redundant). Some
-browsers routinely send wildcards in addition to explicit types they
-can handle. For example:
-<PRE>
+</pre>
+ would indicate that any type starting "image/" is acceptable,
+ as is any other type (so the first "image/*" is redundant).
+ Some browsers routinely send wildcards in addition to explicit
+ types they can handle. For example:
+<pre>
Accept: text/html, text/plain, image/gif, image/jpeg, */*
-</PRE>
-
-The intention of this is to indicate that the explicitly
-listed types are preferred, but if a different representation is
-available, that is ok too. However under the basic algorithm, as given
-above, the */* wildcard has exactly equal preference to all the other
-types, so they are not being preferred. The browser should really have
-sent a request with a lower quality (preference) value for *.*, such
-as:
-<PRE>
+</pre>
+ The intention of this is to indicate that the explicitly listed
+ types are preferred, but if a different representation is
+ available, that is ok too. However under the basic algorithm,
+ as given above, the */* wildcard has exactly equal preference
+ to all the other types, so they are not being preferred. The
+ browser should really have sent a request with a lower quality
+ (preference) value for *.*, such as:
+<pre>
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-</PRE>
-
-The explicit types have no quality factor, so they default to a
-preference of 1.0 (the highest). The wildcard */* is given
-a low preference of 0.01, so other types will only be returned if
-no variant matches an explicitly listed type.
-<P>
-
-If the Accept: header contains <EM>no</EM> q factors at all, Apache sets
-the q value of "*/*", if present, to 0.01 to emulate the desired
-behavior. It also sets the q value of wildcards of the format
-"type/*" to 0.02 (so these are preferred over matches against
-"*/*". If any media type on the Accept: header contains a q factor,
-these special values are <EM>not</EM> applied, so requests from browsers
-which send the correct information to start with work as expected.
-
-<H3>Variants with no Language</H3>
-
-<P>
-If some of the variants for a particular resource have a language
-attribute, and some do not, those variants with no language
-are given a very low language quality factor of 0.001.<P>
-
-The reason for setting this language quality factor for
-variant with no language to a very low value is to allow
-for a default variant which can be supplied if none of the
-other variants match the browser's language preferences.
-
-For example, consider the situation with three variants:
-
-<UL>
-<LI>foo.en.html, language en
-<LI>foo.fr.html, language en
-<LI>foo.html, no language
-</UL>
-
-<P>
-The meaning of a variant with no language is that it is
-always acceptable to the browser. If the request Accept-Language
-header includes either en or fr (or both) one of foo.en.html
-or foo.fr.html will be returned. If the browser does not list
-either en or fr as acceptable, foo.html will be returned instead.
-
-<H2>Extensions to Transparent Content Negotiation</H2>
-
-Apache extends the transparent content negotiation protocol (RFC 2295)
-as follows. A new <CODE> {encoding ..}</CODE> element is used in
-variant lists to label variants which are available with a specific
-content-encoding only. The implementation of the
-RVSA/1.0 algorithm (RFC 2296) is extended to recognize encoded
-variants in the list, and to use them as candidate variants whenever
-their encodings are acceptable according to the Accept-Encoding
-request header. The RVSA/1.0 implementation does not round computed
-quality factors to 5 decimal places before choosing the best variant.
-
-<H2>Note on hyperlinks and naming conventions</H2>
-
-<P>
-If you are using language negotiation you can choose between
-different naming conventions, because files can have more than one
-extension, and the order of the extensions is normally irrelevant
-(see the <A HREF="mod/mod_mime.html#multipleext">mod_mime</A>
-documentation for details).
-<P>
-A typical file has a MIME-type extension (<EM>e.g.</EM>, <SAMP>html</SAMP>),
-maybe an encoding extension (<EM>e.g.</EM>, <SAMP>gz</SAMP>), and of course a
-language extension (<EM>e.g.</EM>, <SAMP>en</SAMP>) when we have different
-language variants of this file.
-
-<P>
-Examples:
-<UL>
-<LI>foo.en.html
-<LI>foo.html.en
-<LI>foo.en.html.gz
-</UL>
-
-<P>
-Here some more examples of filenames together with valid and invalid
-hyperlinks:
-</P>
-
-<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0>
-<TR>
- <TH>Filename</TH>
- <TH>Valid hyperlink</TH>
- <TH>Invalid hyperlink</TH>
-</TR>
-<TR>
- <TD><EM>foo.html.en</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>-</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html</EM></TD>
- <TD>foo</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.en.gz</EM></TD>
- <TD>foo<BR>
- foo.html</TD>
- <TD>foo.gz<BR>
- foo.html.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.en.html.gz</EM></TD>
- <TD>foo</TD>
- <TD>foo.html<BR>
- foo.html.gz<BR>
- foo.gz</TD>
-</TR>
-<TR>
- <TD><EM>foo.gz.html.en</EM></TD>
- <TD>foo<BR>
- foo.gz<BR>
- foo.gz.html</TD>
- <TD>foo.html</TD>
-</TR>
-<TR>
- <TD><EM>foo.html.gz.en</EM></TD>
- <TD>foo<BR>
- foo.html<BR>
- foo.html.gz</TD>
- <TD>foo.gz</TD>
-</TR>
-</TABLE>
-
-<P>
-Looking at the table above you will notice that it is always possible to
-use the name without any extensions in an hyperlink (<EM>e.g.</EM>, <SAMP>foo</SAMP>).
-The advantage is that you can hide the actual type of a
-document rsp. file and can change it later, <EM>e.g.</EM>, from <SAMP>html</SAMP>
-to <SAMP>shtml</SAMP> or <SAMP>cgi</SAMP> without changing any
-hyperlink references.
-
-<P>
-If you want to continue to use a MIME-type in your hyperlinks (<EM>e.g.</EM>
-<SAMP>foo.html</SAMP>) the language extension (including an encoding extension
-if there is one) must be on the right hand side of the MIME-type extension
-(<EM>e.g.</EM>, <SAMP>foo.html.en</SAMP>).
-
-
-<H2>Note on Caching</H2>
-
-<P>
-When a cache stores a representation, it associates it with the request URL.
-The next time that URL is requested, the cache can use the stored
-representation. But, if the resource is negotiable at the server,
-this might result in only the first requested variant being cached and
-subsequent cache hits might return the wrong response. To prevent this,
-Apache normally marks all responses that are returned after content negotiation
-as non-cacheable by HTTP/1.0 clients. Apache also supports the HTTP/1.1
-protocol features to allow caching of negotiated responses. <P>
-
-For requests which come from a HTTP/1.0 compliant client (either a
-browser or a cache), the directive <TT>CacheNegotiatedDocs</TT> can be
-used to allow caching of responses which were subject to negotiation.
-This directive can be given in the server config or virtual host, and
-takes no arguments. It has no effect on requests from HTTP/1.1 clients.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ The explicit types have no quality factor, so they default to a
+ preference of 1.0 (the highest). The wildcard */* is given a
+ low preference of 0.01, so other types will only be returned if
+ no variant matches an explicitly listed type.
+
+ <p>If the Accept: header contains <em>no</em> q factors at all,
+ Apache sets the q value of "*/*", if present, to 0.01 to
+ emulate the desired behavior. It also sets the q value of
+ wildcards of the format "type/*" to 0.02 (so these are
+ preferred over matches against "*/*". If any media type on the
+ Accept: header contains a q factor, these special values are
+ <em>not</em> applied, so requests from browsers which send the
+ correct information to start with work as expected.</p>
+
+ <h3>Variants with no Language</h3>
+
+ <p>If some of the variants for a particular resource have a
+ language attribute, and some do not, those variants with no
+ language are given a very low language quality factor of
+ 0.001.</p>
+
+ <p>The reason for setting this language quality factor for
+ variant with no language to a very low value is to allow for a
+ default variant which can be supplied if none of the other
+ variants match the browser's language preferences. For example,
+ consider the situation with three variants:</p>
+
+ <ul>
+ <li>foo.en.html, language en</li>
+
+ <li>foo.fr.html, language en</li>
+
+ <li>foo.html, no language</li>
+ </ul>
+
+ <p>The meaning of a variant with no language is that it is
+ always acceptable to the browser. If the request
+ Accept-Language header includes either en or fr (or both) one
+ of foo.en.html or foo.fr.html will be returned. If the browser
+ does not list either en or fr as acceptable, foo.html will be
+ returned instead.</p>
+
+ <h2>Extensions to Transparent Content Negotiation</h2>
+ Apache extends the transparent content negotiation protocol
+ (RFC 2295) as follows. A new <code>{encoding ..}</code> element
+ is used in variant lists to label variants which are available
+ with a specific content-encoding only. The implementation of
+ the RVSA/1.0 algorithm (RFC 2296) is extended to recognize
+ encoded variants in the list, and to use them as candidate
+ variants whenever their encodings are acceptable according to
+ the Accept-Encoding request header. The RVSA/1.0 implementation
+ does not round computed quality factors to 5 decimal places
+ before choosing the best variant.
+
+ <h2>Note on hyperlinks and naming conventions</h2>
+
+ <p>If you are using language negotiation you can choose between
+ different naming conventions, because files can have more than
+ one extension, and the order of the extensions is normally
+ irrelevant (see the <a
+ href="mod/mod_mime.html#multipleext">mod_mime</a> documentation
+ for details).</p>
+
+ <p>A typical file has a MIME-type extension (<em>e.g.</em>,
+ <samp>html</samp>), maybe an encoding extension (<em>e.g.</em>,
+ <samp>gz</samp>), and of course a language extension
+ (<em>e.g.</em>, <samp>en</samp>) when we have different
+ language variants of this file.</p>
+
+ <p>Examples:</p>
+
+ <ul>
+ <li>foo.en.html</li>
+
+ <li>foo.html.en</li>
+
+ <li>foo.en.html.gz</li>
+ </ul>
+
+ <p>Here some more examples of filenames together with valid and
+ invalid hyperlinks:</p>
+
+ <table border="1" cellpadding="8" cellspacing="0">
+ <tr>
+ <th>Filename</th>
+
+ <th>Valid hyperlink</th>
+
+ <th>Invalid hyperlink</th>
+ </tr>
+
+ <tr>
+ <td><em>foo.html.en</em></td>
+
+ <td>foo<br />
+ foo.html</td>
+
+ <td>-</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.en.html</em></td>
+
+ <td>foo</td>
+
+ <td>foo.html</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.html.en.gz</em></td>
+
+ <td>foo<br />
+ foo.html</td>
+
+ <td>foo.gz<br />
+ foo.html.gz</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.en.html.gz</em></td>
+
+ <td>foo</td>
+
+ <td>foo.html<br />
+ foo.html.gz<br />
+ foo.gz</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.gz.html.en</em></td>
+
+ <td>foo<br />
+ foo.gz<br />
+ foo.gz.html</td>
+
+ <td>foo.html</td>
+ </tr>
+
+ <tr>
+ <td><em>foo.html.gz.en</em></td>
+
+ <td>foo<br />
+ foo.html<br />
+ foo.html.gz</td>
+
+ <td>foo.gz</td>
+ </tr>
+ </table>
+
+ <p>Looking at the table above you will notice that it is always
+ possible to use the name without any extensions in an hyperlink
+ (<em>e.g.</em>, <samp>foo</samp>). The advantage is that you
+ can hide the actual type of a document rsp. file and can change
+ it later, <em>e.g.</em>, from <samp>html</samp> to
+ <samp>shtml</samp> or <samp>cgi</samp> without changing any
+ hyperlink references.</p>
+
+ <p>If you want to continue to use a MIME-type in your
+ hyperlinks (<em>e.g.</em> <samp>foo.html</samp>) the language
+ extension (including an encoding extension if there is one)
+ must be on the right hand side of the MIME-type extension
+ (<em>e.g.</em>, <samp>foo.html.en</samp>).</p>
+
+ <h2>Note on Caching</h2>
+
+ <p>When a cache stores a representation, it associates it with
+ the request URL. The next time that URL is requested, the cache
+ can use the stored representation. But, if the resource is
+ negotiable at the server, this might result in only the first
+ requested variant being cached and subsequent cache hits might
+ return the wrong response. To prevent this, Apache normally
+ marks all responses that are returned after content negotiation
+ as non-cacheable by HTTP/1.0 clients. Apache also supports the
+ HTTP/1.1 protocol features to allow caching of negotiated
+ responses.</p>
+
+ <p>For requests which come from a HTTP/1.0 compliant client
+ (either a browser or a cache), the directive
+ <tt>CacheNegotiatedDocs</tt> can be used to allow caching of
+ responses which were subject to negotiation. This directive can
+ be given in the server config or virtual host, and takes no
+ arguments. It has no effect on requests from HTTP/1.1 clients.
+ <!--#include virtual="footer.html" -->
+ </p>
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Custom error responses</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Custom error responses</H1>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Additional functionality. Allows webmasters to configure the response of
- Apache to some error or problem.
-
- <P>Customizable responses can be defined to be activated in the
- event of a server detected error or problem.
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Custom error responses</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Custom error responses</h1>
+
+ <dl>
+ <dt>Purpose</dt>
+
+ <dd>
+ Additional functionality. Allows webmasters to configure
+ the response of Apache to some error or problem.
+
+ <p>Customizable responses can be defined to be activated in
+ the event of a server detected error or problem.</p>
+
+ <p>e.g. if a script crashes and produces a "500 Server
+ Error" response, then this response can be replaced with
+ either some friendlier text or by a redirection to another
+ URL (local or external).</p>
+ </dd>
+
+ <dt>Old behavior</dt>
+
+ <dd>NCSA httpd 1.3 would return some boring old error/problem
+ message which would often be meaningless to the user, and
+ would provide no means of logging the symptoms which caused
+ it.<br />
+ </dd>
+
+ <dt>New behavior</dt>
- <P>e.g. if a script crashes and produces a "500 Server Error"
- response, then this response can be replaced with either some
- friendlier text or by a redirection to another URL (local or
- external).
- <P>
+ <dd>
+ The server can be asked to;
-<DT>Old behavior
+ <ol>
+ <li>Display some other text, instead of the NCSA hard
+ coded messages, or</li>
- <DD>NCSA httpd 1.3 would return some boring old error/problem message
- which would often be meaningless to the user, and would provide no
- means of logging the symptoms which caused it.<BR>
-
- <P>
-
-<DT>New behavior
-
- <DD>The server can be asked to;
- <OL>
- <LI>Display some other text, instead of the NCSA hard coded messages, or
- <LI>redirect to a local URL, or
- <LI>redirect to an external URL.
- </OL>
-
- <P>Redirecting to another URL can be useful, but only if some information
- can be passed which can then be used to explain and/or log the
- error/problem
- more clearly.
-
- <P>To achieve this, Apache will define new CGI-like environment
- variables, <EM>e.g.</EM>
-
- <BLOCKQUOTE><CODE>
-REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
-REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712) <BR>
-REDIRECT_PATH=.:/bin:/usr/local/bin:/etc <BR>
-REDIRECT_QUERY_STRING= <BR>
-REDIRECT_REMOTE_ADDR=121.345.78.123 <BR>
-REDIRECT_REMOTE_HOST=ooh.ahhh.com <BR>
-REDIRECT_SERVER_NAME=crash.bang.edu <BR>
-REDIRECT_SERVER_PORT=80 <BR>
-REDIRECT_SERVER_SOFTWARE=Apache/0.8.15 <BR>
-REDIRECT_URL=/cgi-bin/buggy.pl <BR>
- </CODE></BLOCKQUOTE>
-
- <P>note the <CODE>REDIRECT_</CODE> prefix.
-
- <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE>
- will
- be passed to the new URL (assuming it's a cgi-script or a cgi-include).
- The
- other variables will exist only if they existed prior to the
- error/problem.
- <STRONG>None</STRONG> of these will be set if your ErrorDocument is an
- <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a
- scheme name
- like <CODE>http:</CODE>, even if it refers to the same host as the
- server).<P>
-
-<DT>Configuration
-
- <DD> Use of "ErrorDocument" is enabled for .htaccess files when the
- <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is
- allowed.
-
- <P>Here are some examples...
-
- <BLOCKQUOTE><CODE>
-ErrorDocument 500 /cgi-bin/crash-recover <BR>
-ErrorDocument 500 "Sorry, our script crashed. Oh dear<BR>
-ErrorDocument 500 http://xxx/ <BR>
-ErrorDocument 404 /Lame_excuses/not_found.html <BR>
-ErrorDocument 401 /Subscription/how_to_subscribe.html
- </CODE></BLOCKQUOTE>
-
- <P>The syntax is,
-
- <P><CODE><A HREF="mod/core.html#errordocument">ErrorDocument</A></CODE>
-<3-digit-code> action
-
- <P>where the action can be,
-
- <OL>
- <LI>Text to be displayed. Prefix the text with a quote ("). Whatever
- follows the quote is displayed. <EM>Note: the (") prefix isn't
- displayed.</EM>
-
- <LI>An external URL to redirect to.
-
- <LI>A local URL to redirect to.
-
- </OL>
-</DL>
-
-<P><HR><P>
-
-<H2>Custom error responses and redirects</H2>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Apache's behavior to redirected URLs has been modified so that additional
- environment variables are available to a script/server-include.<P>
-
-<DT>Old behavior
-
- <DD>Standard CGI vars were made available to a script which has been
- redirected to. No indication of where the redirection came from was
- provided.
-
- <P>
-
-<DT>New behavior
- <DD>
-
-A new batch of environment variables will be initialized for use by a
-script which has been redirected to. Each new variable will have the
-prefix <CODE>REDIRECT_</CODE>. <CODE>REDIRECT_</CODE> environment
-variables are created from the CGI environment variables which existed
-prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>
-prefix, <EM>i.e.</EM>, <CODE>HTTP_USER_AGENT</CODE> becomes
-<CODE>REDIRECT_HTTP_USER_AGENT</CODE>. In addition to these new
-variables, Apache will define <CODE>REDIRECT_URL</CODE> and
-<CODE>REDIRECT_STATUS</CODE> to help the script trace its origin.
-Both the original URL and the URL being redirected to can be logged in
-the access log.
-
-</DL>
-<P>
-If the ErrorDocument specifies a local redirect to a CGI script, the script
-should include a "<SAMP>Status:</SAMP>" header field in its output
-in order to ensure the propagation all the way back to the client
-of the error condition that caused it to be invoked. For instance, a Perl
-ErrorDocument script might include the following:
-</P>
-<PRE>
+ <li>redirect to a local URL, or</li>
+
+ <li>redirect to an external URL.</li>
+ </ol>
+
+ <p>Redirecting to another URL can be useful, but only if
+ some information can be passed which can then be used to
+ explain and/or log the error/problem more clearly.</p>
+
+ <p>To achieve this, Apache will define new CGI-like
+ environment variables, <em>e.g.</em></p>
+
+ <blockquote>
+ <code>REDIRECT_HTTP_ACCEPT=*/*, image/gif,
+ image/x-xbitmap, image/jpeg<br />
+ REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX
+ A.09.05 9000/712)<br />
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />
+ REDIRECT_QUERY_STRING=<br />
+ REDIRECT_REMOTE_ADDR=121.345.78.123<br />
+ REDIRECT_REMOTE_HOST=ooh.ahhh.com<br />
+ REDIRECT_SERVER_NAME=crash.bang.edu<br />
+ REDIRECT_SERVER_PORT=80<br />
+ REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />
+ REDIRECT_URL=/cgi-bin/buggy.pl<br />
+ </code>
+ </blockquote>
+
+ <p>note the <code>REDIRECT_</code> prefix.</p>
+
+ <p>At least <code>REDIRECT_URL</code> and
+ <code>REDIRECT_QUERY_STRING</code> will be passed to the
+ new URL (assuming it's a cgi-script or a cgi-include). The
+ other variables will exist only if they existed prior to
+ the error/problem. <strong>None</strong> of these will be
+ set if your ErrorDocument is an <em>external</em> redirect
+ (<em>i.e.</em>, anything starting with a scheme name like
+ <code>http:</code>, even if it refers to the same host as
+ the server).</p>
+ </dd>
+
+ <dt>Configuration</dt>
+
+ <dd>
+ Use of "ErrorDocument" is enabled for .htaccess files when
+ the <a href="mod/core.html#allowoverride">"FileInfo"
+ override</a> is allowed.
+
+ <p>Here are some examples...</p>
+
+ <blockquote>
+ <code>ErrorDocument 500 /cgi-bin/crash-recover<br />
+ ErrorDocument 500 "Sorry, our script crashed. Oh
+ dear<br />
+ ErrorDocument 500 http://xxx/<br />
+ ErrorDocument 404 /Lame_excuses/not_found.html<br />
+ ErrorDocument 401
+ /Subscription/how_to_subscribe.html</code>
+ </blockquote>
+
+ <p>The syntax is,</p>
+
+ <p><code><a
+ href="mod/core.html#errordocument">ErrorDocument</a></code>
+ <3-digit-code> action</p>
+
+ <p>where the action can be,</p>
+
+ <ol>
+ <li>Text to be displayed. Prefix the text with a quote
+ ("). Whatever follows the quote is displayed. <em>Note:
+ the (") prefix isn't displayed.</em></li>
+
+ <li>An external URL to redirect to.</li>
+
+ <li>A local URL to redirect to.</li>
+ </ol>
+ </dd>
+ </dl>
+ <hr />
+
+ <h2>Custom error responses and redirects</h2>
+
+ <dl>
+ <dt>Purpose</dt>
+
+ <dd>Apache's behavior to redirected URLs has been modified so
+ that additional environment variables are available to a
+ script/server-include.</dd>
+
+ <dt>Old behavior</dt>
+
+ <dd>Standard CGI vars were made available to a script which
+ has been redirected to. No indication of where the
+ redirection came from was provided.</dd>
+
+ <dt>New behavior</dt>
+
+ <dd>A new batch of environment variables will be initialized
+ for use by a script which has been redirected to. Each new
+ variable will have the prefix <code>REDIRECT_</code>.
+ <code>REDIRECT_</code> environment variables are created from
+ the CGI environment variables which existed prior to the
+ redirect, they are renamed with a <code>REDIRECT_</code>
+ prefix, <em>i.e.</em>, <code>HTTP_USER_AGENT</code> becomes
+ <code>REDIRECT_HTTP_USER_AGENT</code>. In addition to these
+ new variables, Apache will define <code>REDIRECT_URL</code>
+ and <code>REDIRECT_STATUS</code> to help the script trace its
+ origin. Both the original URL and the URL being redirected to
+ can be logged in the access log.</dd>
+ </dl>
+
+ <p>If the ErrorDocument specifies a local redirect to a CGI
+ script, the script should include a "<samp>Status:</samp>"
+ header field in its output in order to ensure the propagation
+ all the way back to the client of the error condition that
+ caused it to be invoked. For instance, a Perl ErrorDocument
+ script might include the following:</p>
+<pre>
:
print "Content-type: text/html\n";
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
:
-</PRE>
-<P>
-If the script is dedicated to handling a particular error condition, such as
-<SAMP>404 Not Found</SAMP>, it can use the specific code and
-error text instead.
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+
+ <p>If the script is dedicated to handling a particular error
+ condition, such as <samp>404 Not Found</samp>, it can
+ use the specific code and error text instead.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Custom error responses</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Custom error responses</H1>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Additional functionality. Allows webmasters to configure the response of
- Apache to some error or problem.
-
- <P>Customizable responses can be defined to be activated in the
- event of a server detected error or problem.
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Custom error responses</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Custom error responses</h1>
+
+ <dl>
+ <dt>Purpose</dt>
+
+ <dd>
+ Additional functionality. Allows webmasters to configure
+ the response of Apache to some error or problem.
+
+ <p>Customizable responses can be defined to be activated in
+ the event of a server detected error or problem.</p>
+
+ <p>e.g. if a script crashes and produces a "500 Server
+ Error" response, then this response can be replaced with
+ either some friendlier text or by a redirection to another
+ URL (local or external).</p>
+ </dd>
+
+ <dt>Old behavior</dt>
+
+ <dd>NCSA httpd 1.3 would return some boring old error/problem
+ message which would often be meaningless to the user, and
+ would provide no means of logging the symptoms which caused
+ it.<br />
+ </dd>
+
+ <dt>New behavior</dt>
- <P>e.g. if a script crashes and produces a "500 Server Error"
- response, then this response can be replaced with either some
- friendlier text or by a redirection to another URL (local or
- external).
- <P>
+ <dd>
+ The server can be asked to;
-<DT>Old behavior
+ <ol>
+ <li>Display some other text, instead of the NCSA hard
+ coded messages, or</li>
- <DD>NCSA httpd 1.3 would return some boring old error/problem message
- which would often be meaningless to the user, and would provide no
- means of logging the symptoms which caused it.<BR>
-
- <P>
-
-<DT>New behavior
-
- <DD>The server can be asked to;
- <OL>
- <LI>Display some other text, instead of the NCSA hard coded messages, or
- <LI>redirect to a local URL, or
- <LI>redirect to an external URL.
- </OL>
-
- <P>Redirecting to another URL can be useful, but only if some information
- can be passed which can then be used to explain and/or log the
- error/problem
- more clearly.
-
- <P>To achieve this, Apache will define new CGI-like environment
- variables, <EM>e.g.</EM>
-
- <BLOCKQUOTE><CODE>
-REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
-REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712) <BR>
-REDIRECT_PATH=.:/bin:/usr/local/bin:/etc <BR>
-REDIRECT_QUERY_STRING= <BR>
-REDIRECT_REMOTE_ADDR=121.345.78.123 <BR>
-REDIRECT_REMOTE_HOST=ooh.ahhh.com <BR>
-REDIRECT_SERVER_NAME=crash.bang.edu <BR>
-REDIRECT_SERVER_PORT=80 <BR>
-REDIRECT_SERVER_SOFTWARE=Apache/0.8.15 <BR>
-REDIRECT_URL=/cgi-bin/buggy.pl <BR>
- </CODE></BLOCKQUOTE>
-
- <P>note the <CODE>REDIRECT_</CODE> prefix.
-
- <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE>
- will
- be passed to the new URL (assuming it's a cgi-script or a cgi-include).
- The
- other variables will exist only if they existed prior to the
- error/problem.
- <STRONG>None</STRONG> of these will be set if your ErrorDocument is an
- <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a
- scheme name
- like <CODE>http:</CODE>, even if it refers to the same host as the
- server).<P>
-
-<DT>Configuration
-
- <DD> Use of "ErrorDocument" is enabled for .htaccess files when the
- <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is
- allowed.
-
- <P>Here are some examples...
-
- <BLOCKQUOTE><CODE>
-ErrorDocument 500 /cgi-bin/crash-recover <BR>
-ErrorDocument 500 "Sorry, our script crashed. Oh dear<BR>
-ErrorDocument 500 http://xxx/ <BR>
-ErrorDocument 404 /Lame_excuses/not_found.html <BR>
-ErrorDocument 401 /Subscription/how_to_subscribe.html
- </CODE></BLOCKQUOTE>
-
- <P>The syntax is,
-
- <P><CODE><A HREF="mod/core.html#errordocument">ErrorDocument</A></CODE>
-<3-digit-code> action
-
- <P>where the action can be,
-
- <OL>
- <LI>Text to be displayed. Prefix the text with a quote ("). Whatever
- follows the quote is displayed. <EM>Note: the (") prefix isn't
- displayed.</EM>
-
- <LI>An external URL to redirect to.
-
- <LI>A local URL to redirect to.
-
- </OL>
-</DL>
-
-<P><HR><P>
-
-<H2>Custom error responses and redirects</H2>
-
-<DL>
-
-<DT>Purpose
-
- <DD>Apache's behavior to redirected URLs has been modified so that additional
- environment variables are available to a script/server-include.<P>
-
-<DT>Old behavior
-
- <DD>Standard CGI vars were made available to a script which has been
- redirected to. No indication of where the redirection came from was
- provided.
-
- <P>
-
-<DT>New behavior
- <DD>
-
-A new batch of environment variables will be initialized for use by a
-script which has been redirected to. Each new variable will have the
-prefix <CODE>REDIRECT_</CODE>. <CODE>REDIRECT_</CODE> environment
-variables are created from the CGI environment variables which existed
-prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>
-prefix, <EM>i.e.</EM>, <CODE>HTTP_USER_AGENT</CODE> becomes
-<CODE>REDIRECT_HTTP_USER_AGENT</CODE>. In addition to these new
-variables, Apache will define <CODE>REDIRECT_URL</CODE> and
-<CODE>REDIRECT_STATUS</CODE> to help the script trace its origin.
-Both the original URL and the URL being redirected to can be logged in
-the access log.
-
-</DL>
-<P>
-If the ErrorDocument specifies a local redirect to a CGI script, the script
-should include a "<SAMP>Status:</SAMP>" header field in its output
-in order to ensure the propagation all the way back to the client
-of the error condition that caused it to be invoked. For instance, a Perl
-ErrorDocument script might include the following:
-</P>
-<PRE>
+ <li>redirect to a local URL, or</li>
+
+ <li>redirect to an external URL.</li>
+ </ol>
+
+ <p>Redirecting to another URL can be useful, but only if
+ some information can be passed which can then be used to
+ explain and/or log the error/problem more clearly.</p>
+
+ <p>To achieve this, Apache will define new CGI-like
+ environment variables, <em>e.g.</em></p>
+
+ <blockquote>
+ <code>REDIRECT_HTTP_ACCEPT=*/*, image/gif,
+ image/x-xbitmap, image/jpeg<br />
+ REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX
+ A.09.05 9000/712)<br />
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />
+ REDIRECT_QUERY_STRING=<br />
+ REDIRECT_REMOTE_ADDR=121.345.78.123<br />
+ REDIRECT_REMOTE_HOST=ooh.ahhh.com<br />
+ REDIRECT_SERVER_NAME=crash.bang.edu<br />
+ REDIRECT_SERVER_PORT=80<br />
+ REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />
+ REDIRECT_URL=/cgi-bin/buggy.pl<br />
+ </code>
+ </blockquote>
+
+ <p>note the <code>REDIRECT_</code> prefix.</p>
+
+ <p>At least <code>REDIRECT_URL</code> and
+ <code>REDIRECT_QUERY_STRING</code> will be passed to the
+ new URL (assuming it's a cgi-script or a cgi-include). The
+ other variables will exist only if they existed prior to
+ the error/problem. <strong>None</strong> of these will be
+ set if your ErrorDocument is an <em>external</em> redirect
+ (<em>i.e.</em>, anything starting with a scheme name like
+ <code>http:</code>, even if it refers to the same host as
+ the server).</p>
+ </dd>
+
+ <dt>Configuration</dt>
+
+ <dd>
+ Use of "ErrorDocument" is enabled for .htaccess files when
+ the <a href="mod/core.html#allowoverride">"FileInfo"
+ override</a> is allowed.
+
+ <p>Here are some examples...</p>
+
+ <blockquote>
+ <code>ErrorDocument 500 /cgi-bin/crash-recover<br />
+ ErrorDocument 500 "Sorry, our script crashed. Oh
+ dear<br />
+ ErrorDocument 500 http://xxx/<br />
+ ErrorDocument 404 /Lame_excuses/not_found.html<br />
+ ErrorDocument 401
+ /Subscription/how_to_subscribe.html</code>
+ </blockquote>
+
+ <p>The syntax is,</p>
+
+ <p><code><a
+ href="mod/core.html#errordocument">ErrorDocument</a></code>
+ <3-digit-code> action</p>
+
+ <p>where the action can be,</p>
+
+ <ol>
+ <li>Text to be displayed. Prefix the text with a quote
+ ("). Whatever follows the quote is displayed. <em>Note:
+ the (") prefix isn't displayed.</em></li>
+
+ <li>An external URL to redirect to.</li>
+
+ <li>A local URL to redirect to.</li>
+ </ol>
+ </dd>
+ </dl>
+ <hr />
+
+ <h2>Custom error responses and redirects</h2>
+
+ <dl>
+ <dt>Purpose</dt>
+
+ <dd>Apache's behavior to redirected URLs has been modified so
+ that additional environment variables are available to a
+ script/server-include.</dd>
+
+ <dt>Old behavior</dt>
+
+ <dd>Standard CGI vars were made available to a script which
+ has been redirected to. No indication of where the
+ redirection came from was provided.</dd>
+
+ <dt>New behavior</dt>
+
+ <dd>A new batch of environment variables will be initialized
+ for use by a script which has been redirected to. Each new
+ variable will have the prefix <code>REDIRECT_</code>.
+ <code>REDIRECT_</code> environment variables are created from
+ the CGI environment variables which existed prior to the
+ redirect, they are renamed with a <code>REDIRECT_</code>
+ prefix, <em>i.e.</em>, <code>HTTP_USER_AGENT</code> becomes
+ <code>REDIRECT_HTTP_USER_AGENT</code>. In addition to these
+ new variables, Apache will define <code>REDIRECT_URL</code>
+ and <code>REDIRECT_STATUS</code> to help the script trace its
+ origin. Both the original URL and the URL being redirected to
+ can be logged in the access log.</dd>
+ </dl>
+
+ <p>If the ErrorDocument specifies a local redirect to a CGI
+ script, the script should include a "<samp>Status:</samp>"
+ header field in its output in order to ensure the propagation
+ all the way back to the client of the error condition that
+ caused it to be invoked. For instance, a Perl ErrorDocument
+ script might include the following:</p>
+<pre>
:
print "Content-type: text/html\n";
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
:
-</PRE>
-<P>
-If the script is dedicated to handling a particular error condition, such as
-<SAMP>404 Not Found</SAMP>, it can use the specific code and
-error text instead.
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+
+ <p>If the script is dedicated to handling a particular error
+ condition, such as <samp>404 Not Found</samp>, it can
+ use the specific code and error text instead.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Issues Regarding DNS and Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Issues Regarding DNS and Apache</H1>
-
-<P>This page could be summarized with the statement: <EM>don't require
-Apache to use DNS for any parsing of the configuration files</EM>.
-If Apache has to use DNS to parse the configuration files then your
-server may be subject to reliability problems (it might not boot), or
-denial and theft of service attacks (including users able to steal hits
-from other users).
-
-<H3>A Simple Example</H3>
-
-Consider this configuration snippet:
-
-<BLOCKQUOTE><PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Issues Regarding DNS and Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Issues Regarding DNS and Apache</h1>
+
+ <p>This page could be summarized with the statement: <em>don't
+ require Apache to use DNS for any parsing of the configuration
+ files</em>. If Apache has to use DNS to parse the configuration
+ files then your server may be subject to reliability problems
+ (it might not boot), or denial and theft of service attacks
+ (including users able to steal hits from other users).</p>
+
+ <h3>A Simple Example</h3>
+ Consider this configuration snippet:
+
+ <blockquote>
+<pre>
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</PRE></BLOCKQUOTE>
-
-<P>In order for Apache to function properly it absolutely needs
-to have two pieces of information about each virtual host: the
-<A HREF="mod/core.html#servername"><CODE>ServerName</CODE></A>
-and at least one IP address that the server
-responds to. This example does not include the IP address, so Apache
-must use DNS to find the address of <CODE>www.abc.dom</CODE>. If for
-some reason DNS is not available at the time your server is parsing its
-config file, then this virtual host <STRONG>will not be configured</STRONG>. It
-won't be able to respond to any hits to this virtual host (prior to
-Apache version 1.2 the server would not even boot).
-
-<P>Suppose that <CODE>www.abc.dom</CODE> has address 10.0.0.1. Then
-consider this configuration snippet:
-
-<BLOCKQUOTE><PRE>
+</pre>
+ </blockquote>
+
+ <p>In order for Apache to function properly it absolutely needs
+ to have two pieces of information about each virtual host: the
+ <a href="mod/core.html#servername"><code>ServerName</code></a>
+ and at least one IP address that the server responds to. This
+ example does not include the IP address, so Apache must use DNS
+ to find the address of <code>www.abc.dom</code>. If for some
+ reason DNS is not available at the time your server is parsing
+ its config file, then this virtual host <strong>will not be
+ configured</strong>. It won't be able to respond to any hits to
+ this virtual host (prior to Apache version 1.2 the server would
+ not even boot).</p>
+
+ <p>Suppose that <code>www.abc.dom</code> has address 10.0.0.1.
+ Then consider this configuration snippet:</p>
+
+ <blockquote>
+<pre>
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</PRE></BLOCKQUOTE>
-
-<P>Now Apache needs to use reverse DNS to find the <CODE>ServerName</CODE>
-for this virtualhost. If that reverse lookup fails then it will partially
-disable the virtualhost (prior to Apache version 1.2 the server would not
-even boot). If the virtual host is name-based then it will effectively
-be totally disabled, but if it is IP-based then it will mostly work.
-However if Apache should ever have to generate a full URL for the server
-which includes the server name then it will fail to generate a valid URL.
-
-<P>Here is a snippet that avoids both of these problems.
-
-<BLOCKQUOTE><PRE>
+</pre>
+ </blockquote>
+
+ <p>Now Apache needs to use reverse DNS to find the
+ <code>ServerName</code> for this virtualhost. If that reverse
+ lookup fails then it will partially disable the virtualhost
+ (prior to Apache version 1.2 the server would not even boot).
+ If the virtual host is name-based then it will effectively be
+ totally disabled, but if it is IP-based then it will mostly
+ work. However if Apache should ever have to generate a full URL
+ for the server which includes the server name then it will fail
+ to generate a valid URL.</p>
+
+ <p>Here is a snippet that avoids both of these problems.</p>
+
+ <blockquote>
+<pre>
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</PRE></BLOCKQUOTE>
-
-<H3>Denial of Service</H3>
-
-<P>There are (at least) two forms that denial of service can come in.
-If you are running a version of Apache prior to version 1.2 then your
-server will not even boot if one of the two DNS lookups mentioned above
-fails for any of your virtual hosts. In some cases this DNS lookup may
-not even be under your control. For example, if <CODE>abc.dom</CODE>
-is one of your customers and they control their own DNS then they
-can force your (pre-1.2) server to fail while booting simply by deleting the
-<CODE>www.abc.dom</CODE> record.
-
-<P>Another form is far more insidious. Consider this configuration
-snippet:
-
-<BLOCKQUOTE><PRE>
+</pre>
+ </blockquote>
+
+ <h3>Denial of Service</h3>
+
+ <p>There are (at least) two forms that denial of service can
+ come in. If you are running a version of Apache prior to
+ version 1.2 then your server will not even boot if one of the
+ two DNS lookups mentioned above fails for any of your virtual
+ hosts. In some cases this DNS lookup may not even be under your
+ control. For example, if <code>abc.dom</code> is one of your
+ customers and they control their own DNS then they can force
+ your (pre-1.2) server to fail while booting simply by deleting
+ the <code>www.abc.dom</code> record.</p>
+
+ <p>Another form is far more insidious. Consider this
+ configuration snippet:</p>
+
+ <blockquote>
+<pre>
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</PRE></BLOCKQUOTE>
+</pre>
+ </blockquote>
-<BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>
-</PRE></BLOCKQUOTE>
-
-<P>Suppose that you've assigned 10.0.0.1 to <CODE>www.abc.dom</CODE> and
-10.0.0.2 to <CODE>www.def.dom</CODE>. Furthermore, suppose that
-<CODE>def.com</CODE> has control of their own DNS. With this config
-you have put <CODE>def.com</CODE> into a position where they can steal
-all traffic destined to <CODE>abc.com</CODE>. To do so, all they have to
-do is set <CODE>www.def.dom</CODE> to 10.0.0.1.
-Since they control their own DNS you can't stop them from pointing the
-<CODE>www.def.com</CODE> record wherever they wish.
-
-<P>Requests coming in to 10.0.0.1 (including all those where users typed
-in URLs of the form <CODE>http://www.abc.dom/whatever</CODE>) will all be
-served by the <CODE>def.com</CODE> virtual host. To better understand why
-this happens requires a more in-depth discussion of how Apache matches
-up incoming requests with the virtual host that will serve it. A rough
-document describing this <A HREF="vhosts/details.html"> is available</A>.
-
-<H3>The "main server" Address</H3>
-
-<P>The addition of <A HREF="vhosts/name-based.html">name-based virtual host
-support</A> in Apache 1.1 requires Apache to know the IP address(es) of
-the host that httpd is running on. To get this address it uses either
-the global <CODE>ServerName</CODE> (if present) or calls the C function
-<CODE>gethostname</CODE> (which should return the same as typing
-"hostname" at the command prompt). Then it performs a DNS lookup on
-this address. At present there is no way to avoid this lookup.
-
-<P>If you fear that this lookup might fail because your DNS server is down
-then you can insert the hostname in <CODE>/etc/hosts</CODE> (where you
-probably already have it so that the machine can boot properly). Then
-ensure that your machine is configured to use <CODE>/etc/hosts</CODE>
-in the event that DNS fails. Depending on what OS you are using this
-might be accomplished by editing <CODE>/etc/resolv.conf</CODE>, or maybe
-<CODE>/etc/nsswitch.conf</CODE>.
-
-<P>If your server doesn't have to perform DNS for any other reason
-then you might be able to get away with running Apache with the
-<CODE>HOSTRESORDER</CODE> environment variable set to "local". This all
-depends on what OS and resolver libraries you are using. It also affects
-CGIs unless you use <A HREF="mod/mod_env.html"><CODE>mod_env</CODE></A>
-to control the environment. It's best to consult the man pages or FAQs
-for your OS.
-
-<H3><A NAME="tips">Tips to Avoid these problems</A></H3>
-
-<UL>
-<LI> use IP addresses in <CODE><VirtualHost></CODE>
-<LI> use IP addresses in <CODE>Listen</CODE>
-<LI> use IP addresses in <CODE>BindAddress</CODE>
-<LI> ensure all virtual hosts have an explicit <CODE>ServerName</CODE>
-<LI> create a <CODE><VirtualHost _default_:*></CODE> server that
- has no pages to serve
-</UL>
-
-<H3>Appendix: Future Directions</H3>
-
-<P>The situation regarding DNS is highly undesirable. For Apache
-1.2 we've attempted to make the server at least continue booting
-in the event of failed DNS, but it might not be the best we
-can do. In any event requiring the use of explicit IP addresses in
-configuration files is highly undesirable in today's Internet where
-renumbering is a necessity.
-
-<P>A possible work around to the theft of service attack described above
-would be to perform a reverse DNS lookup on the ip address returned by
-the forward lookup and compare the two names. In the event of a mismatch
-the virtualhost would be disabled. This would require reverse DNS to be
-configured properly (which is something that most admins are familiar with
-because of the common use of "double-reverse" DNS lookups by FTP servers
-and TCP wrappers).
-
-<P>In any event it doesn't seem possible to reliably boot a virtual-hosted
-web server when DNS has failed unless IP addresses are used. Partial
-solutions such as disabling portions of the configuration might be worse
-than not booting at all depending on what the webserver is supposed
-to accomplish.
-
-<P>As HTTP/1.1 is deployed and browsers and proxies start issuing the
-<CODE>Host</CODE> header it will become possible to avoid the use of
-IP-based virtual hosts entirely. In this event a webserver has no requirement
-to do DNS lookups during configuration. But as of March 1997 these
-features have not been deployed widely enough to be put into use on
-critical webservers.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ </blockquote>
+
+ <p>Suppose that you've assigned 10.0.0.1 to
+ <code>www.abc.dom</code> and 10.0.0.2 to
+ <code>www.def.dom</code>. Furthermore, suppose that
+ <code>def.com</code> has control of their own DNS. With this
+ config you have put <code>def.com</code> into a position where
+ they can steal all traffic destined to <code>abc.com</code>. To
+ do so, all they have to do is set <code>www.def.dom</code> to
+ 10.0.0.1. Since they control their own DNS you can't stop them
+ from pointing the <code>www.def.com</code> record wherever they
+ wish.</p>
+
+ <p>Requests coming in to 10.0.0.1 (including all those where
+ users typed in URLs of the form
+ <code>http://www.abc.dom/whatever</code>) will all be served by
+ the <code>def.com</code> virtual host. To better understand why
+ this happens requires a more in-depth discussion of how Apache
+ matches up incoming requests with the virtual host that will
+ serve it. A rough document describing this <a
+ href="vhosts/details.html">is available</a>.</p>
+
+ <h3>The "main server" Address</h3>
+
+ <p>The addition of <a href="vhosts/name-based.html">name-based
+ virtual host support</a> in Apache 1.1 requires Apache to know
+ the IP address(es) of the host that httpd is running on. To get
+ this address it uses either the global <code>ServerName</code>
+ (if present) or calls the C function <code>gethostname</code>
+ (which should return the same as typing "hostname" at the
+ command prompt). Then it performs a DNS lookup on this address.
+ At present there is no way to avoid this lookup.</p>
+
+ <p>If you fear that this lookup might fail because your DNS
+ server is down then you can insert the hostname in
+ <code>/etc/hosts</code> (where you probably already have it so
+ that the machine can boot properly). Then ensure that your
+ machine is configured to use <code>/etc/hosts</code> in the
+ event that DNS fails. Depending on what OS you are using this
+ might be accomplished by editing <code>/etc/resolv.conf</code>,
+ or maybe <code>/etc/nsswitch.conf</code>.</p>
+
+ <p>If your server doesn't have to perform DNS for any other
+ reason then you might be able to get away with running Apache
+ with the <code>HOSTRESORDER</code> environment variable set to
+ "local". This all depends on what OS and resolver libraries you
+ are using. It also affects CGIs unless you use <a
+ href="mod/mod_env.html"><code>mod_env</code></a> to control the
+ environment. It's best to consult the man pages or FAQs for
+ your OS.</p>
+
+ <h3><a id="tips" name="tips">Tips to Avoid these
+ problems</a></h3>
+
+ <ul>
+ <li>use IP addresses in <code><VirtualHost></code></li>
+
+ <li>use IP addresses in <code>Listen</code></li>
+
+ <li>use IP addresses in <code>BindAddress</code></li>
+
+ <li>ensure all virtual hosts have an explicit
+ <code>ServerName</code></li>
+
+ <li>create a <code><VirtualHost _default_:*></code>
+ server that has no pages to serve</li>
+ </ul>
+
+ <h3>Appendix: Future Directions</h3>
+
+ <p>The situation regarding DNS is highly undesirable. For
+ Apache 1.2 we've attempted to make the server at least continue
+ booting in the event of failed DNS, but it might not be the
+ best we can do. In any event requiring the use of explicit IP
+ addresses in configuration files is highly undesirable in
+ today's Internet where renumbering is a necessity.</p>
+
+ <p>A possible work around to the theft of service attack
+ described above would be to perform a reverse DNS lookup on the
+ ip address returned by the forward lookup and compare the two
+ names. In the event of a mismatch the virtualhost would be
+ disabled. This would require reverse DNS to be configured
+ properly (which is something that most admins are familiar with
+ because of the common use of "double-reverse" DNS lookups by
+ FTP servers and TCP wrappers).</p>
+
+ <p>In any event it doesn't seem possible to reliably boot a
+ virtual-hosted web server when DNS has failed unless IP
+ addresses are used. Partial solutions such as disabling
+ portions of the configuration might be worse than not booting
+ at all depending on what the webserver is supposed to
+ accomplish.</p>
+
+ <p>As HTTP/1.1 is deployed and browsers and proxies start
+ issuing the <code>Host</code> header it will become possible to
+ avoid the use of IP-based virtual hosts entirely. In this event
+ a webserver has no requirement to do DNS lookups during
+ configuration. But as of March 1997 these features have not
+ been deployed widely enough to be put into use on critical
+ webservers. <!--#include virtual="footer.html" -->
+ </p>
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Dynamic Shared Object (DSO) support</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 align="center">
-Dynamic Shared Object (DSO) Support
-</H1>
-
-<p>The Apache HTTP Server is a modular program where the administrator
-can choose the functionality to include in the server by selecting a
-set of modules. The modules can be statically compiled into the
-<code>httpd</code> binary when the server is built. Alternatively,
-modules can be compiled as Dynamic Shared Objects (DSOs) that exist
-separately from the main <code>httpd</code> binary file. DSO modules
-may be compiled at the time the server is built, or they may be
-compiled and added at a later time using the Apache Extension Tool (<a
-href="programs/apxs.html">apxs</a>).</p>
-
-<p>This document describes how to use DSO modules as well as the theory
-behind their use.</p>
-
-<ul>
-<li><a href="#implementation">Implementation</a></li>
-<li><a href="#usage">Usage Summary</a></li>
-<li><a href="#background">Background</a></li>
-<li><a href="#advantages">Advantages and Disadvantages</a></li>
-</ul>
-
-<hr>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_so.html">mod_so</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_so.html#loadmodule">LoadModule</A><br>
-
-</td></tr></table>
-
-<H2><a name="implementation">Implementation</a></H2>
-
-<P>The DSO support for loading individual Apache modules is based on a
-module named <A HREF="mod/mod_so.html"><CODE>mod_so.c</CODE></A> which
-must be statically compiled into the Apache core. It is the only
-module besides <CODE>core.c</CODE> which cannot be put into a DSO
-itself. Practically all other distributed Apache modules then can
-then be placed into a DSO by individually enabling the DSO build for
-them via <CODE>configure</CODE>'s
-<CODE>--enable-<i>module</i>=shared</CODE> option as disucussed in the
-<a href="install.html">install documentation</a>. After a module is
-compiled into a DSO named <CODE>mod_foo.so</CODE> you can use <A
-HREF="mod/mod_so.html"><CODE>mod_so</CODE></A>'s <A
-HREF="mod/mod_so.html#loadmodule"><CODE>LoadModule</CODE></A> command
-in your <CODE>httpd.conf</CODE> file to load this module at server
-startup or restart.
-
-<P>To simplify this creation of DSO files for Apache modules
-(especially for third-party modules) a new support program named <a
-href="programs/apxs.html">apxs</a> (<EM>APache eXtenSion</EM>) is
-available. It can be used to build DSO based modules <EM>outside
-of</EM> the Apache source tree. The idea is simple: When installing
-Apache the <CODE>configure</CODE>'s <CODE>make install</CODE>
-procedure installs the Apache C header files and puts the
-platform-dependent compiler and linker flags for building DSO files
-into the <CODE>apxs</CODE> program. This way the user can use
-<CODE>apxs</CODE> to compile his Apache module sources without the
-Apache distribution source tree and without having to fiddle with the
-platform-dependent compiler and linker flags for DSO support.
-
-<H2><a name="usage">Usage Summary</a></H2>
-
-<P>To give you an overview of the DSO features of Apache 2.0, here is a short
-and concise summary:
-
-<OL>
-
-<LI>Build and install a <EM>distributed</EM> Apache module, say
-<CODE>mod_foo.c</CODE>, into its own DSO <CODE>mod_foo.so</CODE>:
-
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Dynamic Shared Object (DSO) support</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Dynamic Shared Object (DSO) Support</h1>
+
+ <p>The Apache HTTP Server is a modular program where the
+ administrator can choose the functionality to include in the
+ server by selecting a set of modules. The modules can be
+ statically compiled into the <code>httpd</code> binary when the
+ server is built. Alternatively, modules can be compiled as
+ Dynamic Shared Objects (DSOs) that exist separately from the
+ main <code>httpd</code> binary file. DSO modules may be
+ compiled at the time the server is built, or they may be
+ compiled and added at a later time using the Apache Extension
+ Tool (<a href="programs/apxs.html">apxs</a>).</p>
+
+ <p>This document describes how to use DSO modules as well as
+ the theory behind their use.</p>
+
+ <ul>
+ <li><a href="#implementation">Implementation</a></li>
+
+ <li><a href="#usage">Usage Summary</a></li>
+
+ <li><a href="#background">Background</a></li>
+
+ <li><a href="#advantages">Advantages and
+ Disadvantages</a></li>
+ </ul>
+ <hr />
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_so.html">mod_so</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_so.html#loadmodule">LoadModule</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h2><a id="implementation"
+ name="implementation">Implementation</a></h2>
+
+ <p>The DSO support for loading individual Apache modules is
+ based on a module named <a
+ href="mod/mod_so.html"><code>mod_so.c</code></a> which must be
+ statically compiled into the Apache core. It is the only module
+ besides <code>core.c</code> which cannot be put into a DSO
+ itself. Practically all other distributed Apache modules then
+ can then be placed into a DSO by individually enabling the DSO
+ build for them via <code>configure</code>'s
+ <code>--enable-<i>module</i>=shared</code> option as disucussed
+ in the <a href="install.html">install documentation</a>. After
+ a module is compiled into a DSO named <code>mod_foo.so</code>
+ you can use <a href="mod/mod_so.html"><code>mod_so</code></a>'s
+ <a
+ href="mod/mod_so.html#loadmodule"><code>LoadModule</code></a>
+ command in your <code>httpd.conf</code> file to load this
+ module at server startup or restart.</p>
+
+ <p>To simplify this creation of DSO files for Apache modules
+ (especially for third-party modules) a new support program
+ named <a href="programs/apxs.html">apxs</a> (<em>APache
+ eXtenSion</em>) is available. It can be used to build DSO based
+ modules <em>outside of</em> the Apache source tree. The idea is
+ simple: When installing Apache the <code>configure</code>'s
+ <code>make install</code> procedure installs the Apache C
+ header files and puts the platform-dependent compiler and
+ linker flags for building DSO files into the <code>apxs</code>
+ program. This way the user can use <code>apxs</code> to compile
+ his Apache module sources without the Apache distribution
+ source tree and without having to fiddle with the
+ platform-dependent compiler and linker flags for DSO
+ support.</p>
+
+ <h2><a id="usage" name="usage">Usage Summary</a></h2>
+
+ <p>To give you an overview of the DSO features of Apache 2.0,
+ here is a short and concise summary:</p>
+
+ <ol>
+ <li>
+ Build and install a <em>distributed</em> Apache module, say
+ <code>mod_foo.c</code>, into its own DSO
+ <code>mod_foo.so</code>:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ ./configure --prefix=/path/to/install
--enable-foo=shared
$ make install
-</PRE>
-</TD></TR></TABLE>
-
-<LI>Build and install a <EM>third-party</EM> Apache module, say
-<CODE>mod_foo.c</CODE>, into its own DSO <CODE>mod_foo.so</CODE>:
-
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+
+ <li>
+ Build and install a <em>third-party</em> Apache module, say
+ <code>mod_foo.c</code>, into its own DSO
+ <code>mod_foo.so</code>:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c
--enable-foo=shared
$ make install
-</PRE>
-</TD></TR></TABLE>
-
-<LI>Configure Apache for <EM>later installation</EM> of shared modules:
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+
+ <li>
+ Configure Apache for <em>later installation</em> of shared
+ modules:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ ./configure --enable-so
$ make install
-</PRE>
-</TD></TR></TABLE>
-
-<LI>Build and install a <EM>third-party</EM> Apache module, say
-<CODE>mod_foo.c</CODE>, into its own DSO <CODE>mod_foo.so</CODE> <EM>outside
-of</EM> the Apache source tree using <a href="programs/apxs.html">apxs</a>:
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+
+ <li>
+ Build and install a <em>third-party</em> Apache module, say
+ <code>mod_foo.c</code>, into its own DSO
+ <code>mod_foo.so</code> <em>outside of</em> the Apache
+ source tree using <a href="programs/apxs.html">apxs</a>:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.so
-</PRE>
-</TD></TR></TABLE>
-
-</OL>
-
-<p>In all cases, once the shared module is compiled, you must use a <A
-HREF="mod/mod_so.html#loadmodule"><CODE>LoadModule</CODE></A> directive
-in <code>httpd.conf</code> to tell Apache to activate the module.
-
-
-
-<H2><a name="background">Background</a></H2>
-
-<P>On modern Unix derivatives there exists a nifty mechanism usually called
-dynamic linking/loading of <EM>Dynamic Shared Objects</EM> (DSO) which
-provides a way to build a piece of program code in a special format for
-loading it at run-time into the address space of an executable program.
-
-<P>This loading can usually be done in two ways: Automatically by a system
-program called <CODE>ld.so</CODE> when an executable program is started or
-manually from within the executing program via a programmatic system interface
-to the Unix loader through the system calls <CODE>dlopen()/dlsym()</CODE>.
-
-<P>In the first way the DSO's are usually called <EM>shared libraries</EM> or
-<EM>DSO libraries</EM> and named <CODE>libfoo.so</CODE> or
-<CODE>libfoo.so.1.2</CODE>. They reside in a system directory (usually
-<CODE>/usr/lib</CODE>) and the link to the executable program is established
-at build-time by specifying <CODE>-lfoo</CODE> to the linker command. This
-hard-codes library references into the executable program file so that at
-start-time the Unix loader is able to locate <CODE>libfoo.so</CODE> in
-<CODE>/usr/lib</CODE>, in paths hard-coded via linker-options like
-<CODE>-R</CODE> or in paths configured via the environment variable
-<CODE>LD_LIBRARY_PATH</CODE>. It then resolves any (yet unresolved) symbols in
-the executable program which are available in the DSO.
-
-<P>Symbols in the executable program are usually not referenced by the DSO
-(because it's a reusable library of general code) and hence no further
-resolving has to be done. The executable program has no need to do anything on
-its own to use the symbols from the DSO because the complete resolving is done
-by the Unix loader. (In fact, the code to invoke <CODE>ld.so</CODE> is part of
-the run-time startup code which is linked into every executable program which
-has been bound non-static). The advantage of dynamic loading of common library
-code is obvious: the library code needs to be stored only once, in a system
-library like <CODE>libc.so</CODE>, saving disk space for every program.
-
-<P>In the second way the DSO's are usually called <EM>shared objects</EM> or
-<EM>DSO files</EM> and can be named with an arbitrary extension (although the
-canonical name is <CODE>foo.so</CODE>). These files usually stay inside a
-program-specific directory and there is no automatically established link to
-the executable program where they are used. Instead the executable program
-manually loads the DSO at run-time into its address space via
-<CODE>dlopen()</CODE>. At this time no resolving of symbols from the DSO for
-the executable program is done. But instead the Unix loader automatically
-resolves any (yet unresolved) symbols in the DSO from the set of symbols
-exported by the executable program and its already loaded DSO libraries
-(especially all symbols from the ubiquitous <CODE>libc.so</CODE>). This way
-the DSO gets knowledge of the executable program's symbol set as if it had
-been statically linked with it in the first place.
-
-<P>Finally, to take advantage of the DSO's API the executable program has to
-resolve particular symbols from the DSO via <CODE>dlsym()</CODE> for later use
-inside dispatch tables <EM>etc.</EM> In other words: The executable program has to
-manually resolve every symbol it needs to be able to use it. The advantage of
-such a mechanism is that optional program parts need not be loaded (and thus
-do not spend memory) until they are needed by the program in question. When
-required, these program parts can be loaded dynamically to extend the base
-program's functionality.
-
-<P>Although this DSO mechanism sounds straightforward there is at least one
-difficult step here: The resolving of symbols from the executable program for
-the DSO when using a DSO to extend a program (the second way). Why? Because
-"reverse resolving" DSO symbols from the executable program's symbol set is
-against the library design (where the library has no knowledge about the
-programs it is used by) and is neither available under all platforms nor
-standardized. In practice the executable program's global symbols are often
-not re-exported and thus not available for use in a DSO. Finding a way to
-force the linker to export all global symbols is the main problem one has to
-solve when using DSO for extending a program at run-time.
-
-<P>The shared library approach is the typical one, because it is what the DSO
-mechanism was designed for, hence it is used for nearly all types of libraries
-the operating system provides. On the other hand using shared objects for
-extending a program is not used by a lot of programs.
-
-<P>As of 1998 there are only a few software packages available which use the
-DSO mechanism to actually extend their functionality at run-time: Perl 5 (via
-its XS mechanism and the DynaLoader module), Netscape Server, <EM>etc.</EM> Starting
-with version 1.3, Apache joined the crew, because Apache already uses a module
-concept to extend its functionality and internally uses a dispatch-list-based
-approach to link external modules into the Apache core functionality. So,
-Apache is really predestined for using DSO to load its modules at run-time.
-
-
-<H2><a name="advantages">Advantages and Disadvantages</a></H2>
-
-<P>The above DSO based features have the following advantages:
-
-<UL>
-<LI> The server package is more flexible at run-time because the actual server
- process can be assembled at run-time via <A
- HREF="mod/mod_so.html#loadmodule"><CODE>LoadModule</CODE></A>
- <CODE>httpd.conf</CODE> configuration commands instead of
- <CODE>configure</CODE> options at build-time.
- For instance this way one is able to run different server instances
- (standard & SSL version, minimalistic & powered up version
- [mod_perl, PHP3], <EM>etc.</EM>) with only one Apache installation.
-<P>
-<LI> The server package can be easily extended with third-party modules even
- after installation. This is at least a great benefit for vendor package
- maintainers who can create a Apache core package and additional packages
- containing extensions like PHP3, mod_perl, mod_fastcgi, <EM>etc.</EM>
-<P>
-<LI> Easier Apache module prototyping because with the DSO/<CODE>apxs</CODE>
- pair you can both work outside the Apache source tree and only need an
- <CODE>apxs -i</CODE> command followed by an <CODE>apachectl
- restart</CODE> to bring a new version of your currently developed module
- into the running Apache server.
-</UL>
-
-<P>DSO has the following disadvantages:
-
-<UL>
-<LI> The DSO mechanism cannot be used on every platform because not all
- operating systems support dynamic loading of code into the address space
- of a program.
-<P>
-<LI> The server is approximately 20% slower at startup time because of the
- symbol resolving overhead the Unix loader now has to do.
-<P>
-<LI> The server is approximately 5% slower at execution time under some
- platforms because position independent code (PIC) sometimes needs
- complicated assembler tricks for relative addressing which are not
- necessarily as fast as absolute addressing.
-<P>
-<LI> Because DSO modules cannot be linked against other DSO-based libraries
- (<CODE>ld -lfoo</CODE>) on all platforms (for instance a.out-based
- platforms usually don't provide this functionality while ELF-based
- platforms do) you cannot use the DSO mechanism for all types of modules.
- Or in other words, modules compiled as DSO files are restricted to only
- use symbols from the Apache core, from the C library (<CODE>libc</CODE>)
- and all other dynamic or static libraries used by the Apache core, or
- from static library archives (<CODE>libfoo.a</CODE>) containing position
- independent code. The only chances to use other code is to either make
- sure the Apache core itself already contains a reference to it or loading
- the code yourself via <CODE>dlopen()</CODE>.
-<P>
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+ </ol>
+
+ <p>In all cases, once the shared module is compiled, you must
+ use a <a
+ href="mod/mod_so.html#loadmodule"><code>LoadModule</code></a>
+ directive in <code>httpd.conf</code> to tell Apache to activate
+ the module.</p>
+
+ <h2><a id="background" name="background">Background</a></h2>
+
+ <p>On modern Unix derivatives there exists a nifty mechanism
+ usually called dynamic linking/loading of <em>Dynamic Shared
+ Objects</em> (DSO) which provides a way to build a piece of
+ program code in a special format for loading it at run-time
+ into the address space of an executable program.</p>
+
+ <p>This loading can usually be done in two ways: Automatically
+ by a system program called <code>ld.so</code> when an
+ executable program is started or manually from within the
+ executing program via a programmatic system interface to the
+ Unix loader through the system calls
+ <code>dlopen()/dlsym()</code>.</p>
+
+ <p>In the first way the DSO's are usually called <em>shared
+ libraries</em> or <em>DSO libraries</em> and named
+ <code>libfoo.so</code> or <code>libfoo.so.1.2</code>. They
+ reside in a system directory (usually <code>/usr/lib</code>)
+ and the link to the executable program is established at
+ build-time by specifying <code>-lfoo</code> to the linker
+ command. This hard-codes library references into the executable
+ program file so that at start-time the Unix loader is able to
+ locate <code>libfoo.so</code> in <code>/usr/lib</code>, in
+ paths hard-coded via linker-options like <code>-R</code> or in
+ paths configured via the environment variable
+ <code>LD_LIBRARY_PATH</code>. It then resolves any (yet
+ unresolved) symbols in the executable program which are
+ available in the DSO.</p>
+
+ <p>Symbols in the executable program are usually not referenced
+ by the DSO (because it's a reusable library of general code)
+ and hence no further resolving has to be done. The executable
+ program has no need to do anything on its own to use the
+ symbols from the DSO because the complete resolving is done by
+ the Unix loader. (In fact, the code to invoke
+ <code>ld.so</code> is part of the run-time startup code which
+ is linked into every executable program which has been bound
+ non-static). The advantage of dynamic loading of common library
+ code is obvious: the library code needs to be stored only once,
+ in a system library like <code>libc.so</code>, saving disk
+ space for every program.</p>
+
+ <p>In the second way the DSO's are usually called <em>shared
+ objects</em> or <em>DSO files</em> and can be named with an
+ arbitrary extension (although the canonical name is
+ <code>foo.so</code>). These files usually stay inside a
+ program-specific directory and there is no automatically
+ established link to the executable program where they are used.
+ Instead the executable program manually loads the DSO at
+ run-time into its address space via <code>dlopen()</code>. At
+ this time no resolving of symbols from the DSO for the
+ executable program is done. But instead the Unix loader
+ automatically resolves any (yet unresolved) symbols in the DSO
+ from the set of symbols exported by the executable program and
+ its already loaded DSO libraries (especially all symbols from
+ the ubiquitous <code>libc.so</code>). This way the DSO gets
+ knowledge of the executable program's symbol set as if it had
+ been statically linked with it in the first place.</p>
+
+ <p>Finally, to take advantage of the DSO's API the executable
+ program has to resolve particular symbols from the DSO via
+ <code>dlsym()</code> for later use inside dispatch tables
+ <em>etc.</em> In other words: The executable program has to
+ manually resolve every symbol it needs to be able to use it.
+ The advantage of such a mechanism is that optional program
+ parts need not be loaded (and thus do not spend memory) until
+ they are needed by the program in question. When required,
+ these program parts can be loaded dynamically to extend the
+ base program's functionality.</p>
+
+ <p>Although this DSO mechanism sounds straightforward there is
+ at least one difficult step here: The resolving of symbols from
+ the executable program for the DSO when using a DSO to extend a
+ program (the second way). Why? Because "reverse resolving" DSO
+ symbols from the executable program's symbol set is against the
+ library design (where the library has no knowledge about the
+ programs it is used by) and is neither available under all
+ platforms nor standardized. In practice the executable
+ program's global symbols are often not re-exported and thus not
+ available for use in a DSO. Finding a way to force the linker
+ to export all global symbols is the main problem one has to
+ solve when using DSO for extending a program at run-time.</p>
+
+ <p>The shared library approach is the typical one, because it
+ is what the DSO mechanism was designed for, hence it is used
+ for nearly all types of libraries the operating system
+ provides. On the other hand using shared objects for extending
+ a program is not used by a lot of programs.</p>
+
+ <p>As of 1998 there are only a few software packages available
+ which use the DSO mechanism to actually extend their
+ functionality at run-time: Perl 5 (via its XS mechanism and the
+ DynaLoader module), Netscape Server, <em>etc.</em> Starting
+ with version 1.3, Apache joined the crew, because Apache
+ already uses a module concept to extend its functionality and
+ internally uses a dispatch-list-based approach to link external
+ modules into the Apache core functionality. So, Apache is
+ really predestined for using DSO to load its modules at
+ run-time.</p>
+
+ <h2><a id="advantages" name="advantages">Advantages and
+ Disadvantages</a></h2>
+
+ <p>The above DSO based features have the following
+ advantages:</p>
+
+ <ul>
+ <li>The server package is more flexible at run-time because
+ the actual server process can be assembled at run-time via <a
+ href="mod/mod_so.html#loadmodule"><code>LoadModule</code></a>
+ <code>httpd.conf</code> configuration commands instead of
+ <code>configure</code> options at build-time. For instance
+ this way one is able to run different server instances
+ (standard & SSL version, minimalistic & powered up
+ version [mod_perl, PHP3], <em>etc.</em>) with only one Apache
+ installation.</li>
+
+ <li>The server package can be easily extended with
+ third-party modules even after installation. This is at least
+ a great benefit for vendor package maintainers who can create
+ a Apache core package and additional packages containing
+ extensions like PHP3, mod_perl, mod_fastcgi,
+ <em>etc.</em></li>
+
+ <li>Easier Apache module prototyping because with the
+ DSO/<code>apxs</code> pair you can both work outside the
+ Apache source tree and only need an <code>apxs -i</code>
+ command followed by an <code>apachectl restart</code> to
+ bring a new version of your currently developed module into
+ the running Apache server.</li>
+ </ul>
+
+ <p>DSO has the following disadvantages:</p>
+
+ <ul>
+ <li>The DSO mechanism cannot be used on every platform
+ because not all operating systems support dynamic loading of
+ code into the address space of a program.</li>
+
+ <li>The server is approximately 20% slower at startup time
+ because of the symbol resolving overhead the Unix loader now
+ has to do.</li>
+
+ <li>The server is approximately 5% slower at execution time
+ under some platforms because position independent code (PIC)
+ sometimes needs complicated assembler tricks for relative
+ addressing which are not necessarily as fast as absolute
+ addressing.</li>
+
+ <li>Because DSO modules cannot be linked against other
+ DSO-based libraries (<code>ld -lfoo</code>) on all platforms
+ (for instance a.out-based platforms usually don't provide
+ this functionality while ELF-based platforms do) you cannot
+ use the DSO mechanism for all types of modules. Or in other
+ words, modules compiled as DSO files are restricted to only
+ use symbols from the Apache core, from the C library
+ (<code>libc</code>) and all other dynamic or static libraries
+ used by the Apache core, or from static library archives
+ (<code>libfoo.a</code>) containing position independent code.
+ The only chances to use other code is to either make sure the
+ Apache core itself already contains a reference to it or
+ loading the code yourself via <code>dlopen()</code>.</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Dynamic Shared Object (DSO) support</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 align="center">
-Dynamic Shared Object (DSO) Support
-</H1>
-
-<p>The Apache HTTP Server is a modular program where the administrator
-can choose the functionality to include in the server by selecting a
-set of modules. The modules can be statically compiled into the
-<code>httpd</code> binary when the server is built. Alternatively,
-modules can be compiled as Dynamic Shared Objects (DSOs) that exist
-separately from the main <code>httpd</code> binary file. DSO modules
-may be compiled at the time the server is built, or they may be
-compiled and added at a later time using the Apache Extension Tool (<a
-href="programs/apxs.html">apxs</a>).</p>
-
-<p>This document describes how to use DSO modules as well as the theory
-behind their use.</p>
-
-<ul>
-<li><a href="#implementation">Implementation</a></li>
-<li><a href="#usage">Usage Summary</a></li>
-<li><a href="#background">Background</a></li>
-<li><a href="#advantages">Advantages and Disadvantages</a></li>
-</ul>
-
-<hr>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_so.html">mod_so</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_so.html#loadmodule">LoadModule</A><br>
-
-</td></tr></table>
-
-<H2><a name="implementation">Implementation</a></H2>
-
-<P>The DSO support for loading individual Apache modules is based on a
-module named <A HREF="mod/mod_so.html"><CODE>mod_so.c</CODE></A> which
-must be statically compiled into the Apache core. It is the only
-module besides <CODE>core.c</CODE> which cannot be put into a DSO
-itself. Practically all other distributed Apache modules then can
-then be placed into a DSO by individually enabling the DSO build for
-them via <CODE>configure</CODE>'s
-<CODE>--enable-<i>module</i>=shared</CODE> option as disucussed in the
-<a href="install.html">install documentation</a>. After a module is
-compiled into a DSO named <CODE>mod_foo.so</CODE> you can use <A
-HREF="mod/mod_so.html"><CODE>mod_so</CODE></A>'s <A
-HREF="mod/mod_so.html#loadmodule"><CODE>LoadModule</CODE></A> command
-in your <CODE>httpd.conf</CODE> file to load this module at server
-startup or restart.
-
-<P>To simplify this creation of DSO files for Apache modules
-(especially for third-party modules) a new support program named <a
-href="programs/apxs.html">apxs</a> (<EM>APache eXtenSion</EM>) is
-available. It can be used to build DSO based modules <EM>outside
-of</EM> the Apache source tree. The idea is simple: When installing
-Apache the <CODE>configure</CODE>'s <CODE>make install</CODE>
-procedure installs the Apache C header files and puts the
-platform-dependent compiler and linker flags for building DSO files
-into the <CODE>apxs</CODE> program. This way the user can use
-<CODE>apxs</CODE> to compile his Apache module sources without the
-Apache distribution source tree and without having to fiddle with the
-platform-dependent compiler and linker flags for DSO support.
-
-<H2><a name="usage">Usage Summary</a></H2>
-
-<P>To give you an overview of the DSO features of Apache 2.0, here is a short
-and concise summary:
-
-<OL>
-
-<LI>Build and install a <EM>distributed</EM> Apache module, say
-<CODE>mod_foo.c</CODE>, into its own DSO <CODE>mod_foo.so</CODE>:
-
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Dynamic Shared Object (DSO) support</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Dynamic Shared Object (DSO) Support</h1>
+
+ <p>The Apache HTTP Server is a modular program where the
+ administrator can choose the functionality to include in the
+ server by selecting a set of modules. The modules can be
+ statically compiled into the <code>httpd</code> binary when the
+ server is built. Alternatively, modules can be compiled as
+ Dynamic Shared Objects (DSOs) that exist separately from the
+ main <code>httpd</code> binary file. DSO modules may be
+ compiled at the time the server is built, or they may be
+ compiled and added at a later time using the Apache Extension
+ Tool (<a href="programs/apxs.html">apxs</a>).</p>
+
+ <p>This document describes how to use DSO modules as well as
+ the theory behind their use.</p>
+
+ <ul>
+ <li><a href="#implementation">Implementation</a></li>
+
+ <li><a href="#usage">Usage Summary</a></li>
+
+ <li><a href="#background">Background</a></li>
+
+ <li><a href="#advantages">Advantages and
+ Disadvantages</a></li>
+ </ul>
+ <hr />
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_so.html">mod_so</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_so.html#loadmodule">LoadModule</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h2><a id="implementation"
+ name="implementation">Implementation</a></h2>
+
+ <p>The DSO support for loading individual Apache modules is
+ based on a module named <a
+ href="mod/mod_so.html"><code>mod_so.c</code></a> which must be
+ statically compiled into the Apache core. It is the only module
+ besides <code>core.c</code> which cannot be put into a DSO
+ itself. Practically all other distributed Apache modules then
+ can then be placed into a DSO by individually enabling the DSO
+ build for them via <code>configure</code>'s
+ <code>--enable-<i>module</i>=shared</code> option as disucussed
+ in the <a href="install.html">install documentation</a>. After
+ a module is compiled into a DSO named <code>mod_foo.so</code>
+ you can use <a href="mod/mod_so.html"><code>mod_so</code></a>'s
+ <a
+ href="mod/mod_so.html#loadmodule"><code>LoadModule</code></a>
+ command in your <code>httpd.conf</code> file to load this
+ module at server startup or restart.</p>
+
+ <p>To simplify this creation of DSO files for Apache modules
+ (especially for third-party modules) a new support program
+ named <a href="programs/apxs.html">apxs</a> (<em>APache
+ eXtenSion</em>) is available. It can be used to build DSO based
+ modules <em>outside of</em> the Apache source tree. The idea is
+ simple: When installing Apache the <code>configure</code>'s
+ <code>make install</code> procedure installs the Apache C
+ header files and puts the platform-dependent compiler and
+ linker flags for building DSO files into the <code>apxs</code>
+ program. This way the user can use <code>apxs</code> to compile
+ his Apache module sources without the Apache distribution
+ source tree and without having to fiddle with the
+ platform-dependent compiler and linker flags for DSO
+ support.</p>
+
+ <h2><a id="usage" name="usage">Usage Summary</a></h2>
+
+ <p>To give you an overview of the DSO features of Apache 2.0,
+ here is a short and concise summary:</p>
+
+ <ol>
+ <li>
+ Build and install a <em>distributed</em> Apache module, say
+ <code>mod_foo.c</code>, into its own DSO
+ <code>mod_foo.so</code>:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ ./configure --prefix=/path/to/install
--enable-foo=shared
$ make install
-</PRE>
-</TD></TR></TABLE>
-
-<LI>Build and install a <EM>third-party</EM> Apache module, say
-<CODE>mod_foo.c</CODE>, into its own DSO <CODE>mod_foo.so</CODE>:
-
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+
+ <li>
+ Build and install a <em>third-party</em> Apache module, say
+ <code>mod_foo.c</code>, into its own DSO
+ <code>mod_foo.so</code>:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c
--enable-foo=shared
$ make install
-</PRE>
-</TD></TR></TABLE>
-
-<LI>Configure Apache for <EM>later installation</EM> of shared modules:
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+
+ <li>
+ Configure Apache for <em>later installation</em> of shared
+ modules:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ ./configure --enable-so
$ make install
-</PRE>
-</TD></TR></TABLE>
-
-<LI>Build and install a <EM>third-party</EM> Apache module, say
-<CODE>mod_foo.c</CODE>, into its own DSO <CODE>mod_foo.so</CODE> <EM>outside
-of</EM> the Apache source tree using <a href="programs/apxs.html">apxs</a>:
-<TABLE BGCOLOR="#f0f0f0" CELLPADDING=10><TR><TD>
-<PRE>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+
+ <li>
+ Build and install a <em>third-party</em> Apache module, say
+ <code>mod_foo.c</code>, into its own DSO
+ <code>mod_foo.so</code> <em>outside of</em> the Apache
+ source tree using <a href="programs/apxs.html">apxs</a>:
+
+ <table bgcolor="#f0f0f0" cellpadding="10">
+ <tr>
+ <td>
+<pre>
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.so
-</PRE>
-</TD></TR></TABLE>
-
-</OL>
-
-<p>In all cases, once the shared module is compiled, you must use a <A
-HREF="mod/mod_so.html#loadmodule"><CODE>LoadModule</CODE></A> directive
-in <code>httpd.conf</code> to tell Apache to activate the module.
-
-
-
-<H2><a name="background">Background</a></H2>
-
-<P>On modern Unix derivatives there exists a nifty mechanism usually called
-dynamic linking/loading of <EM>Dynamic Shared Objects</EM> (DSO) which
-provides a way to build a piece of program code in a special format for
-loading it at run-time into the address space of an executable program.
-
-<P>This loading can usually be done in two ways: Automatically by a system
-program called <CODE>ld.so</CODE> when an executable program is started or
-manually from within the executing program via a programmatic system interface
-to the Unix loader through the system calls <CODE>dlopen()/dlsym()</CODE>.
-
-<P>In the first way the DSO's are usually called <EM>shared libraries</EM> or
-<EM>DSO libraries</EM> and named <CODE>libfoo.so</CODE> or
-<CODE>libfoo.so.1.2</CODE>. They reside in a system directory (usually
-<CODE>/usr/lib</CODE>) and the link to the executable program is established
-at build-time by specifying <CODE>-lfoo</CODE> to the linker command. This
-hard-codes library references into the executable program file so that at
-start-time the Unix loader is able to locate <CODE>libfoo.so</CODE> in
-<CODE>/usr/lib</CODE>, in paths hard-coded via linker-options like
-<CODE>-R</CODE> or in paths configured via the environment variable
-<CODE>LD_LIBRARY_PATH</CODE>. It then resolves any (yet unresolved) symbols in
-the executable program which are available in the DSO.
-
-<P>Symbols in the executable program are usually not referenced by the DSO
-(because it's a reusable library of general code) and hence no further
-resolving has to be done. The executable program has no need to do anything on
-its own to use the symbols from the DSO because the complete resolving is done
-by the Unix loader. (In fact, the code to invoke <CODE>ld.so</CODE> is part of
-the run-time startup code which is linked into every executable program which
-has been bound non-static). The advantage of dynamic loading of common library
-code is obvious: the library code needs to be stored only once, in a system
-library like <CODE>libc.so</CODE>, saving disk space for every program.
-
-<P>In the second way the DSO's are usually called <EM>shared objects</EM> or
-<EM>DSO files</EM> and can be named with an arbitrary extension (although the
-canonical name is <CODE>foo.so</CODE>). These files usually stay inside a
-program-specific directory and there is no automatically established link to
-the executable program where they are used. Instead the executable program
-manually loads the DSO at run-time into its address space via
-<CODE>dlopen()</CODE>. At this time no resolving of symbols from the DSO for
-the executable program is done. But instead the Unix loader automatically
-resolves any (yet unresolved) symbols in the DSO from the set of symbols
-exported by the executable program and its already loaded DSO libraries
-(especially all symbols from the ubiquitous <CODE>libc.so</CODE>). This way
-the DSO gets knowledge of the executable program's symbol set as if it had
-been statically linked with it in the first place.
-
-<P>Finally, to take advantage of the DSO's API the executable program has to
-resolve particular symbols from the DSO via <CODE>dlsym()</CODE> for later use
-inside dispatch tables <EM>etc.</EM> In other words: The executable program has to
-manually resolve every symbol it needs to be able to use it. The advantage of
-such a mechanism is that optional program parts need not be loaded (and thus
-do not spend memory) until they are needed by the program in question. When
-required, these program parts can be loaded dynamically to extend the base
-program's functionality.
-
-<P>Although this DSO mechanism sounds straightforward there is at least one
-difficult step here: The resolving of symbols from the executable program for
-the DSO when using a DSO to extend a program (the second way). Why? Because
-"reverse resolving" DSO symbols from the executable program's symbol set is
-against the library design (where the library has no knowledge about the
-programs it is used by) and is neither available under all platforms nor
-standardized. In practice the executable program's global symbols are often
-not re-exported and thus not available for use in a DSO. Finding a way to
-force the linker to export all global symbols is the main problem one has to
-solve when using DSO for extending a program at run-time.
-
-<P>The shared library approach is the typical one, because it is what the DSO
-mechanism was designed for, hence it is used for nearly all types of libraries
-the operating system provides. On the other hand using shared objects for
-extending a program is not used by a lot of programs.
-
-<P>As of 1998 there are only a few software packages available which use the
-DSO mechanism to actually extend their functionality at run-time: Perl 5 (via
-its XS mechanism and the DynaLoader module), Netscape Server, <EM>etc.</EM> Starting
-with version 1.3, Apache joined the crew, because Apache already uses a module
-concept to extend its functionality and internally uses a dispatch-list-based
-approach to link external modules into the Apache core functionality. So,
-Apache is really predestined for using DSO to load its modules at run-time.
-
-
-<H2><a name="advantages">Advantages and Disadvantages</a></H2>
-
-<P>The above DSO based features have the following advantages:
-
-<UL>
-<LI> The server package is more flexible at run-time because the actual server
- process can be assembled at run-time via <A
- HREF="mod/mod_so.html#loadmodule"><CODE>LoadModule</CODE></A>
- <CODE>httpd.conf</CODE> configuration commands instead of
- <CODE>configure</CODE> options at build-time.
- For instance this way one is able to run different server instances
- (standard & SSL version, minimalistic & powered up version
- [mod_perl, PHP3], <EM>etc.</EM>) with only one Apache installation.
-<P>
-<LI> The server package can be easily extended with third-party modules even
- after installation. This is at least a great benefit for vendor package
- maintainers who can create a Apache core package and additional packages
- containing extensions like PHP3, mod_perl, mod_fastcgi, <EM>etc.</EM>
-<P>
-<LI> Easier Apache module prototyping because with the DSO/<CODE>apxs</CODE>
- pair you can both work outside the Apache source tree and only need an
- <CODE>apxs -i</CODE> command followed by an <CODE>apachectl
- restart</CODE> to bring a new version of your currently developed module
- into the running Apache server.
-</UL>
-
-<P>DSO has the following disadvantages:
-
-<UL>
-<LI> The DSO mechanism cannot be used on every platform because not all
- operating systems support dynamic loading of code into the address space
- of a program.
-<P>
-<LI> The server is approximately 20% slower at startup time because of the
- symbol resolving overhead the Unix loader now has to do.
-<P>
-<LI> The server is approximately 5% slower at execution time under some
- platforms because position independent code (PIC) sometimes needs
- complicated assembler tricks for relative addressing which are not
- necessarily as fast as absolute addressing.
-<P>
-<LI> Because DSO modules cannot be linked against other DSO-based libraries
- (<CODE>ld -lfoo</CODE>) on all platforms (for instance a.out-based
- platforms usually don't provide this functionality while ELF-based
- platforms do) you cannot use the DSO mechanism for all types of modules.
- Or in other words, modules compiled as DSO files are restricted to only
- use symbols from the Apache core, from the C library (<CODE>libc</CODE>)
- and all other dynamic or static libraries used by the Apache core, or
- from static library archives (<CODE>libfoo.a</CODE>) containing position
- independent code. The only chances to use other code is to either make
- sure the Apache core itself already contains a reference to it or loading
- the code yourself via <CODE>dlopen()</CODE>.
-<P>
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+ </ol>
+
+ <p>In all cases, once the shared module is compiled, you must
+ use a <a
+ href="mod/mod_so.html#loadmodule"><code>LoadModule</code></a>
+ directive in <code>httpd.conf</code> to tell Apache to activate
+ the module.</p>
+
+ <h2><a id="background" name="background">Background</a></h2>
+
+ <p>On modern Unix derivatives there exists a nifty mechanism
+ usually called dynamic linking/loading of <em>Dynamic Shared
+ Objects</em> (DSO) which provides a way to build a piece of
+ program code in a special format for loading it at run-time
+ into the address space of an executable program.</p>
+
+ <p>This loading can usually be done in two ways: Automatically
+ by a system program called <code>ld.so</code> when an
+ executable program is started or manually from within the
+ executing program via a programmatic system interface to the
+ Unix loader through the system calls
+ <code>dlopen()/dlsym()</code>.</p>
+
+ <p>In the first way the DSO's are usually called <em>shared
+ libraries</em> or <em>DSO libraries</em> and named
+ <code>libfoo.so</code> or <code>libfoo.so.1.2</code>. They
+ reside in a system directory (usually <code>/usr/lib</code>)
+ and the link to the executable program is established at
+ build-time by specifying <code>-lfoo</code> to the linker
+ command. This hard-codes library references into the executable
+ program file so that at start-time the Unix loader is able to
+ locate <code>libfoo.so</code> in <code>/usr/lib</code>, in
+ paths hard-coded via linker-options like <code>-R</code> or in
+ paths configured via the environment variable
+ <code>LD_LIBRARY_PATH</code>. It then resolves any (yet
+ unresolved) symbols in the executable program which are
+ available in the DSO.</p>
+
+ <p>Symbols in the executable program are usually not referenced
+ by the DSO (because it's a reusable library of general code)
+ and hence no further resolving has to be done. The executable
+ program has no need to do anything on its own to use the
+ symbols from the DSO because the complete resolving is done by
+ the Unix loader. (In fact, the code to invoke
+ <code>ld.so</code> is part of the run-time startup code which
+ is linked into every executable program which has been bound
+ non-static). The advantage of dynamic loading of common library
+ code is obvious: the library code needs to be stored only once,
+ in a system library like <code>libc.so</code>, saving disk
+ space for every program.</p>
+
+ <p>In the second way the DSO's are usually called <em>shared
+ objects</em> or <em>DSO files</em> and can be named with an
+ arbitrary extension (although the canonical name is
+ <code>foo.so</code>). These files usually stay inside a
+ program-specific directory and there is no automatically
+ established link to the executable program where they are used.
+ Instead the executable program manually loads the DSO at
+ run-time into its address space via <code>dlopen()</code>. At
+ this time no resolving of symbols from the DSO for the
+ executable program is done. But instead the Unix loader
+ automatically resolves any (yet unresolved) symbols in the DSO
+ from the set of symbols exported by the executable program and
+ its already loaded DSO libraries (especially all symbols from
+ the ubiquitous <code>libc.so</code>). This way the DSO gets
+ knowledge of the executable program's symbol set as if it had
+ been statically linked with it in the first place.</p>
+
+ <p>Finally, to take advantage of the DSO's API the executable
+ program has to resolve particular symbols from the DSO via
+ <code>dlsym()</code> for later use inside dispatch tables
+ <em>etc.</em> In other words: The executable program has to
+ manually resolve every symbol it needs to be able to use it.
+ The advantage of such a mechanism is that optional program
+ parts need not be loaded (and thus do not spend memory) until
+ they are needed by the program in question. When required,
+ these program parts can be loaded dynamically to extend the
+ base program's functionality.</p>
+
+ <p>Although this DSO mechanism sounds straightforward there is
+ at least one difficult step here: The resolving of symbols from
+ the executable program for the DSO when using a DSO to extend a
+ program (the second way). Why? Because "reverse resolving" DSO
+ symbols from the executable program's symbol set is against the
+ library design (where the library has no knowledge about the
+ programs it is used by) and is neither available under all
+ platforms nor standardized. In practice the executable
+ program's global symbols are often not re-exported and thus not
+ available for use in a DSO. Finding a way to force the linker
+ to export all global symbols is the main problem one has to
+ solve when using DSO for extending a program at run-time.</p>
+
+ <p>The shared library approach is the typical one, because it
+ is what the DSO mechanism was designed for, hence it is used
+ for nearly all types of libraries the operating system
+ provides. On the other hand using shared objects for extending
+ a program is not used by a lot of programs.</p>
+
+ <p>As of 1998 there are only a few software packages available
+ which use the DSO mechanism to actually extend their
+ functionality at run-time: Perl 5 (via its XS mechanism and the
+ DynaLoader module), Netscape Server, <em>etc.</em> Starting
+ with version 1.3, Apache joined the crew, because Apache
+ already uses a module concept to extend its functionality and
+ internally uses a dispatch-list-based approach to link external
+ modules into the Apache core functionality. So, Apache is
+ really predestined for using DSO to load its modules at
+ run-time.</p>
+
+ <h2><a id="advantages" name="advantages">Advantages and
+ Disadvantages</a></h2>
+
+ <p>The above DSO based features have the following
+ advantages:</p>
+
+ <ul>
+ <li>The server package is more flexible at run-time because
+ the actual server process can be assembled at run-time via <a
+ href="mod/mod_so.html#loadmodule"><code>LoadModule</code></a>
+ <code>httpd.conf</code> configuration commands instead of
+ <code>configure</code> options at build-time. For instance
+ this way one is able to run different server instances
+ (standard & SSL version, minimalistic & powered up
+ version [mod_perl, PHP3], <em>etc.</em>) with only one Apache
+ installation.</li>
+
+ <li>The server package can be easily extended with
+ third-party modules even after installation. This is at least
+ a great benefit for vendor package maintainers who can create
+ a Apache core package and additional packages containing
+ extensions like PHP3, mod_perl, mod_fastcgi,
+ <em>etc.</em></li>
+
+ <li>Easier Apache module prototyping because with the
+ DSO/<code>apxs</code> pair you can both work outside the
+ Apache source tree and only need an <code>apxs -i</code>
+ command followed by an <code>apachectl restart</code> to
+ bring a new version of your currently developed module into
+ the running Apache server.</li>
+ </ul>
+
+ <p>DSO has the following disadvantages:</p>
+
+ <ul>
+ <li>The DSO mechanism cannot be used on every platform
+ because not all operating systems support dynamic loading of
+ code into the address space of a program.</li>
+
+ <li>The server is approximately 20% slower at startup time
+ because of the symbol resolving overhead the Unix loader now
+ has to do.</li>
+
+ <li>The server is approximately 5% slower at execution time
+ under some platforms because position independent code (PIC)
+ sometimes needs complicated assembler tricks for relative
+ addressing which are not necessarily as fast as absolute
+ addressing.</li>
+
+ <li>Because DSO modules cannot be linked against other
+ DSO-based libraries (<code>ld -lfoo</code>) on all platforms
+ (for instance a.out-based platforms usually don't provide
+ this functionality while ELF-based platforms do) you cannot
+ use the DSO mechanism for all types of modules. Or in other
+ words, modules compiled as DSO files are restricted to only
+ use symbols from the Apache core, from the C library
+ (<code>libc</code>) and all other dynamic or static libraries
+ used by the Apache core, or from static library archives
+ (<code>libfoo.a</code>) containing position independent code.
+ The only chances to use other code is to either make sure the
+ Apache core itself already contains a reference to it or
+ loading the code yourself via <code>dlopen()</code>.</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>The Apache EBCDIC Port</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<blockquote><strong>Warning:</strong>
-This document has not been updated to take into account changes
-made in the 2.0 version of the Apache HTTP Server. Some of the
-information may still be relevant, but please use it
-with care.
-</blockquote>
-
-<H1 ALIGN="CENTER">Overview of the Apache EBCDIC Port</H1>
-
- <P>
- Version 1.3 of the Apache HTTP Server is the first version which
- includes a port to a (non-ASCII) mainframe machine which uses
- the EBCDIC character set as its native codeset.<BR>
- (It is the SIEMENS family of mainframes running the
- <A HREF="http://www.siemens.de/servers/bs2osd/osdbc_us.htm">BS2000/OSD
- operating system</A>. This mainframe OS nowadays features a
- SVR4-derived POSIX subsystem).
- </P>
-
- <P>
- The port was started initially to
- <UL>
- <LI> prove the feasibility of porting
- <A HREF="http://dev.apache.org/">the Apache HTTP server</A>
- to this platform
- <LI> find a "worthy and capable" successor for the venerable
- <A HREF="http://www.w3.org/Daemon/">CERN-3.0</A> daemon
- (which was ported a couple of years ago), and to
- <LI> prove that Apache's preforking process model can on this platform
- easily outperform the accept-fork-serve model used by CERN by a
- factor of 5 or more.
- </UL>
- </P>
-
- <P>
- This document serves as a rationale to describe some of the design
- decisions of the port to this machine.
- </P>
-
- <H2 ALIGN=CENTER>Design Goals</H2>
- <P>
- One objective of the EBCDIC port was to maintain enough backwards
- compatibility with the (EBCDIC) CERN server to make the transition to
- the new server attractive and easy. This required the addition of
- a configurable method to define whether a HTML document was stored
- in ASCII (the only format accepted by the old server) or in EBCDIC
- (the native document format in the POSIX subsystem, and therefore
- the only realistic format in which the other POSIX tools like grep
- or sed could operate on the documents). The current solution to
- this is a "pseudo-MIME-format" which is intercepted and
- interpreted by the Apache server (see below). Future versions
- might solve the problem by defining an "ebcdic-handler" for all
- documents which must be converted.
- </P>
-
- <H2 ALIGN=CENTER>Technical Solution</H2>
- <P>
- Since all Apache input and output is based upon the BUFF data type
- and its methods, the easiest solution was to add the conversion to
- the BUFF handling routines. The conversion must be settable at any
- time, so a BUFF flag was added which defines whether a BUFF object
- has currently enabled conversion or not. This flag is modified at
- several points in the HTTP protocol:
- <UL>
- <LI><STRONG>set</STRONG> before a request is received (because the
- request and the request header lines are always in ASCII
- format)
-
- <LI><STRONG>set/unset</STRONG> when the request body is
- received - depending on the content type of the request body
- (because the request body may contain ASCII text or a binary file)
-
- <LI><STRONG>set</STRONG> before a reply header is sent (because the
- response header lines are always in ASCII format)
-
- <LI><STRONG>set/unset</STRONG> when the response body is
- sent - depending on the content type of the response body
- (because the response body may contain text or a binary file)
- </UL>
- </P>
-
-<H2 ALIGN=CENTER>Porting Notes</H2>
- <P>
- <OL>
- <LI>
- The relevant changes in the source are #ifdef'ed into two
- categories:
- <DL>
- <DT><CODE><STRONG>#ifdef CHARSET_EBCDIC</STRONG></CODE>
- <DD>Code which is needed for any EBCDIC based machine. This
- includes character translations, differences in
- contiguity of the two character sets, flags which
- indicate which part of the HTTP protocol has to be
- converted and which part doesn't <EM>etc.</EM>
- <DT><CODE><STRONG>#ifdef _OSD_POSIX</STRONG></CODE>
- <DD>Code which is needed for the SIEMENS BS2000/OSD
- mainframe platform only. This deals with include file
- differences and socket implementation topics which are
- only required on the BS2000/OSD platform.
- </DL>
- </LI><BR>
-
- <LI>
- The possibility to translate between ASCII and EBCDIC at the
- socket level (on BS2000 POSIX, there is a socket option which
- supports this) was intentionally <EM>not</EM> chosen, because
- the byte stream at the HTTP protocol level consists of a
- mixture of protocol related strings and non-protocol related
- raw file data. HTTP protocol strings are always encoded in
- ASCII (the GET request, any Header: lines, the chunking
- information <EM>etc.</EM>) whereas the file transfer parts (<EM>i.e.</EM>, GIF
- images, CGI output <EM>etc.</EM>) should usually be just "passed through"
- by the server. This separation between "protocol string" and
- "raw data" is reflected in the server code by functions like
- bgets() or rvputs() for strings, and functions like bwrite()
- for binary data. A global translation of everything would
- therefore be inadequate.<BR>
- (In the case of text files of course, provisions must be made so
- that EBCDIC documents are always served in ASCII)
- </LI><BR>
-
- <LI>
- This port therefore features a built-in protocol level conversion
- for the server-internal strings (which the compiler translated to
- EBCDIC strings) and thus for all server-generated documents.
- The hard coded ASCII escapes \012 and \015 which are
- ubiquitous in the server code are an exception: they are
- already the binary encoding of the ASCII \n and \r and must
- not be converted to ASCII a second time. This exception is
- only relevant for server-generated strings; and <EM>external</EM>
- EBCDIC documents are not expected to contain ASCII newline characters.
- </LI><BR>
-
- <LI>
- By examining the call hierarchy for the BUFF management
- routines, I added an "ebcdic/ascii conversion layer" which
- would be crossed on every puts/write/get/gets, and a
- conversion flag which allowed enabling/disabling the
- conversions on-the-fly. Usually, a document crosses this
- layer twice from its origin source (a file or CGI output) to
- its destination (the requesting client): <SAMP>file ->
- Apache</SAMP>, and <SAMP>Apache -> client</SAMP>.<BR>
- The server can now read the header
- lines of a CGI-script output in EBCDIC format, and then find
- out that the remainder of the script's output is in ASCII
- (like in the case of the output of a WWW Counter program: the
- document body contains a GIF image). All header processing is
- done in the native EBCDIC format; the server then determines,
- based on the type of document being served, whether the
- document body (except for the chunking information, of
- course) is in ASCII already or must be converted from EBCDIC.
- </LI><BR>
-
- <LI>
- For Text documents (MIME types text/plain, text/html <EM>etc.</EM>),
- an implicit translation to ASCII can be used, or (if the
- users prefer to store some documents in raw ASCII form for
- faster serving, or because the files reside on a NFS-mounted
- directory tree) can be served without conversion.
- <BR>
- <STRONG>Example:</STRONG><BLOCKQUOTE>
- to serve files with the suffix .ahtml as a raw ASCII text/html
- document without implicit conversion (and suffix .ascii
- as ASCII text/plain), use the directives:<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>The Apache EBCDIC Port</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <blockquote>
+ <strong>Warning:</strong> This document has not been updated
+ to take into account changes made in the 2.0 version of the
+ Apache HTTP Server. Some of the information may still be
+ relevant, but please use it with care.
+ </blockquote>
+
+ <h1 align="CENTER">Overview of the Apache EBCDIC Port</h1>
+
+ <p>Version 1.3 of the Apache HTTP Server is the first version
+ which includes a port to a (non-ASCII) mainframe machine which
+ uses the EBCDIC character set as its native codeset.<br />
+ (It is the SIEMENS family of mainframes running the <a
+ href="http://www.siemens.de/servers/bs2osd/osdbc_us.htm">BS2000/OSD
+ operating system</a>. This mainframe OS nowadays features a
+ SVR4-derived POSIX subsystem).</p>
+
+ <p>The port was started initially to</p>
+
+ <ul>
+ <li>prove the feasibility of porting <a
+ href="http://dev.apache.org/">the Apache HTTP server</a> to
+ this platform</li>
+
+ <li>find a "worthy and capable" successor for the venerable
+ <a href="http://www.w3.org/Daemon/">CERN-3.0</a> daemon
+ (which was ported a couple of years ago), and to</li>
+
+ <li>prove that Apache's preforking process model can on this
+ platform easily outperform the accept-fork-serve model used
+ by CERN by a factor of 5 or more.</li>
+ </ul>
+ <br />
+ <br />
+
+
+ <p>This document serves as a rationale to describe some of the
+ design decisions of the port to this machine.</p>
+
+ <h2 align="CENTER">Design Goals</h2>
+
+ <p>One objective of the EBCDIC port was to maintain enough
+ backwards compatibility with the (EBCDIC) CERN server to make
+ the transition to the new server attractive and easy. This
+ required the addition of a configurable method to define
+ whether a HTML document was stored in ASCII (the only format
+ accepted by the old server) or in EBCDIC (the native document
+ format in the POSIX subsystem, and therefore the only realistic
+ format in which the other POSIX tools like grep or sed could
+ operate on the documents). The current solution to this is a
+ "pseudo-MIME-format" which is intercepted and interpreted by
+ the Apache server (see below). Future versions might solve the
+ problem by defining an "ebcdic-handler" for all documents which
+ must be converted.</p>
+
+ <h2 align="CENTER">Technical Solution</h2>
+
+ <p>Since all Apache input and output is based upon the BUFF
+ data type and its methods, the easiest solution was to add the
+ conversion to the BUFF handling routines. The conversion must
+ be settable at any time, so a BUFF flag was added which defines
+ whether a BUFF object has currently enabled conversion or not.
+ This flag is modified at several points in the HTTP
+ protocol:</p>
+
+ <ul>
+ <li><strong>set</strong> before a request is received
+ (because the request and the request header lines are always
+ in ASCII format)</li>
+
+ <li><strong>set/unset</strong> when the request body is
+ received - depending on the content type of the request body
+ (because the request body may contain ASCII text or a binary
+ file)</li>
+
+ <li><strong>set</strong> before a reply header is sent
+ (because the response header lines are always in ASCII
+ format)</li>
+
+ <li><strong>set/unset</strong> when the response body is sent
+ - depending on the content type of the response body (because
+ the response body may contain text or a binary file)</li>
+ </ul>
+ <br />
+ <br />
+
+
+ <h2 align="CENTER">Porting Notes</h2>
+
+ <ol>
+ <li>
+ The relevant changes in the source are #ifdef'ed into two
+ categories:
+
+ <dl>
+ <dt><code><strong>#ifdef
+ CHARSET_EBCDIC</strong></code></dt>
+
+ <dd>Code which is needed for any EBCDIC based machine.
+ This includes character translations, differences in
+ contiguity of the two character sets, flags which
+ indicate which part of the HTTP protocol has to be
+ converted and which part doesn't <em>etc.</em></dd>
+
+ <dt><code><strong>#ifdef _OSD_POSIX</strong></code></dt>
+
+ <dd>Code which is needed for the SIEMENS BS2000/OSD
+ mainframe platform only. This deals with include file
+ differences and socket implementation topics which are
+ only required on the BS2000/OSD platform.</dd>
+ </dl>
+ </li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>The possibility to translate between ASCII and EBCDIC at
+ the socket level (on BS2000 POSIX, there is a socket option
+ which supports this) was intentionally <em>not</em> chosen,
+ because the byte stream at the HTTP protocol level consists
+ of a mixture of protocol related strings and non-protocol
+ related raw file data. HTTP protocol strings are always
+ encoded in ASCII (the GET request, any Header: lines, the
+ chunking information <em>etc.</em>) whereas the file transfer
+ parts (<em>i.e.</em>, GIF images, CGI output <em>etc.</em>)
+ should usually be just "passed through" by the server. This
+ separation between "protocol string" and "raw data" is
+ reflected in the server code by functions like bgets() or
+ rvputs() for strings, and functions like bwrite() for binary
+ data. A global translation of everything would therefore be
+ inadequate.<br />
+ (In the case of text files of course, provisions must be
+ made so that EBCDIC documents are always served in
+ ASCII)</li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>This port therefore features a built-in protocol level
+ conversion for the server-internal strings (which the
+ compiler translated to EBCDIC strings) and thus for all
+ server-generated documents. The hard coded ASCII escapes \012
+ and \015 which are ubiquitous in the server code are an
+ exception: they are already the binary encoding of the ASCII
+ \n and \r and must not be converted to ASCII a second time.
+ This exception is only relevant for server-generated strings;
+ and <em>external</em> EBCDIC documents are not expected to
+ contain ASCII newline characters.</li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>By examining the call hierarchy for the BUFF management
+ routines, I added an "ebcdic/ascii conversion layer" which
+ would be crossed on every puts/write/get/gets, and a
+ conversion flag which allowed enabling/disabling the
+ conversions on-the-fly. Usually, a document crosses this
+ layer twice from its origin source (a file or CGI output) to
+ its destination (the requesting client): <samp>file ->
+ Apache</samp>, and <samp>Apache -> client</samp>.<br />
+ The server can now read the header lines of a CGI-script
+ output in EBCDIC format, and then find out that the remainder
+ of the script's output is in ASCII (like in the case of the
+ output of a WWW Counter program: the document body contains a
+ GIF image). All header processing is done in the native
+ EBCDIC format; the server then determines, based on the type
+ of document being served, whether the document body (except
+ for the chunking information, of course) is in ASCII already
+ or must be converted from EBCDIC.</li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>
+ For Text documents (MIME types text/plain, text/html
+ <em>etc.</em>), an implicit translation to ASCII can be
+ used, or (if the users prefer to store some documents in
+ raw ASCII form for faster serving, or because the files
+ reside on a NFS-mounted directory tree) can be served
+ without conversion.<br />
+ <strong>Example:</strong>
+
+ <blockquote>
+ to serve files with the suffix .ahtml as a raw ASCII
+ text/html document without implicit conversion (and
+ suffix .ascii as ASCII text/plain), use the directives:
+<pre>
AddType text/x-ascii-html .ahtml
AddType text/x-ascii-plain .ascii
- </PRE></BLOCKQUOTE>
- Similarly, any text/foo MIME type can be served as "raw ASCII" by
- configuring a MIME type "text/x-ascii-foo" for it using AddType.
- </LI><BR>
-
- <LI>
- Non-text documents are always served "binary" without conversion.
- This seems to be the most sensible choice for, .<EM>e.g.</EM>, GIF/ZIP/AU
- file types. This of course requires the user to copy them to the
- mainframe host using the "rcp -b" binary switch.
- </LI><BR>
-
- <LI>
- Server parsed files are always assumed to be in native (<EM>i.e.</EM>,
- EBCDIC) format as used on the machine, and are converted after
- processing.
- </LI><BR>
-
- <LI>
- For CGI output, the CGI script determines whether a conversion is
- needed or not: by setting the appropriate Content-Type, text files
- can be converted, or GIF output can be passed through unmodified.
- An example for the latter case is the wwwcount program which we ported
- as well.
- </LI><BR>
- </OL>
- </P>
-
- <H2 ALIGN=CENTER>Document Storage Notes</H2>
- <H3 ALIGN=CENTER>Binary Files</H3>
- <P>
- All files with a <SAMP>Content-Type:</SAMP> which does not
- start with <SAMP>text/</SAMP> are regarded as <EM>binary files</EM>
- by the server and are not subject to any conversion.
- Examples for binary files are GIF images, gzip-compressed
- files and the like.
- </P>
- <P>
- When exchanging binary files between the mainframe host and a
- Unix machine or Windows PC, be sure to use the ftp "binary"
- (<SAMP>TYPE I</SAMP>) command, or use the
- <SAMP>rcp -b</SAMP> command from the mainframe host
- (the -b switch is not supported in unix rcp's).
- </P>
-
- <H3 ALIGN=CENTER>Text Documents</H3>
- <P>
- The default assumption of the server is that Text Files
- (<EM>i.e.</EM>, all files whose <SAMP>Content-Type:</SAMP> starts with
- <SAMP>text/</SAMP>) are stored in the native character
- set of the host, EBCDIC.
- </P>
-
- <H3 ALIGN=CENTER>Server Side Included Documents</H3>
- <P>
- SSI documents must currently be stored in EBCDIC only. No
- provision is made to convert it from ASCII before processing.
- </P>
-
- <H2 ALIGN=CENTER>Apache Modules' Status</H2>
- <TABLE BORDER ALIGN=middle>
- <TR>
- <TH>Module
- <TH>Status
- <TH>Notes
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>http_core
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_access
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_actions
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_alias
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_asis
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_auth
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_auth_anon
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_auth_db
- <TD ALIGN=CENTER>?
- <TD>with own libdb.a
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_auth_dbm
- <TD ALIGN=CENTER>?
- <TD>with own libdb.a
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_autoindex
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_cern_meta
- <TD ALIGN=CENTER>?
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_cgi
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_digest
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_dir
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_so
- <TD ALIGN=CENTER>-
- <TD>no shared libs
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_env
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_example
- <TD ALIGN=CENTER>-
- <TD>(test bed only)
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_expires
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_headers
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_imap
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_include
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_info
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_log_agent
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_log_config
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_log_referer
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_mime
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_mime_magic
- <TD ALIGN=CENTER>?
- <TD>not ported yet
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_negotiation
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_proxy
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_rewrite
- <TD ALIGN=CENTER>+
- <TD>untested
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_setenvif
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_speling
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_status
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_unique_id
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_userdir
- <TD ALIGN=CENTER>+
- <TD>
- </TR>
-
- <TR>
- <TD ALIGN=LEFT>mod_usertrack
- <TD ALIGN=CENTER>?
- <TD>untested
- </TR>
- </TABLE>
-
- <H2 ALIGN=CENTER>Third Party Modules' Status</H2>
- <TABLE BORDER ALIGN=middle>
- <TR>
- <TH>Module
- <TH>Status
- <TH>Notes
- </TR>
-
- <TR>
- <TD ALIGN=LEFT><A HREF="http://java.apache.org/">mod_jserv</A>
- <TD ALIGN=CENTER>-
- <TD>JAVA still being ported.
- </TR>
-
- <TR>
- <TD ALIGN=LEFT><A HREF="http://www.php.net/">mod_php3</A>
- <TD ALIGN=CENTER>+
- <TD>mod_php3 runs fine, with LDAP and GD and FreeType libraries
- </TR>
-
- <TR>
- <TD ALIGN=LEFT
- ><A HREF="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">mod_put</A>
- <TD ALIGN=CENTER>?
- <TD>untested
- </TR>
-
- <TR>
- <TD ALIGN=LEFT
- ><A HREF="ftp://hachiman.vidya.com/pub/apache/">mod_session</A>
- <TD ALIGN=CENTER>-
- <TD>untested
- </TR>
-
- </TABLE>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+
+</pre>
+ </blockquote>
+ Similarly, any text/foo MIME type can be served as "raw
+ ASCII" by configuring a MIME type "text/x-ascii-foo" for it
+ using AddType.
+ </li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>Non-text documents are always served "binary" without
+ conversion. This seems to be the most sensible choice for,
+ .<em>e.g.</em>, GIF/ZIP/AU file types. This of course
+ requires the user to copy them to the mainframe host using
+ the "rcp -b" binary switch.</li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>Server parsed files are always assumed to be in native
+ (<em>i.e.</em>, EBCDIC) format as used on the machine, and
+ are converted after processing.</li>
+
+ <li style="list-style: none"><br />
+ </li>
+
+ <li>For CGI output, the CGI script determines whether a
+ conversion is needed or not: by setting the appropriate
+ Content-Type, text files can be converted, or GIF output can
+ be passed through unmodified. An example for the latter case
+ is the wwwcount program which we ported as well.</li>
+
+ <li style="list-style: none"><br />
+ </li>
+ </ol>
+ <br />
+ <br />
+
+
+ <h2 align="CENTER">Document Storage Notes</h2>
+
+ <h3 align="CENTER">Binary Files</h3>
+
+ <p>All files with a <samp>Content-Type:</samp> which does not
+ start with <samp>text/</samp> are regarded as <em>binary
+ files</em> by the server and are not subject to any conversion.
+ Examples for binary files are GIF images, gzip-compressed files
+ and the like.</p>
+
+ <p>When exchanging binary files between the mainframe host and
+ a Unix machine or Windows PC, be sure to use the ftp "binary"
+ (<samp>TYPE I</samp>) command, or use the
+ <samp>rcp -b</samp> command from the mainframe host (the
+ -b switch is not supported in unix rcp's).</p>
+
+ <h3 align="CENTER">Text Documents</h3>
+
+ <p>The default assumption of the server is that Text Files
+ (<em>i.e.</em>, all files whose <samp>Content-Type:</samp>
+ starts with <samp>text/</samp>) are stored in the native
+ character set of the host, EBCDIC.</p>
+
+ <h3 align="CENTER">Server Side Included Documents</h3>
+
+ <p>SSI documents must currently be stored in EBCDIC only. No
+ provision is made to convert it from ASCII before
+ processing.</p>
+
+ <h2 align="CENTER">Apache Modules' Status</h2>
+
+ <table border="1" align="middle">
+ <tr>
+ <th>Module</th>
+
+ <th>Status</th>
+
+ <th>Notes</th>
+ </tr>
+
+ <tr>
+ <td align="LEFT">http_core</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_access</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_actions</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_alias</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_asis</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_auth</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_auth_anon</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_auth_db</td>
+
+ <td align="CENTER">?</td>
+
+ <td>with own libdb.a</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_auth_dbm</td>
+
+ <td align="CENTER">?</td>
+
+ <td>with own libdb.a</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_autoindex</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_cern_meta</td>
+
+ <td align="CENTER">?</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_cgi</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_digest</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_dir</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_so</td>
+
+ <td align="CENTER">-</td>
+
+ <td>no shared libs</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_env</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_example</td>
+
+ <td align="CENTER">-</td>
+
+ <td>(test bed only)</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_expires</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_headers</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_imap</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_include</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_info</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_log_agent</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_log_config</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_log_referer</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_mime</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_mime_magic</td>
+
+ <td align="CENTER">?</td>
+
+ <td>not ported yet</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_negotiation</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_proxy</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_rewrite</td>
+
+ <td align="CENTER">+</td>
+
+ <td>untested</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_setenvif</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_speling</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_status</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_unique_id</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_userdir</td>
+
+ <td align="CENTER">+</td>
+
+ <td>
+ </td>
+ </tr>
+
+ <tr>
+ <td align="LEFT">mod_usertrack</td>
+
+ <td align="CENTER">?</td>
+
+ <td>untested</td>
+ </tr>
+ </table>
+
+ <h2 align="CENTER">Third Party Modules' Status</h2>
+
+ <table border="1" align="middle">
+ <tr>
+ <th>Module</th>
+
+ <th>Status</th>
+
+ <th>Notes</th>
+ </tr>
+
+ <tr>
+ <td align="LEFT"><a
+ href="http://java.apache.org/">mod_jserv</a> </td>
+
+ <td align="CENTER">-</td>
+
+ <td>JAVA still being ported.</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT"><a href="http://www.php.net/">mod_php3</a>
+ </td>
+
+ <td align="CENTER">+</td>
+
+ <td>mod_php3 runs fine, with LDAP and GD and FreeType
+ libraries</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT"><a
+ href="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">
+ mod_put</a> </td>
+
+ <td align="CENTER">?</td>
+
+ <td>untested</td>
+ </tr>
+
+ <tr>
+ <td align="LEFT"><a
+ href="ftp://hachiman.vidya.com/pub/apache/">mod_session</a>
+ </td>
+
+ <td align="CENTER">-</td>
+
+ <td>untested</td>
+ </tr>
+ </table>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Environment Variables in Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Environment Variables in Apache</h1>
-
-<p>The Apache HTTP Server provides a mechanism for storing information
-in named variables that are called <em>environment variables</em>.
-This information can be used to control various operations such as
-logging or access control. The variables are also used as a mechanism
-to communicate with external programs such as CGI scripts. This
-document discusses different ways to manipulate and use these
-variables.</p>
-
-<p>Although these variables are referred to as <em>environment
-variables</em>, they are not the same as the environment variables
-controlled by the underlying operating system. Instead, these
-variables are stored and manipulated in an internal Apache structure.
-They only become actual operating system environment variables when
-they are provided to CGI scripts and Server Side Include scripts. If
-you wish to manipulate the operating system environment under which
-the server itself runs, you must use the standard environment
-manipulation mechanisms provided by your operating system shell.</p>
-
-<ul>
-<li><a href="#setting">Setting Environment Variables</a></li>
-<li><a href="#using">Using Environment Variables</a></li>
-<li><a href="#special">Special Purpose Environment Variables</a></li>
-<li><a href="#examples">Examples</a></li>
-</ul>
-
-<hr>
-
-<h2><a name="setting">Setting Environment Variables</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_env.html">mod_env</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a><br>
-<a href="mod/mod_setenvif.html">mod_setenvif</a><br>
-<a href="mod/mod_unique_id.html">mod_unique_id</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_setenvif.html#BrowserMatch">BrowserMatch</A><br>
-<A HREF="mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</A><br>
-<A HREF="mod/mod_env.html#passenv">PassEnv</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteRule">RewriteRule</A><br>
-<A HREF="mod/mod_env.html#setenv">SetEnv</A><br>
-<A HREF="mod/mod_setenvif.html#SetEnvIf">SetEnvIf</A><br>
-<A HREF="mod/mod_setenvif.html#SetEnvIfNoCase">SetEnvIfNoCase</A><br>
-<A HREF="mod/mod_env.html#unsetenv">UnsetEnv</A><br>
-</td></tr></table>
-
-<h3>Basic Environment Manipulation</h3>
-
-<p>The most basic way to set an environment variable in Apache is
-using the unconditional <code>SetEnv</code> directive. Variables
-may also be passed from the environment of the shell which started
-the server using the <code>PassEnv</code> directive.</p>
-
-<h3>Conditional Per-Request Settings</h3>
-
-<p>For additional flexibility, the directives provided by mod_setenvif
-allow environment variables to be set on a per-request basis,
-conditional on characteristics of particular requests. For example, a
-variable could be set only when a specific browser (User-Agent) is
-making a request, or only when a specific Referer [sic] header is
-found. Even more flexibility is available through the mod_rewrite's
-<code>RewriteRule</code> which uses the <code>[E=...]</code> option to
-set environment variables.</p>
-
-<h3>Unique Identifiers</h3>
-
-<p>Finally, mod_unique_id sets the environment variable
-<code>UNIQUE_ID</code> for each request to a value which is guaranteed
-to be unique across "all" requests under very specific conditions.</p>
-
-<h3>Standard CGI Variables</h3>
-
-<p>In addition to all environment variables set within the Apache
-configuration and passed from the shell, CGI scripts and SSI pages are
-provided with a set of environment variables containing
-meta-information about the request as required by the
-<a href="http://cgi-spec.golux.com/">CGI specification</a>.</p>
-
-<h3>Some Caveats</h3>
-
-<ul>
-
-<li>It is not possible to override or change the standard CGI
-variables using the environment manipulation directives.</li>
-
-<li>When <a href="suexec.html">suexec</a> is used to launch CGI
-scripts, the environment will be cleaned down to a set of
-<em>safe</em> variables before CGI scripts are launched. The list of
-<em>safe</em> variables is defined at compile-time in
-<code>suexec.c</code>.</li>
-
-<li>For portability reasons, the names of environment variables
-may contain only letters, numbers, and the underscore character.
-In addition, the first character may not be a number. Characters
-which do not match this restriction will be replaced by an
-underscore when passed to CGI scripts and SSI pages.</li>
-
-</ul>
-
-
-<hr>
-
-<h2><a name="using">Using Environment Variables</a></h2>
-
-<table border=1><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_access.html">mod_access</a><br>
-<a href="mod/mod_cgi.html">mod_cgi</a><br>
-<a href="mod/mod_headers.html">mod_headers</a><br>
-<a href="mod/mod_include.html">mod_include</a><br>
-<a href="mod/mod_log_config.html">mod_log_config</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_access.html#allow">Allow</A><br>
-<a href="mod/mod_log_config.html#customlog">CustomLog</a><br>
-<A HREF="mod/mod_access.html#deny">Deny</A><br>
-<a href="mod/mod_headers.html#Header">Header</a><br>
-<a href="mod/mod_log_config.html#logformat">LogFormat</a><br>
-<A HREF="mod/mod_rewrite.html#RewriteCond">RewriteCond</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteRule">RewriteRule</A><br>
-
-</td></tr></table>
-
-<h3>CGI Scripts</h3>
-
-<p>One of the primary uses of environment variables is to communicate
-information to CGI scripts. As discussed above, the environment
-passed to CGI scripts includes standard meta-information about the request
-in addition to any variables set within the Apache configuration.
-For more details, see the <a href="howto/cgi.html">CGI tutorial</a>.
-</p>
-
-<h3>SSI Pages</h3>
-
-<p>Server-parsed (SSI) documents processed by mod_include's
-<code>INCLUDES</code> filter can print environment variables
-using the <code>echo</code> element, and can use environment variables
-in flow control elements to makes parts of a page conditional on
-characteristics of a request. Apache also provides SSI pages with the
-standard CGI environment variables as discussed above. For more
-details, see the <a href="howto/ssi.html">SSI tutorial</a>.
-</p>
-
-<h3>Access Control</h3>
-
-<p>Access to the server can be controlled based on the value of
-environment variables using the <code>allow from env=</code> and
-<code>deny from env=</code></a> directives. In combination with
-<code>SetEnvIf</code>, this allows for flexible control of access to
-the server based on characteristics of the client. For example, you
-can use these directives to deny access to a particular browser
-(User-Agent).
-</p>
-
-<h3>Conditional Logging</h3>
-
-<p>Environment variables can be logged in the access log using the
-<code>LogFormat</code> option <code>%e</code>. In addition, the
-decision on whether or not to log requests can be made based on the
-status of environment variables using the conditional form of the
-<code>CustomLog</code> directive. In combination with
-<code>SetEnvIf</code> this allows for flexible control of which
-requests are logged. For example, you can choose not to log requests
-for filenames ending in <code>gif</code>, or you can choose to only
-log requests from clients which are outside your subnet.
-</p>
-
-<h3>Conditional Response Headers</h3>
-
-<p>The <code>Header</code> directive can use the presence or absence
-of an environment variable to determine whether or not a certain
-HTTP header will be placed in the response to the client.
-This allows, for example, a certain response header to be sent
-only if a corresponding header is received in the request from
-the client.</p>
-
-<h3>URL Rewriting</h3>
-
-<p>The <code>%{ENV:...}</code> form of <em>TestString</em> in the
-<code>RewriteCond</code> allows mod_rewrite's rewrite engine to make
-decisions conditional on environment variables. Note that the
-variables accessible in mod_rewrite without the <code>ENV:</code>
-prefix are not actually environment variables. Rather, they
-are variables special to mod_rewrite which cannot be accessed from
-other modules.</p>
-
-<hr>
-
-<H2><a name="special">Special Purpose Environment Variables</a></H2>
-<P>
-Interoperability problems have led to the introduction of
-mechanisms to modify the way Apache behaves when talking to particular
-clients. To make these mechanisms as flexible as possible, they
-are invoked by defining environment variables, typically with
-<A HREF="mod/mod_setenvif.html#browsermatch">BrowserMatch</A>, though
-<A HREF="mod/mod_env.html#setenv">SetEnv</A> and
-<A HREF="mod/mod_env.html#passenv">PassEnv</A> could also be used, for
-example.
-</P>
-
-<H2>downgrade-1.0</H2>
-<P>
-This forces the request to be treated as a HTTP/1.0 request even if it
-was in a later dialect.
-</P>
-
-<H2>force-no-vary</H2>
-<P>
-This causes any <CODE>Vary</CODE> fields to be removed from the response
-header before it is sent back to the client. Some clients don't
-interpret this field correctly (see the
-<A HREF="misc/known_client_problems.html">known client problems</A>
-page); setting this variable can work around this problem. Setting
-this variable also implies <STRONG>force-response-1.0</STRONG>.
-</P>
-
-<H2>force-response-1.0</H2>
-<P>
-This forces an HTTP/1.0 response when set. It was originally implemented as a
-result of a problem with AOL's proxies. Some clients may not behave correctly
-when given an HTTP/1.1 response, and this can be used to interoperate with
-them.
-</P>
-
-<H2>nokeepalive</H2>
-<P>
-This disables <A HREF="mod/core.html#keepalive">KeepAlive</A> when set.
-</P>
-
-
-<hr>
-
-<h2><a name="examples">Examples</a></h2>
-
-<h3>Changing protocol behavior with misbehaving clients</h3>
-
-<p>We recommend that the following lines be included in httpd.conf
-to deal with known client problems.</p>
-
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Environment Variables in Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Environment Variables in Apache</h1>
+
+ <p>The Apache HTTP Server provides a mechanism for storing
+ information in named variables that are called <em>environment
+ variables</em>. This information can be used to control various
+ operations such as logging or access control. The variables are
+ also used as a mechanism to communicate with external programs
+ such as CGI scripts. This document discusses different ways to
+ manipulate and use these variables.</p>
+
+ <p>Although these variables are referred to as <em>environment
+ variables</em>, they are not the same as the environment
+ variables controlled by the underlying operating system.
+ Instead, these variables are stored and manipulated in an
+ internal Apache structure. They only become actual operating
+ system environment variables when they are provided to CGI
+ scripts and Server Side Include scripts. If you wish to
+ manipulate the operating system environment under which the
+ server itself runs, you must use the standard environment
+ manipulation mechanisms provided by your operating system
+ shell.</p>
+
+ <ul>
+ <li><a href="#setting">Setting Environment Variables</a></li>
+
+ <li><a href="#using">Using Environment Variables</a></li>
+
+ <li><a href="#special">Special Purpose Environment
+ Variables</a></li>
+
+ <li><a href="#examples">Examples</a></li>
+ </ul>
+ <hr />
+
+ <h2><a id="setting" name="setting">Setting Environment
+ Variables</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_env.html">mod_env</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a><br />
+ <a href="mod/mod_setenvif.html">mod_setenvif</a><br />
+ <a href="mod/mod_unique_id.html">mod_unique_id</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/mod_setenvif.html#BrowserMatch">BrowserMatch</a><br />
+ <a
+ href="mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</a><br />
+ <a href="mod/mod_env.html#passenv">PassEnv</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteRule">RewriteRule</a><br />
+ <a href="mod/mod_env.html#setenv">SetEnv</a><br />
+ <a
+ href="mod/mod_setenvif.html#SetEnvIf">SetEnvIf</a><br />
+ <a
+ href="mod/mod_setenvif.html#SetEnvIfNoCase">SetEnvIfNoCase</a><br />
+ <a href="mod/mod_env.html#unsetenv">UnsetEnv</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h3>Basic Environment Manipulation</h3>
+
+ <p>The most basic way to set an environment variable in Apache
+ is using the unconditional <code>SetEnv</code> directive.
+ Variables may also be passed from the environment of the shell
+ which started the server using the <code>PassEnv</code>
+ directive.</p>
+
+ <h3>Conditional Per-Request Settings</h3>
+
+ <p>For additional flexibility, the directives provided by
+ mod_setenvif allow environment variables to be set on a
+ per-request basis, conditional on characteristics of particular
+ requests. For example, a variable could be set only when a
+ specific browser (User-Agent) is making a request, or only when
+ a specific Referer [sic] header is found. Even more flexibility
+ is available through the mod_rewrite's <code>RewriteRule</code>
+ which uses the <code>[E=...]</code> option to set environment
+ variables.</p>
+
+ <h3>Unique Identifiers</h3>
+
+ <p>Finally, mod_unique_id sets the environment variable
+ <code>UNIQUE_ID</code> for each request to a value which is
+ guaranteed to be unique across "all" requests under very
+ specific conditions.</p>
+
+ <h3>Standard CGI Variables</h3>
+
+ <p>In addition to all environment variables set within the
+ Apache configuration and passed from the shell, CGI scripts and
+ SSI pages are provided with a set of environment variables
+ containing meta-information about the request as required by
+ the <a href="http://cgi-spec.golux.com/">CGI
+ specification</a>.</p>
+
+ <h3>Some Caveats</h3>
+
+ <ul>
+ <li>It is not possible to override or change the standard CGI
+ variables using the environment manipulation directives.</li>
+
+ <li>When <a href="suexec.html">suexec</a> is used to launch
+ CGI scripts, the environment will be cleaned down to a set of
+ <em>safe</em> variables before CGI scripts are launched. The
+ list of <em>safe</em> variables is defined at compile-time in
+ <code>suexec.c</code>.</li>
+
+ <li>For portability reasons, the names of environment
+ variables may contain only letters, numbers, and the
+ underscore character. In addition, the first character may
+ not be a number. Characters which do not match this
+ restriction will be replaced by an underscore when passed to
+ CGI scripts and SSI pages.</li>
+ </ul>
+ <hr />
+
+ <h2><a id="using" name="using">Using Environment
+ Variables</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_access.html">mod_access</a><br />
+ <a href="mod/mod_cgi.html">mod_cgi</a><br />
+ <a href="mod/mod_headers.html">mod_headers</a><br />
+ <a href="mod/mod_include.html">mod_include</a><br />
+ <a href="mod/mod_log_config.html">mod_log_config</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_access.html#allow">Allow</a><br />
+ <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a><br />
+ <a href="mod/mod_access.html#deny">Deny</a><br />
+ <a href="mod/mod_headers.html#Header">Header</a><br />
+ <a
+ href="mod/mod_log_config.html#logformat">LogFormat</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteCond">RewriteCond</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteRule">RewriteRule</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h3>CGI Scripts</h3>
+
+ <p>One of the primary uses of environment variables is to
+ communicate information to CGI scripts. As discussed above, the
+ environment passed to CGI scripts includes standard
+ meta-information about the request in addition to any variables
+ set within the Apache configuration. For more details, see the
+ <a href="howto/cgi.html">CGI tutorial</a>.</p>
+
+ <h3>SSI Pages</h3>
+
+ <p>Server-parsed (SSI) documents processed by mod_include's
+ <code>INCLUDES</code> filter can print environment variables
+ using the <code>echo</code> element, and can use environment
+ variables in flow control elements to makes parts of a page
+ conditional on characteristics of a request. Apache also
+ provides SSI pages with the standard CGI environment variables
+ as discussed above. For more details, see the <a
+ href="howto/ssi.html">SSI tutorial</a>.</p>
+
+ <h3>Access Control</h3>
+
+ <p>Access to the server can be controlled based on the value of
+ environment variables using the <code>allow from env=</code>
+ and <code>deny from env=</code> directives. In combination with
+ <code>SetEnvIf</code>, this allows for flexible control of
+ access to the server based on characteristics of the client.
+ For example, you can use these directives to deny access to a
+ particular browser (User-Agent).</p>
+
+ <h3>Conditional Logging</h3>
+
+ <p>Environment variables can be logged in the access log using
+ the <code>LogFormat</code> option <code>%e</code>. In addition,
+ the decision on whether or not to log requests can be made
+ based on the status of environment variables using the
+ conditional form of the <code>CustomLog</code> directive. In
+ combination with <code>SetEnvIf</code> this allows for flexible
+ control of which requests are logged. For example, you can
+ choose not to log requests for filenames ending in
+ <code>gif</code>, or you can choose to only log requests from
+ clients which are outside your subnet.</p>
+
+ <h3>Conditional Response Headers</h3>
+
+ <p>The <code>Header</code> directive can use the presence or
+ absence of an environment variable to determine whether or not
+ a certain HTTP header will be placed in the response to the
+ client. This allows, for example, a certain response header to
+ be sent only if a corresponding header is received in the
+ request from the client.</p>
+
+ <h3>URL Rewriting</h3>
+
+ <p>The <code>%{ENV:...}</code> form of <em>TestString</em> in
+ the <code>RewriteCond</code> allows mod_rewrite's rewrite
+ engine to make decisions conditional on environment variables.
+ Note that the variables accessible in mod_rewrite without the
+ <code>ENV:</code> prefix are not actually environment
+ variables. Rather, they are variables special to mod_rewrite
+ which cannot be accessed from other modules.</p>
+ <hr />
+
+ <h2><a id="special" name="special">Special Purpose Environment
+ Variables</a></h2>
+
+ <p>Interoperability problems have led to the introduction of
+ mechanisms to modify the way Apache behaves when talking to
+ particular clients. To make these mechanisms as flexible as
+ possible, they are invoked by defining environment variables,
+ typically with <a
+ href="mod/mod_setenvif.html#browsermatch">BrowserMatch</a>,
+ though <a href="mod/mod_env.html#setenv">SetEnv</a> and <a
+ href="mod/mod_env.html#passenv">PassEnv</a> could also be used,
+ for example.</p>
+
+ <h2>downgrade-1.0</h2>
+
+ <p>This forces the request to be treated as a HTTP/1.0 request
+ even if it was in a later dialect.</p>
+
+ <h2>force-no-vary</h2>
+
+ <p>This causes any <code>Vary</code> fields to be removed from
+ the response header before it is sent back to the client. Some
+ clients don't interpret this field correctly (see the <a
+ href="misc/known_client_problems.html">known client
+ problems</a> page); setting this variable can work around this
+ problem. Setting this variable also implies
+ <strong>force-response-1.0</strong>.</p>
+
+ <h2>force-response-1.0</h2>
+
+ <p>This forces an HTTP/1.0 response when set. It was originally
+ implemented as a result of a problem with AOL's proxies. Some
+ clients may not behave correctly when given an HTTP/1.1
+ response, and this can be used to interoperate with them.</p>
+
+ <h2>nokeepalive</h2>
+
+ <p>This disables <a
+ href="mod/core.html#keepalive">KeepAlive</a> when set.</p>
+ <hr />
+
+ <h2><a id="examples" name="examples">Examples</a></h2>
+
+ <h3>Changing protocol behavior with misbehaving clients</h3>
+
+ <p>We recommend that the following lines be included in
+ httpd.conf to deal with known client problems.</p>
<pre>
#
# The following directives modify normal HTTP response behavior.
BrowserMatch "JDK/1\.0" force-response-1.0
</pre>
-<h3>Do not log requests for images in the access log</h3>
-
-<p>This example keeps requests for images from appearing
-in the access log. It can be easily modified to prevent logging
-of particular directories, or to prevent logging of requests
-coming from particular hosts.</p>
+ <h3>Do not log requests for images in the access log</h3>
+ <p>This example keeps requests for images from appearing in the
+ access log. It can be easily modified to prevent logging of
+ particular directories, or to prevent logging of requests
+ coming from particular hosts.</p>
<pre>
SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.jpg image-request
CustomLog logs/access_log env=!image-request
</pre>
-<h3>Prevent "Image Theft"</h3>
-
-<p>This example shows how to keep people not on your server from using
-images on your server as inline-images on their pages. This is not
-a recommended configuration, but it can work in limited
-circumstances. We assume that all your images are in a directory
-called /web/images.</p>
+ <h3>Prevent "Image Theft"</h3>
+ <p>This example shows how to keep people not on your server
+ from using images on your server as inline-images on their
+ pages. This is not a recommended configuration, but it can work
+ in limited circumstances. We assume that all your images are in
+ a directory called /web/images.</p>
<pre>
SetEnvIf Referer "^http://www.example.com/" local_referal
# Allow browsers that do not send Referer info
</Directory>
</pre>
-<p>For more information about this technique, see the ApacheToday
-tutorial "<a
-href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS">Keeping
-Your Images from Adorning Other Sites</a>".</p>
+ <p>For more information about this technique, see the
+ ApacheToday tutorial " <a
+ href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS">
+ Keeping Your Images from Adorning Other Sites</a>".</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Environment Variables in Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Environment Variables in Apache</h1>
-
-<p>The Apache HTTP Server provides a mechanism for storing information
-in named variables that are called <em>environment variables</em>.
-This information can be used to control various operations such as
-logging or access control. The variables are also used as a mechanism
-to communicate with external programs such as CGI scripts. This
-document discusses different ways to manipulate and use these
-variables.</p>
-
-<p>Although these variables are referred to as <em>environment
-variables</em>, they are not the same as the environment variables
-controlled by the underlying operating system. Instead, these
-variables are stored and manipulated in an internal Apache structure.
-They only become actual operating system environment variables when
-they are provided to CGI scripts and Server Side Include scripts. If
-you wish to manipulate the operating system environment under which
-the server itself runs, you must use the standard environment
-manipulation mechanisms provided by your operating system shell.</p>
-
-<ul>
-<li><a href="#setting">Setting Environment Variables</a></li>
-<li><a href="#using">Using Environment Variables</a></li>
-<li><a href="#special">Special Purpose Environment Variables</a></li>
-<li><a href="#examples">Examples</a></li>
-</ul>
-
-<hr>
-
-<h2><a name="setting">Setting Environment Variables</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_env.html">mod_env</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a><br>
-<a href="mod/mod_setenvif.html">mod_setenvif</a><br>
-<a href="mod/mod_unique_id.html">mod_unique_id</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_setenvif.html#BrowserMatch">BrowserMatch</A><br>
-<A HREF="mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</A><br>
-<A HREF="mod/mod_env.html#passenv">PassEnv</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteRule">RewriteRule</A><br>
-<A HREF="mod/mod_env.html#setenv">SetEnv</A><br>
-<A HREF="mod/mod_setenvif.html#SetEnvIf">SetEnvIf</A><br>
-<A HREF="mod/mod_setenvif.html#SetEnvIfNoCase">SetEnvIfNoCase</A><br>
-<A HREF="mod/mod_env.html#unsetenv">UnsetEnv</A><br>
-</td></tr></table>
-
-<h3>Basic Environment Manipulation</h3>
-
-<p>The most basic way to set an environment variable in Apache is
-using the unconditional <code>SetEnv</code> directive. Variables
-may also be passed from the environment of the shell which started
-the server using the <code>PassEnv</code> directive.</p>
-
-<h3>Conditional Per-Request Settings</h3>
-
-<p>For additional flexibility, the directives provided by mod_setenvif
-allow environment variables to be set on a per-request basis,
-conditional on characteristics of particular requests. For example, a
-variable could be set only when a specific browser (User-Agent) is
-making a request, or only when a specific Referer [sic] header is
-found. Even more flexibility is available through the mod_rewrite's
-<code>RewriteRule</code> which uses the <code>[E=...]</code> option to
-set environment variables.</p>
-
-<h3>Unique Identifiers</h3>
-
-<p>Finally, mod_unique_id sets the environment variable
-<code>UNIQUE_ID</code> for each request to a value which is guaranteed
-to be unique across "all" requests under very specific conditions.</p>
-
-<h3>Standard CGI Variables</h3>
-
-<p>In addition to all environment variables set within the Apache
-configuration and passed from the shell, CGI scripts and SSI pages are
-provided with a set of environment variables containing
-meta-information about the request as required by the
-<a href="http://cgi-spec.golux.com/">CGI specification</a>.</p>
-
-<h3>Some Caveats</h3>
-
-<ul>
-
-<li>It is not possible to override or change the standard CGI
-variables using the environment manipulation directives.</li>
-
-<li>When <a href="suexec.html">suexec</a> is used to launch CGI
-scripts, the environment will be cleaned down to a set of
-<em>safe</em> variables before CGI scripts are launched. The list of
-<em>safe</em> variables is defined at compile-time in
-<code>suexec.c</code>.</li>
-
-<li>For portability reasons, the names of environment variables
-may contain only letters, numbers, and the underscore character.
-In addition, the first character may not be a number. Characters
-which do not match this restriction will be replaced by an
-underscore when passed to CGI scripts and SSI pages.</li>
-
-</ul>
-
-
-<hr>
-
-<h2><a name="using">Using Environment Variables</a></h2>
-
-<table border=1><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_access.html">mod_access</a><br>
-<a href="mod/mod_cgi.html">mod_cgi</a><br>
-<a href="mod/mod_headers.html">mod_headers</a><br>
-<a href="mod/mod_include.html">mod_include</a><br>
-<a href="mod/mod_log_config.html">mod_log_config</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_access.html#allow">Allow</A><br>
-<a href="mod/mod_log_config.html#customlog">CustomLog</a><br>
-<A HREF="mod/mod_access.html#deny">Deny</A><br>
-<a href="mod/mod_headers.html#Header">Header</a><br>
-<a href="mod/mod_log_config.html#logformat">LogFormat</a><br>
-<A HREF="mod/mod_rewrite.html#RewriteCond">RewriteCond</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteRule">RewriteRule</A><br>
-
-</td></tr></table>
-
-<h3>CGI Scripts</h3>
-
-<p>One of the primary uses of environment variables is to communicate
-information to CGI scripts. As discussed above, the environment
-passed to CGI scripts includes standard meta-information about the request
-in addition to any variables set within the Apache configuration.
-For more details, see the <a href="howto/cgi.html">CGI tutorial</a>.
-</p>
-
-<h3>SSI Pages</h3>
-
-<p>Server-parsed (SSI) documents processed by mod_include's
-<code>INCLUDES</code> filter can print environment variables
-using the <code>echo</code> element, and can use environment variables
-in flow control elements to makes parts of a page conditional on
-characteristics of a request. Apache also provides SSI pages with the
-standard CGI environment variables as discussed above. For more
-details, see the <a href="howto/ssi.html">SSI tutorial</a>.
-</p>
-
-<h3>Access Control</h3>
-
-<p>Access to the server can be controlled based on the value of
-environment variables using the <code>allow from env=</code> and
-<code>deny from env=</code></a> directives. In combination with
-<code>SetEnvIf</code>, this allows for flexible control of access to
-the server based on characteristics of the client. For example, you
-can use these directives to deny access to a particular browser
-(User-Agent).
-</p>
-
-<h3>Conditional Logging</h3>
-
-<p>Environment variables can be logged in the access log using the
-<code>LogFormat</code> option <code>%e</code>. In addition, the
-decision on whether or not to log requests can be made based on the
-status of environment variables using the conditional form of the
-<code>CustomLog</code> directive. In combination with
-<code>SetEnvIf</code> this allows for flexible control of which
-requests are logged. For example, you can choose not to log requests
-for filenames ending in <code>gif</code>, or you can choose to only
-log requests from clients which are outside your subnet.
-</p>
-
-<h3>Conditional Response Headers</h3>
-
-<p>The <code>Header</code> directive can use the presence or absence
-of an environment variable to determine whether or not a certain
-HTTP header will be placed in the response to the client.
-This allows, for example, a certain response header to be sent
-only if a corresponding header is received in the request from
-the client.</p>
-
-<h3>URL Rewriting</h3>
-
-<p>The <code>%{ENV:...}</code> form of <em>TestString</em> in the
-<code>RewriteCond</code> allows mod_rewrite's rewrite engine to make
-decisions conditional on environment variables. Note that the
-variables accessible in mod_rewrite without the <code>ENV:</code>
-prefix are not actually environment variables. Rather, they
-are variables special to mod_rewrite which cannot be accessed from
-other modules.</p>
-
-<hr>
-
-<H2><a name="special">Special Purpose Environment Variables</a></H2>
-<P>
-Interoperability problems have led to the introduction of
-mechanisms to modify the way Apache behaves when talking to particular
-clients. To make these mechanisms as flexible as possible, they
-are invoked by defining environment variables, typically with
-<A HREF="mod/mod_setenvif.html#browsermatch">BrowserMatch</A>, though
-<A HREF="mod/mod_env.html#setenv">SetEnv</A> and
-<A HREF="mod/mod_env.html#passenv">PassEnv</A> could also be used, for
-example.
-</P>
-
-<H2>downgrade-1.0</H2>
-<P>
-This forces the request to be treated as a HTTP/1.0 request even if it
-was in a later dialect.
-</P>
-
-<H2>force-no-vary</H2>
-<P>
-This causes any <CODE>Vary</CODE> fields to be removed from the response
-header before it is sent back to the client. Some clients don't
-interpret this field correctly (see the
-<A HREF="misc/known_client_problems.html">known client problems</A>
-page); setting this variable can work around this problem. Setting
-this variable also implies <STRONG>force-response-1.0</STRONG>.
-</P>
-
-<H2>force-response-1.0</H2>
-<P>
-This forces an HTTP/1.0 response when set. It was originally implemented as a
-result of a problem with AOL's proxies. Some clients may not behave correctly
-when given an HTTP/1.1 response, and this can be used to interoperate with
-them.
-</P>
-
-<H2>nokeepalive</H2>
-<P>
-This disables <A HREF="mod/core.html#keepalive">KeepAlive</A> when set.
-</P>
-
-
-<hr>
-
-<h2><a name="examples">Examples</a></h2>
-
-<h3>Changing protocol behavior with misbehaving clients</h3>
-
-<p>We recommend that the following lines be included in httpd.conf
-to deal with known client problems.</p>
-
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Environment Variables in Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Environment Variables in Apache</h1>
+
+ <p>The Apache HTTP Server provides a mechanism for storing
+ information in named variables that are called <em>environment
+ variables</em>. This information can be used to control various
+ operations such as logging or access control. The variables are
+ also used as a mechanism to communicate with external programs
+ such as CGI scripts. This document discusses different ways to
+ manipulate and use these variables.</p>
+
+ <p>Although these variables are referred to as <em>environment
+ variables</em>, they are not the same as the environment
+ variables controlled by the underlying operating system.
+ Instead, these variables are stored and manipulated in an
+ internal Apache structure. They only become actual operating
+ system environment variables when they are provided to CGI
+ scripts and Server Side Include scripts. If you wish to
+ manipulate the operating system environment under which the
+ server itself runs, you must use the standard environment
+ manipulation mechanisms provided by your operating system
+ shell.</p>
+
+ <ul>
+ <li><a href="#setting">Setting Environment Variables</a></li>
+
+ <li><a href="#using">Using Environment Variables</a></li>
+
+ <li><a href="#special">Special Purpose Environment
+ Variables</a></li>
+
+ <li><a href="#examples">Examples</a></li>
+ </ul>
+ <hr />
+
+ <h2><a id="setting" name="setting">Setting Environment
+ Variables</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_env.html">mod_env</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a><br />
+ <a href="mod/mod_setenvif.html">mod_setenvif</a><br />
+ <a href="mod/mod_unique_id.html">mod_unique_id</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/mod_setenvif.html#BrowserMatch">BrowserMatch</a><br />
+ <a
+ href="mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</a><br />
+ <a href="mod/mod_env.html#passenv">PassEnv</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteRule">RewriteRule</a><br />
+ <a href="mod/mod_env.html#setenv">SetEnv</a><br />
+ <a
+ href="mod/mod_setenvif.html#SetEnvIf">SetEnvIf</a><br />
+ <a
+ href="mod/mod_setenvif.html#SetEnvIfNoCase">SetEnvIfNoCase</a><br />
+ <a href="mod/mod_env.html#unsetenv">UnsetEnv</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h3>Basic Environment Manipulation</h3>
+
+ <p>The most basic way to set an environment variable in Apache
+ is using the unconditional <code>SetEnv</code> directive.
+ Variables may also be passed from the environment of the shell
+ which started the server using the <code>PassEnv</code>
+ directive.</p>
+
+ <h3>Conditional Per-Request Settings</h3>
+
+ <p>For additional flexibility, the directives provided by
+ mod_setenvif allow environment variables to be set on a
+ per-request basis, conditional on characteristics of particular
+ requests. For example, a variable could be set only when a
+ specific browser (User-Agent) is making a request, or only when
+ a specific Referer [sic] header is found. Even more flexibility
+ is available through the mod_rewrite's <code>RewriteRule</code>
+ which uses the <code>[E=...]</code> option to set environment
+ variables.</p>
+
+ <h3>Unique Identifiers</h3>
+
+ <p>Finally, mod_unique_id sets the environment variable
+ <code>UNIQUE_ID</code> for each request to a value which is
+ guaranteed to be unique across "all" requests under very
+ specific conditions.</p>
+
+ <h3>Standard CGI Variables</h3>
+
+ <p>In addition to all environment variables set within the
+ Apache configuration and passed from the shell, CGI scripts and
+ SSI pages are provided with a set of environment variables
+ containing meta-information about the request as required by
+ the <a href="http://cgi-spec.golux.com/">CGI
+ specification</a>.</p>
+
+ <h3>Some Caveats</h3>
+
+ <ul>
+ <li>It is not possible to override or change the standard CGI
+ variables using the environment manipulation directives.</li>
+
+ <li>When <a href="suexec.html">suexec</a> is used to launch
+ CGI scripts, the environment will be cleaned down to a set of
+ <em>safe</em> variables before CGI scripts are launched. The
+ list of <em>safe</em> variables is defined at compile-time in
+ <code>suexec.c</code>.</li>
+
+ <li>For portability reasons, the names of environment
+ variables may contain only letters, numbers, and the
+ underscore character. In addition, the first character may
+ not be a number. Characters which do not match this
+ restriction will be replaced by an underscore when passed to
+ CGI scripts and SSI pages.</li>
+ </ul>
+ <hr />
+
+ <h2><a id="using" name="using">Using Environment
+ Variables</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_access.html">mod_access</a><br />
+ <a href="mod/mod_cgi.html">mod_cgi</a><br />
+ <a href="mod/mod_headers.html">mod_headers</a><br />
+ <a href="mod/mod_include.html">mod_include</a><br />
+ <a href="mod/mod_log_config.html">mod_log_config</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_access.html#allow">Allow</a><br />
+ <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a><br />
+ <a href="mod/mod_access.html#deny">Deny</a><br />
+ <a href="mod/mod_headers.html#Header">Header</a><br />
+ <a
+ href="mod/mod_log_config.html#logformat">LogFormat</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteCond">RewriteCond</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteRule">RewriteRule</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h3>CGI Scripts</h3>
+
+ <p>One of the primary uses of environment variables is to
+ communicate information to CGI scripts. As discussed above, the
+ environment passed to CGI scripts includes standard
+ meta-information about the request in addition to any variables
+ set within the Apache configuration. For more details, see the
+ <a href="howto/cgi.html">CGI tutorial</a>.</p>
+
+ <h3>SSI Pages</h3>
+
+ <p>Server-parsed (SSI) documents processed by mod_include's
+ <code>INCLUDES</code> filter can print environment variables
+ using the <code>echo</code> element, and can use environment
+ variables in flow control elements to makes parts of a page
+ conditional on characteristics of a request. Apache also
+ provides SSI pages with the standard CGI environment variables
+ as discussed above. For more details, see the <a
+ href="howto/ssi.html">SSI tutorial</a>.</p>
+
+ <h3>Access Control</h3>
+
+ <p>Access to the server can be controlled based on the value of
+ environment variables using the <code>allow from env=</code>
+ and <code>deny from env=</code> directives. In combination with
+ <code>SetEnvIf</code>, this allows for flexible control of
+ access to the server based on characteristics of the client.
+ For example, you can use these directives to deny access to a
+ particular browser (User-Agent).</p>
+
+ <h3>Conditional Logging</h3>
+
+ <p>Environment variables can be logged in the access log using
+ the <code>LogFormat</code> option <code>%e</code>. In addition,
+ the decision on whether or not to log requests can be made
+ based on the status of environment variables using the
+ conditional form of the <code>CustomLog</code> directive. In
+ combination with <code>SetEnvIf</code> this allows for flexible
+ control of which requests are logged. For example, you can
+ choose not to log requests for filenames ending in
+ <code>gif</code>, or you can choose to only log requests from
+ clients which are outside your subnet.</p>
+
+ <h3>Conditional Response Headers</h3>
+
+ <p>The <code>Header</code> directive can use the presence or
+ absence of an environment variable to determine whether or not
+ a certain HTTP header will be placed in the response to the
+ client. This allows, for example, a certain response header to
+ be sent only if a corresponding header is received in the
+ request from the client.</p>
+
+ <h3>URL Rewriting</h3>
+
+ <p>The <code>%{ENV:...}</code> form of <em>TestString</em> in
+ the <code>RewriteCond</code> allows mod_rewrite's rewrite
+ engine to make decisions conditional on environment variables.
+ Note that the variables accessible in mod_rewrite without the
+ <code>ENV:</code> prefix are not actually environment
+ variables. Rather, they are variables special to mod_rewrite
+ which cannot be accessed from other modules.</p>
+ <hr />
+
+ <h2><a id="special" name="special">Special Purpose Environment
+ Variables</a></h2>
+
+ <p>Interoperability problems have led to the introduction of
+ mechanisms to modify the way Apache behaves when talking to
+ particular clients. To make these mechanisms as flexible as
+ possible, they are invoked by defining environment variables,
+ typically with <a
+ href="mod/mod_setenvif.html#browsermatch">BrowserMatch</a>,
+ though <a href="mod/mod_env.html#setenv">SetEnv</a> and <a
+ href="mod/mod_env.html#passenv">PassEnv</a> could also be used,
+ for example.</p>
+
+ <h2>downgrade-1.0</h2>
+
+ <p>This forces the request to be treated as a HTTP/1.0 request
+ even if it was in a later dialect.</p>
+
+ <h2>force-no-vary</h2>
+
+ <p>This causes any <code>Vary</code> fields to be removed from
+ the response header before it is sent back to the client. Some
+ clients don't interpret this field correctly (see the <a
+ href="misc/known_client_problems.html">known client
+ problems</a> page); setting this variable can work around this
+ problem. Setting this variable also implies
+ <strong>force-response-1.0</strong>.</p>
+
+ <h2>force-response-1.0</h2>
+
+ <p>This forces an HTTP/1.0 response when set. It was originally
+ implemented as a result of a problem with AOL's proxies. Some
+ clients may not behave correctly when given an HTTP/1.1
+ response, and this can be used to interoperate with them.</p>
+
+ <h2>nokeepalive</h2>
+
+ <p>This disables <a
+ href="mod/core.html#keepalive">KeepAlive</a> when set.</p>
+ <hr />
+
+ <h2><a id="examples" name="examples">Examples</a></h2>
+
+ <h3>Changing protocol behavior with misbehaving clients</h3>
+
+ <p>We recommend that the following lines be included in
+ httpd.conf to deal with known client problems.</p>
<pre>
#
# The following directives modify normal HTTP response behavior.
BrowserMatch "JDK/1\.0" force-response-1.0
</pre>
-<h3>Do not log requests for images in the access log</h3>
-
-<p>This example keeps requests for images from appearing
-in the access log. It can be easily modified to prevent logging
-of particular directories, or to prevent logging of requests
-coming from particular hosts.</p>
+ <h3>Do not log requests for images in the access log</h3>
+ <p>This example keeps requests for images from appearing in the
+ access log. It can be easily modified to prevent logging of
+ particular directories, or to prevent logging of requests
+ coming from particular hosts.</p>
<pre>
SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.jpg image-request
CustomLog logs/access_log env=!image-request
</pre>
-<h3>Prevent "Image Theft"</h3>
-
-<p>This example shows how to keep people not on your server from using
-images on your server as inline-images on their pages. This is not
-a recommended configuration, but it can work in limited
-circumstances. We assume that all your images are in a directory
-called /web/images.</p>
+ <h3>Prevent "Image Theft"</h3>
+ <p>This example shows how to keep people not on your server
+ from using images on your server as inline-images on their
+ pages. This is not a recommended configuration, but it can work
+ in limited circumstances. We assume that all your images are in
+ a directory called /web/images.</p>
<pre>
SetEnvIf Referer "^http://www.example.com/" local_referal
# Allow browsers that do not send Referer info
</Directory>
</pre>
-<p>For more information about this technique, see the ApacheToday
-tutorial "<a
-href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS">Keeping
-Your Images from Adorning Other Sites</a>".</p>
+ <p>For more information about this technique, see the
+ ApacheToday tutorial " <a
+ href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS">
+ Keeping Your Images from Adorning Other Sites</a>".</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Filters - Apache HTTPD</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Filters</H1>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_ext_filter.html">mod_ext_filter</a><br>
-<A HREF="mod/mod_include.html">mod_include</A><br>
-</td>
-<td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/mod_mime.html#addinputfilter">AddInputFilter</a><br>
-<a href="mod/mod_mime.html#addoutputfilter">AddOutputFilter</a><br>
-<a href="mod/mod_ext_filter.html#extfilterdefine">ExtFilterDefine</a></br>
-<a href="mod/mod_ext_filter.html#extfilteroptions">ExtFilterOptions</a><br>
-<a href="mod/core.html#setinputfilter">SetInputFilter</a><br>
-<a href="mod/core.html#setoutputfilter">SetOutputFilter</a><br>
-</td>
-</tr></table>
-
-<p>A <em>filter</em> is a process which is applied to data that is
-sent or received by the server. Data sent by clients to the server
-is processed by <em>input filters</em> while data sent by the
-server to the client is processed by <em>output filters</em>.
-Multiple filters can be applied to the data, and the order
-of the filters can be explicitly specified.</p>
-
-<p>Filters are used internally by Apache to perform functions such as
-chunking and byte-range request handling. In addition, modules can
-provide filters which are selectable using run-time configuration
-directives. The set of filters which apply to data can be manipulated
-with the <code>SetInputFilter</code> and <code>SetOutputFilter</code>
-directives.</p>
-
-<p>The only configurable filter currently included with the Apache
-distribution is the <code>INCLUDES</code> filter which is provided by
-<a href="mod/mod_include.html">mod_include</a> to process output for
-Server Side Includes. There is also an experimental module called <a
-href="mod/mod_ext_filter.html">mod_ext_filter</a> which allows for
-external programs to be defined as filters.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Filters - Apache HTTPD</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Filters</h1>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_ext_filter.html">mod_ext_filter</a><br />
+ <a href="mod/mod_include.html">mod_include</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/mod_mime.html#addinputfilter">AddInputFilter</a><br />
+ <a
+ href="mod/mod_mime.html#addoutputfilter">AddOutputFilter</a><br />
+ <a
+ href="mod/mod_ext_filter.html#extfilterdefine">ExtFilterDefine</a><br />
+ <a
+ href="mod/mod_ext_filter.html#extfilteroptions">ExtFilterOptions</a><br />
+ <a
+ href="mod/core.html#setinputfilter">SetInputFilter</a><br />
+ <a
+ href="mod/core.html#setoutputfilter">SetOutputFilter</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>A <em>filter</em> is a process which is applied to data that
+ is sent or received by the server. Data sent by clients to the
+ server is processed by <em>input filters</em> while data sent
+ by the server to the client is processed by <em>output
+ filters</em>. Multiple filters can be applied to the data, and
+ the order of the filters can be explicitly specified.</p>
+
+ <p>Filters are used internally by Apache to perform functions
+ such as chunking and byte-range request handling. In addition,
+ modules can provide filters which are selectable using run-time
+ configuration directives. The set of filters which apply to
+ data can be manipulated with the <code>SetInputFilter</code>
+ and <code>SetOutputFilter</code> directives.</p>
+
+ <p>The only configurable filter currently included with the
+ Apache distribution is the <code>INCLUDES</code> filter which
+ is provided by <a href="mod/mod_include.html">mod_include</a>
+ to process output for Server Side Includes. There is also an
+ experimental module called <a
+ href="mod/mod_ext_filter.html">mod_ext_filter</a> which allows
+ for external programs to be defined as filters.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Filters - Apache HTTPD</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Filters</H1>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_ext_filter.html">mod_ext_filter</a><br>
-<A HREF="mod/mod_include.html">mod_include</A><br>
-</td>
-<td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/mod_mime.html#addinputfilter">AddInputFilter</a><br>
-<a href="mod/mod_mime.html#addoutputfilter">AddOutputFilter</a><br>
-<a href="mod/mod_ext_filter.html#extfilterdefine">ExtFilterDefine</a></br>
-<a href="mod/mod_ext_filter.html#extfilteroptions">ExtFilterOptions</a><br>
-<a href="mod/core.html#setinputfilter">SetInputFilter</a><br>
-<a href="mod/core.html#setoutputfilter">SetOutputFilter</a><br>
-</td>
-</tr></table>
-
-<p>A <em>filter</em> is a process which is applied to data that is
-sent or received by the server. Data sent by clients to the server
-is processed by <em>input filters</em> while data sent by the
-server to the client is processed by <em>output filters</em>.
-Multiple filters can be applied to the data, and the order
-of the filters can be explicitly specified.</p>
-
-<p>Filters are used internally by Apache to perform functions such as
-chunking and byte-range request handling. In addition, modules can
-provide filters which are selectable using run-time configuration
-directives. The set of filters which apply to data can be manipulated
-with the <code>SetInputFilter</code> and <code>SetOutputFilter</code>
-directives.</p>
-
-<p>The only configurable filter currently included with the Apache
-distribution is the <code>INCLUDES</code> filter which is provided by
-<a href="mod/mod_include.html">mod_include</a> to process output for
-Server Side Includes. There is also an experimental module called <a
-href="mod/mod_ext_filter.html">mod_ext_filter</a> which allows for
-external programs to be defined as filters.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Filters - Apache HTTPD</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Filters</h1>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_ext_filter.html">mod_ext_filter</a><br />
+ <a href="mod/mod_include.html">mod_include</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/mod_mime.html#addinputfilter">AddInputFilter</a><br />
+ <a
+ href="mod/mod_mime.html#addoutputfilter">AddOutputFilter</a><br />
+ <a
+ href="mod/mod_ext_filter.html#extfilterdefine">ExtFilterDefine</a><br />
+ <a
+ href="mod/mod_ext_filter.html#extfilteroptions">ExtFilterOptions</a><br />
+ <a
+ href="mod/core.html#setinputfilter">SetInputFilter</a><br />
+ <a
+ href="mod/core.html#setoutputfilter">SetOutputFilter</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>A <em>filter</em> is a process which is applied to data that
+ is sent or received by the server. Data sent by clients to the
+ server is processed by <em>input filters</em> while data sent
+ by the server to the client is processed by <em>output
+ filters</em>. Multiple filters can be applied to the data, and
+ the order of the filters can be explicitly specified.</p>
+
+ <p>Filters are used internally by Apache to perform functions
+ such as chunking and byte-range request handling. In addition,
+ modules can provide filters which are selectable using run-time
+ configuration directives. The set of filters which apply to
+ data can be manipulated with the <code>SetInputFilter</code>
+ and <code>SetOutputFilter</code> directives.</p>
+
+ <p>The only configurable filter currently included with the
+ Apache distribution is the <code>INCLUDES</code> filter which
+ is provided by <a href="mod/mod_include.html">mod_include</a>
+ to process output for Server Side Includes. There is also an
+ experimental module called <a
+ href="mod/mod_ext_filter.html">mod_ext_filter</a> which allows
+ for external programs to be defined as filters.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<HR>
- <H3 ALIGN="CENTER">
- Apache HTTP Server Version 2.0
- </H3>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title></title>
+ </head>
+
+ <body>
+ <hr />
+
+ <h3 align="CENTER">Apache HTTP Server Version 2.0</h3>
+ <a href="./"><img src="images/index.gif" alt="Index" /></a>
+ </body>
+</html>
-<A HREF="./"><IMG SRC="images/index.gif" ALT="Index"></A>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache's Handler Use</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache's Handler Use</H1>
-
-<ul>
-<li><a href="#definition">What is a Handler</a></li>
-<li><a href="#examples">Examples</a></li>
-<li><a href="#programmer">Programmer's Note</a></li>
-</ul>
-
-<hr>
-<H2><a name="definition">What is a Handler</a></H2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_actions.html">mod_actions</a><br>
-<A HREF="mod/mod_asis.html">mod_asis</A><br>
-<A HREF="mod/mod_cgi.html">mod_cgi</A><br>
-<A HREF="mod/mod_imap.html">mod_imap</A><br>
-<A HREF="mod/mod_info.html">mod_info</A><br>
-<a href="mod/mod_mime.html">mod_mime</a><br>
-<A HREF="mod/mod_negotiation.html">mod_negotiation</A><br>
-<A HREF="mod/mod_status.html">mod_status</A><br>
-</td>
-<td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/mod_actions.html#action">Action</a><br>
-<A HREF="mod/mod_mime.html#addhandler">AddHandler</A><br>
-<a href="mod/mod_mime.html#removehandler">RemoveHandler</a><br>
-<A HREF="mod/mod_mime.html#sethandler">SetHandler</A><br>
-</td>
-</tr></table>
-
-
-<P>A "handler" is an internal Apache representation of the action to be
-performed when a file is called. Generally, files have implicit
-handlers, based on the file type. Normally, all files are simply
-served by the server, but certain file types are "handled"
-separately.</P>
-
-<P>Apache 1.1 adds the ability to use handlers explicitly. Based on
-either filename extensions or on location, handlers can be specified
-without relation to file type. This is advantageous both because it is
-a more elegant solution, and because it also allows for both a type
-<STRONG>and</STRONG> a handler to be associated with a file. (See also
-<A HREF="mod/mod_mime.html#multipleext">Files with Multiple
-Extensions</A>.)</p>
-
-<P>Handlers can either be built into the server or included in a module,
-or they can be added with the <A
-HREF="mod/mod_actions.html#action">Action</A> directive. The built-in
-handlers in the standard distribution are as follows:</P>
-
-<UL>
-<LI><STRONG>default-handler</STRONG>:
- Send the file using the <CODE>default_handler()</CODE>, which is the
- handler used by default to handle static content.
- (core)
-<LI><STRONG>send-as-is</STRONG>:
- Send file with HTTP headers as is.
- (<A HREF="mod/mod_asis.html">mod_asis</A>)
-<LI><STRONG>cgi-script</STRONG>:
- Treat the file as a CGI script.
- (<A HREF="mod/mod_cgi.html">mod_cgi</A>)
-<LI><STRONG>imap-file</STRONG>:
- Parse as an imagemap rule file.
- (<A HREF="mod/mod_imap.html">mod_imap</A>)
-<LI><STRONG>server-info</STRONG>:
- Get the server's configuration information.
- (<A HREF="mod/mod_info.html">mod_info</A>)
-<LI><STRONG>server-status</STRONG>:
- Get the server's status report.
- (<A HREF="mod/mod_status.html">mod_status</A>)
-<LI><STRONG>type-map</STRONG>:
- Parse as a type map file for content negotiation.
- (<A HREF="mod/mod_negotiation.html">mod_negotiation</A>)
-</UL>
-
-<hr>
-
-<h2><a name="examples">Examples</a></h2>
-
-<h3>Modifying static content using a CGI script</h3>
-
-<p>The following directives will cause requests for files with the
-<code>html</code> extension to trigger the launch of the
-<code>footer.pl</code> CGI script.</p>
-
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache's Handler Use</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Apache's Handler Use</h1>
+
+ <ul>
+ <li><a href="#definition">What is a Handler</a></li>
+
+ <li><a href="#examples">Examples</a></li>
+
+ <li><a href="#programmer">Programmer's Note</a></li>
+ </ul>
+ <hr />
+
+ <h2><a id="definition" name="definition">What is a
+ Handler</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_actions.html">mod_actions</a><br />
+ <a href="mod/mod_asis.html">mod_asis</a><br />
+ <a href="mod/mod_cgi.html">mod_cgi</a><br />
+ <a href="mod/mod_imap.html">mod_imap</a><br />
+ <a href="mod/mod_info.html">mod_info</a><br />
+ <a href="mod/mod_mime.html">mod_mime</a><br />
+ <a
+ href="mod/mod_negotiation.html">mod_negotiation</a><br />
+ <a href="mod/mod_status.html">mod_status</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_actions.html#action">Action</a><br />
+ <a
+ href="mod/mod_mime.html#addhandler">AddHandler</a><br />
+ <a
+ href="mod/mod_mime.html#removehandler">RemoveHandler</a><br />
+ <a
+ href="mod/mod_mime.html#sethandler">SetHandler</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>A "handler" is an internal Apache representation of the
+ action to be performed when a file is called. Generally, files
+ have implicit handlers, based on the file type. Normally, all
+ files are simply served by the server, but certain file types
+ are "handled" separately.</p>
+
+ <p>Apache 1.1 adds the ability to use handlers explicitly.
+ Based on either filename extensions or on location, handlers
+ can be specified without relation to file type. This is
+ advantageous both because it is a more elegant solution, and
+ because it also allows for both a type <strong>and</strong> a
+ handler to be associated with a file. (See also <a
+ href="mod/mod_mime.html#multipleext">Files with Multiple
+ Extensions</a>.)</p>
+
+ <p>Handlers can either be built into the server or included in
+ a module, or they can be added with the <a
+ href="mod/mod_actions.html#action">Action</a> directive. The
+ built-in handlers in the standard distribution are as
+ follows:</p>
+
+ <ul>
+ <li><strong>default-handler</strong>: Send the file using the
+ <code>default_handler()</code>, which is the handler used by
+ default to handle static content. (core)</li>
+
+ <li><strong>send-as-is</strong>: Send file with HTTP headers
+ as is. (<a href="mod/mod_asis.html">mod_asis</a>)</li>
+
+ <li><strong>cgi-script</strong>: Treat the file as a CGI
+ script. (<a href="mod/mod_cgi.html">mod_cgi</a>)</li>
+
+ <li><strong>imap-file</strong>: Parse as an imagemap rule
+ file. (<a href="mod/mod_imap.html">mod_imap</a>)</li>
+
+ <li><strong>server-info</strong>: Get the server's
+ configuration information. (<a
+ href="mod/mod_info.html">mod_info</a>)</li>
+
+ <li><strong>server-status</strong>: Get the server's status
+ report. (<a href="mod/mod_status.html">mod_status</a>)</li>
+
+ <li><strong>type-map</strong>: Parse as a type map file for
+ content negotiation. (<a
+ href="mod/mod_negotiation.html">mod_negotiation</a>)</li>
+ </ul>
+ <hr />
+
+ <h2><a id="examples" name="examples">Examples</a></h2>
+
+ <h3>Modifying static content using a CGI script</h3>
+
+ <p>The following directives will cause requests for files with
+ the <code>html</code> extension to trigger the launch of the
+ <code>footer.pl</code> CGI script.</p>
<pre>
Action add-footer /cgi-bin/footer.pl
AddHandler add-footer .html
</pre>
-<p>Then the CGI script is responsible for sending the originally
-requested document (pointed to by the <code>PATH_TRANSLATED</code>
-environment variable) and making whatever modifications or additions
-are desired.</p>
-
-<h3>Files with HTTP headers</h3>
+ <p>Then the CGI script is responsible for sending the
+ originally requested document (pointed to by the
+ <code>PATH_TRANSLATED</code> environment variable) and making
+ whatever modifications or additions are desired.</p>
-<p>The following directives will enable the <code>send-as-is</code>
-handler, which is used for files which contain their own HTTP headers.
-All files in the <code>/web/htdocs/asis/</code> directory will be
-processed by the <code>send-as-is</code> handler, regardless of their
-filename extensions.</p>
+ <h3>Files with HTTP headers</h3>
+ <p>The following directives will enable the
+ <code>send-as-is</code> handler, which is used for files which
+ contain their own HTTP headers. All files in the
+ <code>/web/htdocs/asis/</code> directory will be processed by
+ the <code>send-as-is</code> handler, regardless of their
+ filename extensions.</p>
<pre>
<Directory /web/htdocs/asis>
SetHandler send-as-is
</Directory>
</pre>
+ <hr />
-<hr>
-
-<H2><a name="programmer">Programmer's Note</a></H2>
+ <h2><a id="programmer" name="programmer">Programmer's
+ Note</a></h2>
-<P>In order to implement the handler features, an addition has been
-made to the <A HREF="misc/API.html">Apache API</A> that you may wish to
-make use of. Specifically, a new record has been added to the
-<CODE>request_rec</CODE> structure:</P>
-<PRE>
+ <p>In order to implement the handler features, an addition has
+ been made to the <a href="misc/API.html">Apache API</a> that
+ you may wish to make use of. Specifically, a new record has
+ been added to the <code>request_rec</code> structure:</p>
+<pre>
char *handler
-</PRE>
-<P>If you wish to have your module engage a handler, you need only to
-set <CODE>r->handler</CODE> to the name of the handler at any time
-prior to the <CODE>invoke_handler</CODE> stage of the
-request. Handlers are implemented as they were before, albeit using
-the handler name instead of a content type. While it is not
-necessary, the naming convention for handlers is to use a
-dash-separated word, with no slashes, so as to not invade the media
-type name-space.</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+
+ <p>If you wish to have your module engage a handler, you need
+ only to set <code>r->handler</code> to the name of the
+ handler at any time prior to the <code>invoke_handler</code>
+ stage of the request. Handlers are implemented as they were
+ before, albeit using the handler name instead of a content
+ type. While it is not necessary, the naming convention for
+ handlers is to use a dash-separated word, with no slashes, so
+ as to not invade the media type name-space.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache \e$B$N%O%s%I%i$N;HMQ\e(B</title>
-</HEAD>
-<!-- English revision: 1.22 -->
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000FF"
- vlink="#000080"
- alink="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="CENTER">Apache \e$B$N%O%s%I%i$N;HMQ\e(B</h1>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
-<ul>
-<li><a href="#definition">\e$B%O%s%I%i$H$O\e(B</a></li>
-<li><a href="#examples">\e$BNc\e(B</a></li>
-<li><a href="#programmer">\e$B%W%m%0%i%^8~$1$N%a%b\e(B</a></li>
-</ul>
+ <title>Apache $B$N%O%s%I%i$N;HMQ(B</title>
+ </head>
+ <!-- English revision: 1.22 -->
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<hr>
-<h2><a name="definition">\e$B%O%s%I%i$H$O\e(B</a></h2>
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
-<table border="1">
-<tr><td valign="top">
-<strong>\e$B4XO"%b%8%e!<%k\e(B</strong><br><br>
+ <h1 align="CENTER">Apache $B$N%O%s%I%i$N;HMQ(B</h1>
-<a href="mod/mod_actions.html">mod_actions</a><br>
-<a href="mod/mod_asis.html">mod_asis</a><br>
-<a href="mod/mod_cgi.html">mod_cgi</a><br>
-<a href="mod/mod_imap.html">mod_imap</a><br>
-<a href="mod/mod_info.html">mod_info</a><br>
-<a href="mod/mod_mime.html">mod_mime</a><br>
-<a href="mod/mod_negotiation.html">mod_negotiation</a><br>
-<a href="mod/mod_status.html">mod_status</a><br>
-</td>
-<td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
+ <ul>
+ <li><a href="#definition">$B%O%s%I%i$H$O(B</a></li>
-<a href="mod/mod_actions.html#action">Action</a><br>
-<a href="mod/mod_mime.html#addhandler">AddHandler</a><br>
-<a href="mod/mod_mime.html#removehandler">RemoveHandler</a><br>
-<a href="mod/mod_mime.html#sethandler">SetHandler</a><br>
-</td>
-</tr></table>
+ <li><a href="#examples">$BNc(B</a></li>
+ <li><a
+ href="#programmer">$B%W%m%0%i%^8~$1$N%a%b(B</a></li>
+ </ul>
+ <hr />
-<p>\e$B!V%O%s%I%i!W$H$O!"%U%!%$%k$,8F$P$l$?$H$-$K<B9T$5$l$kF0:n$N\e(B Apache \e$B$K$*$1$k\e(B
-\e$BFbItI=8=$G$9!#DL>o!"%U%!%$%k$O%U%!%$%k7?$K4p$E$$$?0EL[$N\e(B
-\e$B%O%s%I%i$,$"$j$^$9!#IaDL$O$9$Y$F$N%U%!%$%k$OC1$K%5!<%P$K07$o$l$^$9$,!"\e(B
-\e$B%U%!%$%k%?%$%W$NCf$K$OJL$K!V%O%s%I%k!W\e(B (\e$BLuCm\e(B: \e$B07$&\e(B) \e$B$5$l$k$b$N$b$"$j$^$9!#\e(B</p>
+ <h2><a id="definition"
+ name="definition">$B%O%s%I%i$H$O(B</a></h2>
-<p>Apache 1.1 \e$B$G$O!"%O%s%I%i$rL@<(E*$K;HMQ$9$k5!G=$,DI2C$5$l$^$7$?!#\e(B
-\e$B%U%!%$%k$N3HD%;R$dCV$$$F$$$k>l=j$K4p$E$$$F!"%U%!%$%k7?$H4X78$J$/%O%s%I%i$r\e(B
-\e$B;XDj$9$k$3$H$,$G$-$^$9!#$3$l$O$h$jM%2m$J2r7hK!$H$$$&E@$H!"%U%!%$%k$K\e(B
-\e$B%?%$%W\e(B<strong>\e$B$H\e(B</strong>\e$B%O%s%I%i$NN>J}$r4XO"IU$1$k$3$H$,$G$-$k$H$$$&\e(B
-
\e$BE@$GM%$l$F$$$^$9!#
\e(B (<a
-href="mod/mod_mime.html#multipleext">\e$BJ#?t$N3HD%;R$N$"$k%U%!%$%k\e(B</a>
-\e$B$b;2>H$7$F$/$@$5$$\e(B)\e$B!#\e(B</p>
-
-<p>\e$B%O%s%I%i$O%5!<%P$KAH$_9~$s$@$j!"%b%8%e!<%k$H$7$F4^$a$?$j!"\e(B
-<a href="mod/mod_actions.html#action">Action</a> \e$B%G%#%l%/%F%#%V$H$7$F\e(B
-\e$BDI2C$7$?$j$9$k$3$H$,$G$-$^$9!#0J2<$OI8=`G[I[$KAH$_9~$^$l$F$$$k%O%s%I%i$G$9!#\e(B</p>
-
-<ul>
-<li><strong>default-handler</strong>:
- <code>default_handelr()</code> \e$B$r;H$C$F%U%!%$%k$rAw$j$^$9!#\e(B
- \e$B@EE*$J%3%s%F%s%D$r07$&$H$-$K%G%U%)%k%H$G;HMQ$5$l$k%O%s%I%i$G$9!#\e(B
- (core)
-<li><strong>send-as-is</strong>:
- HTTP \e$B%X%C%@$N$"$k%U%!%$%k$r$=$N$^$^Aw$j$^$9!#\e(B
- (<a href="mod/mod_asis.html">mod_asis</a>)
-<li><strong>cgi-script</strong>:
- \e$B%U%!%$%k$r\e(B CGI \e$B%9%/%j%W%H$H$7$F07$$$^$9!#\e(B
- (<a href="mod/mod_cgi.html">mod_cgi</a>)
-<li><strong>imap-file</strong>:
- \e$B%$%a!<%8%^%C%W$N%k!<%k%U%!%$%k$H$7$F2r@O$7$^$9!#\e(B
- (<a href="mod/mod_imap.html">mod_imap</a>)
-<li><strong>server-info</strong>:
- \e$B%5!<%P$N@_Dj>pJs$r<hF@$7$^$9!#\e(B
- (<a href="mod/mod_info.html">mod_info</a>)
-<li><strong>server-status</strong>:
- \e$B%5!<%P$N>uBVJs9p$r<hF@$7$^$9!#\e(B
- (<a href="mod/mod_status.html">mod_status</a>)
-<li><strong>type-map</strong>:
- \e$B%3%s%F%s%H%M%4%7%(!<%7%g%s$N$?$a$N%?%$%W%^%C%W$H$7$F2r@O$7$^$9!#\e(B
- (<a href="mod/mod_negotiation.html">mod_negotiation</a>)
-</ul>
-
-<hr>
-
-<h2><a name="examples">\e$BNc\e(B</a></h2>
-
-<h3>CGI \e$B%9%/%j%W%H$rMQ$$$F@EE*$J%3%s%F%s%D$rJQ99$9$k\e(B</h3>
-
-<p>\e$B0J2<$N%G%#%l%/%F%#%V$K$h$C$F!"3HD%;R$,\e(B <code>html</code> \e$B$G$"$k%U%!%$%k$O\e(B
-<code>footer.pl</code> CGI \e$B%9%/%j%W%H$r5/F0$9$k$h$&$K$J$j$^$9!#\e(B</p>
-
-<pre>
- Action add-footer /cgi-bin/footer.pl
- AddHandler add-footer .html
-</pre>
-
-<p>CGI \e$B%9%/%j%W%H$OK>$^$7$$=$@5$dDI2C$r9T$J$C$F!"85!9MW5a$5$l$?J8=q\e(B
-(\e$B4D6-JQ?t\e(B <code>PATH_TRANSLATED</code> \e$B$G;X$5$l$F$$$^$9\e(B) \e$B$rAw$k@UG$$,$"$j$^$9!#\e(B</p>
-
-<h3>HTTP \e$B%X%C%@$N$"$k%U%!%$%k\e(B</h3>
-
-<p>\e$B0J2<$N%G%#%l%/%F%#%V$O\e(B <code>send-as-is</code> \e$B%O%s%I%i$r;HMQ$9$k\e(B
-\e$B$h$&$K;X<($7$^$9!#$3$N%O%s%I%i$O<+J,<+?H$N\e(B HTTP \e$B%X%C%@$r;}$C$F$$$k%U%!%$%k$K\e(B
-\e$B;HMQ$5$l$^$9!#$3$3$G$O!"3HD%;R$K4X$o$i$:!"\e(B<code>/web/htdocs/asis</code>
-\e$B%G%#%l%/%H%j$K$"$kA4$F$N%U%!%$%k$O\e(B <code>send-as-is</code> \e$B%O%s%I%i$K$h$C$F\e(B
-\e$B07$o$l$^$9!#\e(B</p>
-
-<pre>
- <Directory /web/htdocs/asis>
- SetHandler send-as-is
- </Directory>
-</pre>
-
-<hr>
-
-<h2><a name="programmer">\e$B%W%m%0%i%^8~$1$N%a%b\e(B</a></h2>
-
-<p>\e$B%O%s%I%i$N5!G=$r<BAu$9$k$?$a$K!"MxMQ$9$k$HJXMx$+$b$7$l$J$$$b$N$,\e(B
-<a href="misc/API.html">Apache API</a> \e$B$KDI2C$5$l$^$7$?!#\e(B
-\e$B>\$7$/8@$&$H!"\e(B<code>request_rec</code> \e$B9=B$BN$K?7$7$$%l%3!<%I$,\e(B
-\e$BDI2C$5$l$?$H$$$&$3$H$G$9!#\e(B</p>
-<pre>
- char *handler
-</pre>
-<p>\e$B$b$7%b%8%e!<%k$,%O%s%I%i$K4X$o$j$?$$>l9g!"$d$i$J$1$l$P$J$i$J$$$3$H$O!"\e(B
-\e$B%j%/%(%9%H$,\e(B <code>invoke_handler</code> \e$B%9%F!<%8$KC#$9$k0JA0$K\e(B
-<code>r->handler</code> \e$B$r@_Dj$9$k$3$H$@$1$G$9!#\e(B
-\e$B%O%s%I%i$O%3%s%F%s%H%?%$%W$NBe$o$j$K%O%s%I%iL>$r;H$&$h$&$K$J$C$F$$$k$3$H0J30$O!"\e(B
-\e$B0JA0$HF1$8$h$&$K<BAu$5$l$F$$$^$9!#I,$:MW5a$5$l$F$$$k$o$1$G$O$"$j$^$;$s$,!"\e(B
-\e$B%a%G%#%"%?%$%W$NL>A06u4V$r?/$5$J$$$h$&$K!"%O%s%I%i$NL>A0$K$O%9%i%C%7%e\e(B
-\e$B$r4^$^$J$$!"%@%C%7%e\e(B (\e$BLuCm\e(B: "-") \e$B$GJ,N%$5$l$?L>A0$rIU$1$k=,47$K$J$C$F$$$^$9!#\e(B</P>
-
-<!--#include virtual="footer.html" -->
-</body>
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>$B4XO"%b%8%e!</strong></td>
+ </tr>
+ </table>
+ </body>
</html>
+
-<DIV ALIGN="CENTER">
- <IMG SRC="images/sub.gif" ALT="[APACHE DOCUMENTATION]">
- <H3>
- Apache HTTP Server Version 2.0
- </H3>
-</DIV>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title></title>
+ </head>
+
+ <body>
+ <div align="CENTER">
+ <img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" />
+
+ <h3>Apache HTTP Server Version 2.0</h3>
+ </div>
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head><title>Apache HTTP Server Version 2.0 Documentation</title></head>
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000FF"
- vlink="#000080"
- alink="#FF0000"
->
-
-<div align="center">
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center">
- <img src="images/apache_header.gif" width=600 height=62 border=0 alt="[Apache Documentation]"></td>
-</tr>
-<tr>
-<td align="center" bgcolor="#4f4f4f">
- <table cellspacing="1" cellpadding="4" border="0" width="100%">
- <tr>
- <td align="center" bgcolor="#bebebe">
- <a href="faq/"><strong>FAQ</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="mod/directives.html"><strong>Directives</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="mod/"><strong>Modules</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="http://www.apache.org/search.html"><strong>Search</strong></a>
- </td>
- </tr></table>
-</td>
-</tr>
-<tr>
-<td> </td>
-</tr><tr>
-<td align="center" height="30">
- <h3>Apache HTTP Server Version 2.0</h3>
-</td>
-</tr>
-</table>
-</div>
-
-<div align="center">
-
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr><td align="center">
- <form method="post" action="http://search.apache.org/">
- <input type="hidden" name="what" value="httpd.apache.org">
- <input type="hidden" name="results" value="20">
- <input type="hidden" name="version" value="2">
- <input type="text" name="keyword" size="20">
- <input type="submit" value="Search">
- </form>
-</td></tr></table>
-
-<!--
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center"><hr size="1" noshade width="100%">
-</td>
-</tr>
-</table>
--->
-
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center" valign="top">
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
- <strong>Release Notes</strong>
-</td></tr><tr><td>
-<A HREF="new_features_2_0.html">New Features in Version 2.0</A>
-</td></tr><tr><td>
-<A HREF="upgrading.html">Upgrading to Version 2.0</A>
-</td></tr><tr><td>
-<A HREF="LICENSE">Apache License</A>
-</td></tr>
-</table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Reference Manual</strong>
-</td></tr><tr><td>
-<A HREF="install.html">Compiling and Installing</A>
-</td></tr><tr><td>
-<A HREF="invoking.html">Starting</A>
-</td></tr><tr><td>
-<A HREF="stopping.html">Stopping or Restarting</A>
-</td></tr><tr><td>
-<A HREF="mod/directives.html">Run-time Configuration Directives</A>
-</td></tr><tr><td>
-Modules: <A HREF="mod/index-bytype.html">By Type</A> or
- <A HREF="mod/">Alphabetical</A>
-</td></tr><tr><td>
-<a href="mpm.html">Multi-Processing Modules (MPMs)</a>
-</td></tr><tr><td>
-<a href="programs/">Server and Supporting Programs</a>
-</td></tr><tr><td>
-<A HREF="dso.html">Dynamic Shared Object (DSO) Support</A>
-</td></tr></table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Platform Specific Notes</strong>
-</td></tr><tr><td>
-<A HREF="platform/windows.html">Microsoft Windows</A>
-</td></tr></table>
-
-</td>
-<td align="center" valign="top" bgcolor="#cccccc">
-<table border="0" cellpadding="0" cellspacing="0" bgcolor="#cccccc"><tr><td
- align="center"><img src="images/pixel.gif" width="1" height="1"
- border="0" alt="."></td></tr></table>
-</td>
-<td align="center" valign="top">
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Using the Apache HTTP Server</strong>
-</td></tr><tr><td>
-<A HREF="configuring.html">Configuration Files</A>
-</td></tr><tr><td>
-<a href="server-wide.html">Server-Wide Configuration</A>
-</td></tr><tr><td>
-<A HREF="logs.html">Log Files</A>
-</td></tr><tr><td>
-<A HREF="urlmapping.html">Mapping URLs to the Filesystem</A>
-</td></tr><tr><td>
-<A HREF="vhosts/">Virtual Hosts</A>
-</td></tr><tr><td>
-<A HREF="howto/ssi.html">Server Side Includes</A>
-</td></tr><tr><td>
-<A HREF="howto/cgi.html">Dynamic Content with CGI</A>
-</td></tr><tr><td>
-<A HREF="handler.html">Handlers</A>
-</td></tr><tr><td>
-<A HREF="filter.html">Filters</A>
-</td></tr><tr><td>
-<A HREF="content-negotiation.html">Content negotiation</A>
-</td></tr><tr><td>
-<A HREF="env.html">Environment Variables</A>
-</td></tr><tr><td>
-<A HREF="suexec.html">Using SetUserID Execution for CGI</A>
-</td></tr><tr><td>
-<A HREF="misc/perf-tuning.html">General Performance hints</A>
-</td></tr><tr><td>
-<A HREF="misc/security_tips.html">Security tips</A>
-</td></tr><tr><td>
-<A HREF="misc/rewriteguide.html">URL Rewriting Guide</A>
-</td></tr></table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Other Topics</strong>
-</td></tr><tr><td>
-<A HREF="faq/">Frequently Asked Questions</A>
-</td></tr><tr><td>
-<A HREF="misc/tutorials.html">Tutorials</A>
-</td></tr><tr><td>
-<A HREF="developer/">Documentation for Developers</A>
-</td></tr><tr><td>
-<A HREF="misc/">Other Notes</A>
-</td></tr></table>
-</td>
-</tr>
-</table>
-
-</div>
-
-<p align="center">Maintained by the <a
-href="http://httpd.apache.org/docs-project/">Apache HTTP Server
-Documentation Project</a>.</p>
-
-<!--#include virtual="footer.html" -->
-</body>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache HTTP Server Version 2.0 Documentation</title>
+ </head>
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <div align="center">
+ <table cellspacing="0" cellpadding="0" border="0"
+ width="600">
+ <tr>
+ <td align="center"><img src="images/apache_header.gif"
+ width="600" height="62" border="0"
+ alt="[Apache Documentation]" /></td>
+ </tr>
+
+ <tr>
+ <td align="center" bgcolor="#4f4f4f">
+ <table cellspacing="1" cellpadding="4" border="0"
+ width="100%">
+ <tr>
+ <td align="center" bgcolor="#bebebe"><a
+ href="faq/"><strong>FAQ</strong></a> </td>
+
+ <td align="center" bgcolor="#bebebe"><a
+ href="mod/directives.html"><strong>Directives</strong></a>
+ </td>
+
+ <td align="center" bgcolor="#bebebe"><a
+ href="mod/"><strong>Modules</strong></a> </td>
+
+ <td align="center" bgcolor="#bebebe"><a
+ href="http://www.apache.org/search.html"><strong>Search</strong></a>
+ </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+
+ <tr>
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td align="center" height="30">
+ <h3>Apache HTTP Server Version 2.0</h3>
+ </td>
+ </tr>
+ </table>
+ </div>
+
+ <div align="center">
+ <table cellspacing="0" cellpadding="0" border="0"
+ width="600">
+ <tr>
+ <td align="center">
+ <form method="post" action="http://search.apache.org/">
+ <input type="hidden" name="what"
+ value="httpd.apache.org" /> <input type="hidden"
+ name="results" value="20" /> <input type="hidden"
+ name="version" value="2" /> <input type="text"
+ name="keyword" size="20" /> <input type="submit"
+ value="Search" />
+ </form>
+ </td>
+ </tr>
+ </table>
+ <!--
+ <table cellspacing="0" cellpadding="0" border="0" width="600">
+ <tr>
+ <td align="center"><hr size="1" noshade width="100%">
+ </td>
+ </tr>
+ </table>
+ -->
+
+ <table cellspacing="0" cellpadding="0" border="0"
+ width="600">
+ <tr>
+ <td align="center" valign="top">
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9">
+ <strong>Release Notes</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="new_features_2_0.html">New Features in
+ Version 2.0</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="upgrading.html">Upgrading to Version
+ 2.0</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="LICENSE">Apache License</a> </td>
+ </tr>
+ </table>
+
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9">
+ <strong>Reference Manual</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="install.html">Compiling and
+ Installing</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="invoking.html">Starting</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="stopping.html">Stopping or
+ Restarting</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="mod/directives.html">Run-time
+ Configuration Directives</a> </td>
+ </tr>
+
+ <tr>
+ <td>Modules: <a href="mod/index-bytype.html">By
+ Type</a> or <a href="mod/">Alphabetical</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="mpm.html">Multi-Processing Modules
+ (MPMs)</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="programs/">Server and Supporting
+ Programs</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="dso.html">Dynamic Shared Object (DSO)
+ Support</a> </td>
+ </tr>
+ </table>
+
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9">
+ <strong>Platform Specific Notes</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="platform/windows.html">Microsoft
+ Windows</a> </td>
+ </tr>
+ </table>
+ </td>
+
+ <td align="center" valign="top" bgcolor="#cccccc">
+ <table border="0" cellpadding="0" cellspacing="0"
+ bgcolor="#cccccc">
+ <tr>
+ <td align="center"><img src="images/pixel.gif"
+ width="1" height="1" border="0" alt="." /></td>
+ </tr>
+ </table>
+ </td>
+
+ <td align="center" valign="top">
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9"><strong>Using
+ the Apache HTTP Server</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="configuring.html">Configuration
+ Files</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="server-wide.html">Server-Wide
+ Configuration</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="logs.html">Log Files</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="urlmapping.html">Mapping URLs to the
+ Filesystem</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="vhosts/">Virtual Hosts</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="howto/ssi.html">Server Side
+ Includes</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="howto/cgi.html">Dynamic Content with
+ CGI</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="handler.html">Handlers</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="filter.html">Filters</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="content-negotiation.html">Content
+ negotiation</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="env.html">Environment Variables</a>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="suexec.html">Using SetUserID Execution
+ for CGI</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/perf-tuning.html">General
+ Performance hints</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/security_tips.html">Security
+ tips</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/rewriteguide.html">URL Rewriting
+ Guide</a> </td>
+ </tr>
+ </table>
+
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9"><strong>Other
+ Topics</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="faq/">Frequently Asked Questions</a>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/tutorials.html">Tutorials</a>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="developer/">Documentation for
+ Developers</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/">Other Notes</a> </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+ </table>
+ </div>
+
+ <p align="center">Maintained by the <a
+ href="http://httpd.apache.org/docs-project/">Apache HTTP Server
+ Documentation Project</a>.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<title>Documentation du serveur HTTP Apache version 2.0</title>
-</head>
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000FF"
- vlink="#000080"
- alink="#FF0000"
->
-
-<div align="center">
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center">
- <img src="images/apache_header.gif" width=600 height=62 border=0 alt="[Documentation Apache]"></td>
-</tr>
-<tr>
-<td align="center" bgcolor="#4f4f4f">
- <table cellspacing="1" cellpadding="4" border="0" width="100%">
- <tr>
- <td align="center" bgcolor="#bebebe">
- <a href="faq/"><strong>FAQ</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="mod/directives.html"><strong>Directives</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="mod/"><strong>Modules</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="http://www.apache.org/search.html"><strong>Rechercher</strong></a>
- </td>
- </tr></table>
-</td>
-</tr>
-<tr>
-<td> </td>
-</tr><tr>
-<td align="center" height="30">
- <h3>Serveur HTTP Apache version 2.0</h3>
-</td>
-</tr>
-</table>
-</div>
-
-<div align="center">
-
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr><td align="center">
- <form method="post" action="http://search.apache.org/">
- <input type="hidden" name="what" value="httpd.apache.org">
- <input type="hidden" name="results" value="20">
- <input type="hidden" name="version" value="2">
- <input type="text" name="keyword" size="20">
- <input type="submit" value="Chercher">
- </form>
-</td></tr></table>
-
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center" valign="top">
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
- <strong>Notes sur cette version</strong>
-</td></tr><tr><td>
-<A HREF="new_features_2_0.html">Nouvelles fonctionnalités de la version 2.0</A>
-</td></tr><tr><td>
-<A HREF="upgrading.html">Migrer vers la version 2.0</A>
-</td></tr><tr><td>
-<A HREF="LICENSE">Licence Apache</A>
-</td></tr>
-</table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Manuel de référence</strong>
-</td></tr><tr><td>
-<A HREF="install.html">Compilation et installation</A>
-</td></tr><tr><td>
-<A HREF="invoking.html">Démarrage</A>
-</td></tr><tr><td>
-<A HREF="stopping.html">Arrêt et redémarrage</A>
-</td></tr><tr><td>
-<A HREF="mod/directives.html">Directives de configuration de l'exécution</A>
-</td></tr><tr><td>
-Modules <A HREF="mod/index-bytype.html">par type</A> ou
- <A HREF="mod/">par ordre alphabétique</A>
-</td></tr><tr><td>
-<a href="mpm.html">Modules Multi-Traitements (MPMs)</a>
-</td></tr><tr><td>
-<A HREF="dso.html">Support des Objets partagés dynamiques (DSO)</A>
-</td></tr></table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Notes liées aux plates-formes</strong>
-</td></tr><tr><td>
-<A HREF="platform/windows.html">Microsoft Windows</A>
-</td></tr><tr><td>
-<A HREF="platform/">Autres notes pour plates-formes spécifiques</a>
-</td></tr></table>
-
-</td>
-<td align="center" valign="top" bgcolor="#cccccc">
-<table border="0" cellpadding="0" cellspacing="0" bgcolor="#cccccc"><tr><td
- align="center"><img src="images/pixel.gif" width="1" height="1"
- border="0" alt="."></td></tr></table>
-</td>
-<td align="center" valign="top">
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Utilisation du serveur HTTP Apache</strong>
-</td></tr><tr><td>
-<A HREF="configuring.html">Fichiers de configuration</A>
-</td></tr><tr><td>
-<a href="server-wide.html">Configuration globale du serveur</A>
-</td></tr><tr><td>
-<A HREF="vhosts/">Hôtes virtuels</A>
-</td></tr><tr><td>
-<A HREF="handler.html">Handlers</A>
-</td></tr><tr><td>
-<A HREF="content-negotiation.html">Négotiation de contenu</A>
-</td></tr><tr><td>
-<A HREF="env.html">Variables d'environnement</A>
-</td></tr><tr><td>
-<A HREF="suexec.html">Utilisation du SetUserID pour les CGI</A>
-</td></tr><tr><td>
-<A HREF="misc/perf-tuning.html">Aides sur les performances générales</A>
-</td></tr><tr><td>
-<A HREF="misc/security_tips.html">Trucs sur la sécurité</A>
-</td></tr><tr><td>
-<A HREF="misc/rewriteguide.html">Guide de réécriture d'URLs</A>
-</td></tr></table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Autres sujets</strong>
-</td></tr><tr><td>
-<A HREF="faq/">Foires aux questions</A>
-</td></tr><tr><td>
-<A HREF="misc/tutorials.html">Tutoriels</A>
-</td></tr><tr><td>
-<A HREF="developer/">Documentation pour les développeurs</A>
-</td></tr><tr><td>
-<A HREF="misc/">Autres notes</A>
-</td></tr></table>
-</td>
-</tr>
-</table>
-
-</div>
-
-<!--#include virtual="footer.html" -->
-</body>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+ <meta http-equiv="Content-Type"
+ content="text/html; charset=iso-8859-1" />
+
+ <title>Documentation du serveur HTTP Apache version 2.0</title>
+ </head>
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <div align="center">
+ <table cellspacing="0" cellpadding="0" border="0"
+ width="600">
+ <tr>
+ <td align="center"><img src="images/apache_header.gif"
+ width="600" height="62" border="0"
+ alt="[Documentation Apache]" /></td>
+ </tr>
+
+ <tr>
+ <td align="center" bgcolor="#4f4f4f">
+ <table cellspacing="1" cellpadding="4" border="0"
+ width="100%">
+ <tr>
+ <td align="center" bgcolor="#bebebe"><a
+ href="faq/"><strong>FAQ</strong></a> </td>
+
+ <td align="center" bgcolor="#bebebe"><a
+ href="mod/directives.html"><strong>Directives</strong></a>
+ </td>
+
+ <td align="center" bgcolor="#bebebe"><a
+ href="mod/"><strong>Modules</strong></a> </td>
+
+ <td align="center" bgcolor="#bebebe"><a
+ href="http://www.apache.org/search.html"><strong>Rechercher</strong></a>
+ </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+
+ <tr>
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td align="center" height="30">
+ <h3>Serveur HTTP Apache version 2.0</h3>
+ </td>
+ </tr>
+ </table>
+ </div>
+
+ <div align="center">
+ <table cellspacing="0" cellpadding="0" border="0"
+ width="600">
+ <tr>
+ <td align="center">
+ <form method="post" action="http://search.apache.org/">
+ <input type="hidden" name="what"
+ value="httpd.apache.org" /> <input type="hidden"
+ name="results" value="20" /> <input type="hidden"
+ name="version" value="2" /> <input type="text"
+ name="keyword" size="20" /> <input type="submit"
+ value="Chercher" />
+ </form>
+ </td>
+ </tr>
+ </table>
+
+ <table cellspacing="0" cellpadding="0" border="0"
+ width="600">
+ <tr>
+ <td align="center" valign="top">
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9"><strong>Notes
+ sur cette version</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="new_features_2_0.html">Nouvelles
+ fonctionnalités de la version 2.0</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="upgrading.html">Migrer vers la version
+ 2.0</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="LICENSE">Licence Apache</a> </td>
+ </tr>
+ </table>
+
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9"><strong>Manuel
+ de référence</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="install.html">Compilation et
+ installation</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="invoking.html">Démarrage</a>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="stopping.html">Arrêt et
+ redémarrage</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="mod/directives.html">Directives de
+ configuration de l'exécution</a> </td>
+ </tr>
+
+ <tr>
+ <td>Modules <a href="mod/index-bytype.html">par
+ type</a> ou <a href="mod/">par ordre
+ alphabétique</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="mpm.html">Modules Multi-Traitements
+ (MPMs)</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="dso.html">Support des Objets
+ partagés dynamiques (DSO)</a> </td>
+ </tr>
+ </table>
+
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9"><strong>Notes
+ liées aux plates-formes</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="platform/windows.html">Microsoft
+ Windows</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="platform/">Autres notes pour
+ plates-formes spécifiques</a> </td>
+ </tr>
+ </table>
+ </td>
+
+ <td align="center" valign="top" bgcolor="#cccccc">
+ <table border="0" cellpadding="0" cellspacing="0"
+ bgcolor="#cccccc">
+ <tr>
+ <td align="center"><img src="images/pixel.gif"
+ width="1" height="1" border="0" alt="." /></td>
+ </tr>
+ </table>
+ </td>
+
+ <td align="center" valign="top">
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9">
+ <strong>Utilisation du serveur HTTP Apache</strong>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="configuring.html">Fichiers de
+ configuration</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="server-wide.html">Configuration
+ globale du serveur</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="vhosts/">Hôtes virtuels</a>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="handler.html">Handlers</a> </td>
+ </tr>
+
+ <tr>
+ <td><a
+ href="content-negotiation.html">Négotiation
+ de contenu</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="env.html">Variables
+ d'environnement</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="suexec.html">Utilisation du SetUserID
+ pour les CGI</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/perf-tuning.html">Aides sur les
+ performances générales</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/security_tips.html">Trucs sur la
+ sécurité</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/rewriteguide.html">Guide de
+ réécriture d'URLs</a> </td>
+ </tr>
+ </table>
+
+ <table border="0" cellpadding="4" cellspacing="0"
+ bgcolor="#ffffff" width="280">
+ <tr>
+ <td align="center" bgcolor="#e9e9e9"><strong>Autres
+ sujets</strong> </td>
+ </tr>
+
+ <tr>
+ <td><a href="faq/">Foires aux questions</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/tutorials.html">Tutoriels</a>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="developer/">Documentation pour les
+ développeurs</a> </td>
+ </tr>
+
+ <tr>
+ <td><a href="misc/">Autres notes</a> </td>
+ </tr>
+ </table>
+ </td>
+ </tr>
+ </table>
+ </div>
+ <!--#include virtual="footer.html" -->
+ </body>
</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head><title>Apache HTTP \e$B%5!<%P\e(B \e$B%P!<%8%g%s\e(B 2.0 \e$B%I%-%e%a%s%H\e(B</title></head>
-<!-- English revision: 1.21 -->
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000FF"
- vlink="#000080"
- alink="#FF0000"
->
-<div align="center">
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center">
- <img src="images/apache_header.gif" width=600 height=62 border=0 alt="[Apache \e$B%I%-%e%a%s%H\e(B]"></td>
-</tr>
-<tr>
-<td align="center" bgcolor="#4f4f4f">
- <table cellspacing="1" cellpadding="4" border="0" width="100%">
- <tr>
- <td align="center" bgcolor="#bebebe">
- <a href="faq/"><strong>FAQ</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="mod/directives.html"><strong>\e$B%G%#%l%/%F%#%V\e(B</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="mod/"><strong>\e$B%b%8%e!<%k\e(B</strong></a>
- </td>
- <td align="center" bgcolor="#bebebe">
- <a href="http://www.apache.org/search.html"><strong>\e$B8!:w\e(B</strong></a>
- </td>
- </tr></table>
-</td>
-</tr>
-<tr>
-<td> </td>
-</tr><tr>
-<td align="center" height="30">
- <h3>Apache HTTP Server Version 2.0</h3>
-</td>
-</tr>
-</table>
-</div>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<div align="center">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr><td align="center">
- <form method="post" action="http://search.apache.org/">
- <input type="hidden" name="what" value="httpd.apache.org">
- <input type="hidden" name="results" value="20">
- <input type="hidden" name="version" value="2">
- <input type="text" name="keyword" size="20">
- <input type="submit" value="Search">
- </form>
-</td></tr></table>
-
-<!--
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center"><hr size="1" noshade width="100%">
-</td>
-</tr>
-</table>
--->
-
-<table cellspacing="0" cellpadding="0" border="0" width="600">
-<tr>
-<td align="center" valign="top">
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
- <strong>\e$B%j%j!<%9%N!<%H\e(B</strong>
-</td></tr><tr><td>
-<a href="new_features_2_0.html">Apache 2.0 \e$B$N?75!G=\e(B</a>
-</td></tr><tr><td>
-<a href="upgrading.html">Apache 2.0 \e$B$X$N%"%C%W%0%l!<%I\e(B</a>
-</td></tr><tr><td>
-<a href="LICENSE">Apache \e$B$N%i%$%;%s%9\e(B</a>
-</td></tr>
-</table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>\e$B%j%U%!%l%s%9%^%K%e%"%k\e(B</strong>
-</td></tr><tr><td>
-<a href="install.html">\e$B%3%s%Q%$%k$H%$%s%9%H!<%k\e(B</a>
-</td></tr><tr><td>
-<a href="invoking.html">\e$B5/F0\e(B</a>
-</td></tr><tr><td>
-<a href="stopping.html">\e$B=*N;$^$?$O:F5/F0\e(B</a>
-</td></tr><tr><td>
-<a href="mod/directives.html">\e$B<B9T;~$N@_DjJ}K!\e(B</a>
-</td></tr><tr><td>
-
\e$B%b%8%e!<%k
\e(B: <a href="mod/index-bytype.html">
\e$B<oN`JL
\e(B</a>
\e$B$H
\e(B
- <a href="mod/">\e$B%"%k%U%!%Y%C%H=g\e(B</a>
-</td></tr><tr><td>
-<a href="mpm.html">Multi-Processing Modules (MPM)</a>
-</td></tr><tr><td>
-<a href="programs/">\e$B%5!<%P$H%5%]!<%H%W%m%0%i%`\e(B</a>
-</td></tr><tr><td>
-<a href="dso.html">Dynamic Shared Object (DSO) \e$B$N%5%]!<%H\e(B</a>
-</td></tr></table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>\e$B%W%i%C%H%U%)!<%`8GM-$N>pJs\e(B</strong>
-</td></tr><tr><td>
-<a href="platform/windows.html">Microsoft Windows</a>
-</td></tr><tr><td>
-<a href="platform/">\e$BB>$N%W%i%C%H%U%)!<%`FCM-$N>pJs\e(B</a>
-</td></tr></table>
-
-</td>
-<td align="center" valign="top" bgcolor="#cccccc">
-<table border="0" cellpadding="0" cellspacing="0" bgcolor="#cccccc"><tr><td
- align="center"><img src="images/pixel.gif" width="1" height="1"
- border="0" alt="."></td></tr></table>
-</td>
-<td align="center" valign="top">
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>Apache HTTP \e$B%5!<%P$r;H$&\e(B</strong>
-</td></tr><tr><td>
-<a href="configuring.html">\e$B@_Dj%U%!%$%k\e(B</a>
-</td></tr><tr><td>
-<a href="server-wide.html">\e$B%5!<%PA4BN$N@_Dj\e(B</a>
-</td></tr><tr><td>
-<a href="urlmapping.html">URL
\e$B$r%U%!%$%k%7%9%F%`$K%^%C%W$9$k
\e(B<a>
-</td></tr><tr><td>
-<a href="vhosts/">\e$B%P!<%A%c%k%[%9%H\e(B</a>
-</td></tr><tr><td>
-<a href="handler.html">\e$B%O%s%I%i\e(B</a>
-</td></tr><tr><td>
-<a href="filter.html">\e$B%U%#%k%?\e(B</a>
-</td></tr><tr><td>
-<a href="content-negotiation.html">\e$B%3%s%F%s%H%M%4%7%(!<%7%g%s\e(B</a>
-</td></tr><tr><td>
-<a href="env.html">\e$B4D6-JQ?t\e(B</a>
-</td></tr><tr><td>
-<a href="suexec.html">CGI \e$B$G\e(B SetUserID \e$B<B9T$r;H$&\e(B</a>
-</td></tr><tr><td>
-<a href="misc/perf-tuning.html">\e$B0lHLE*$J@-G=$K4X$9$k%R%s%H\e(B</a>
-</td></tr><tr><td>
-<a href="misc/security_tips.html">\e$B%;%-%e%j%F%#>pJs\e(B</a>
-</td></tr><tr><td>
-<a href="misc/rewriteguide.html">URL Rewriting \e$B$N%,%$%I\e(B</a>
-</td></tr></table>
-
-<p>
-<table border="0" cellpadding="4" cellspacing="0" bgcolor="#ffffff" width="280">
-<tr><td align="center" bgcolor="#e9e9e9">
-<strong>\e$B$=$NB>\e(B</strong>
-</td></tr><tr><td>
-<a href="faq/">FAQ</a>
-</td></tr><tr><td>
-<a href="misc/tutorials.html">\e$B%A%e!<%H%j%"%k\e(B</a>
-</td></tr><tr><td>
-<a href="developer/">\e$B3+H/<T$N$?$a$N%I%-%e%a%s%H\e(B</a>
-</td></tr><tr><td>
-<a href="misc/">\e$B$=$NB>\e(B</a>
-</td></tr></table>
-</td>
-</tr>
-</table>
-
-</div>
-
-<p align="center"><a
-href="http://httpd.apache.org/docs-project/">Apache HTTP Server
-Documentation Project</a> \e$B$K$h$j%a%s%F%J%s%9$5$l$F$$$^$9!#\e(B</p>
-
-<!--#include virtual="footer.html" -->
-</body>
+ <title>Apache HTTP $B%5!</title>
+ </head>
</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Compiling and Installing Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">Compiling and Installing</H1>
-
-
-<p>This document covers compilation and installation of Apache on Unix
-and Unix-like systems only. For compiling and installation on Windows,
-see <A HREF="platform/windows.html">Using Apache with Microsoft
-Windows</A>. For other platforms, see the <a
-href="platform/">platform</a> documentation.</p>
-
-<p>Apache 2.0's configuration and installation environment has changed
-completely from Apache 1.3. Apache 1.3 used a custom set of scripts
-to achieve easy installation. Apache 2.0 now uses libtool and
-autoconf to create an environment that looks like many other Open
-Source projects.</p>
-
-<ul>
-<li><a href="#overview">Overview for the impatient</a></li>
-<li><a href="#requirements">Requirements</a></li>
-<li><a href="#download">Download</a></li>
-<li><a href="#extract">Extract</a></li>
-<li><a href="#configure">Configuring the source tree</a>
- <ul>
- <li><a href="#environment">Environment Variables</a></li>
- <li><a href="#output">autoconf Output Options</a></li>
- <li><a href="#pathnames">Pathnames</a></li>
- <li><a href="#modules">Modules</a></li>
- <li><a href="#suexec">Suexec</a></li>
- </ul></li>
-<li><a href="#compile">Build</a></li>
-<li><a href="#install">Install</a></li>
-<li><a href="#customize">Customize</a></li>
-<li><a href="#test">Test</a></li>
-</ul>
-
-<hr>
-
-<h3><a name="overview">Overview for the impatient</a></h3>
-
-<table>
-<tr><td><a href="#download">Download</a></td>
-<td><code>$ lynx http://www.apache.org/dist/httpd/httpd-2_0_<em>NN</em>.tar.gz
-</code></td></tr>
-
-<tr><td><a href="#extract">Extract</a></td>
-<td><code>$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br>
-$ tar xvf httpd-2_0_<em>NN</em>.tar
-</code></td></tr>
-
-<tr><td><a href="#configure">Configure</a></td>
-<td><code>$ ./configure --prefix=<em>PREFIX</em>
-</code></td></tr>
-
-<tr><td><a href="#compile">Compile</a></td>
-<td><code>$ make
-</code></td></tr>
-
-<tr><td><a href="#install">Install</a></td>
-<td><code>$ make install
-</code></td></tr>
-
-<tr><td><a href="#customize">Customize</a></td>
-<td><code>$ vi <em>PREFIX</em>/conf/httpd.conf
-</code></td></tr>
-
-<tr><td><a href="#test">Test</a></td>
-<td><code>$ <em>PREFIX</em>/bin/apachectl start
-</code></td></tr>
-
-</table>
-
-<p><em>NN</em> must be replaced with the current minor version number,
-and <em>PREFIX</em> must be replaced with the filesystem path under
-which the server should be installed. If <em>PREFIX</em> is not
-specified, it defaults to <code>/usr/local/apache2</code>.</p>
-
-<p>Each section of the compilation and installation process is
-described in more detail below, beginning with the requirements
-for compiling and installing Apache HTTPD.</p>
-
-<h3><a name="requirements">Requirements</a></h3>
-
-<p>The following requirements exist for building Apache:</p>
-
-<ul>
-
-<li>Disk Space<br><br> Make sure you have at least 50 MB of temporary
-free disk space available. After installation Apache occupies
-approximately 10 MB of disk space. The actual disk space requirements
-will vary considerably based on your chosen configuration options and
-any third-party modules.<br><br></li>
-
-<li>ANSI-C Compiler and Build System<br><br> Make sure you have an
-ANSI-C compiler installed. The <a
-href="http://www.gnu.org/software/gcc/gcc.html">GNU C compiler
-(GCC)</a> from the <a href="http://www.gnu.org/">Free Software
-Foundation (FSF)</a> is recommended (version 2.7.2 is fine). If you
-don't have GCC then at least make sure your vendor's compiler is ANSI
-compliant. In addition, your <code>PATH</code> must contain basic
-build tools such as <code>make</code>.<br><br></li>
-
-<li>Accurate time keeping<br><br> Elements of the HTTP protocol are
-expressed as the time of day. So, it's time to investigate setting
-some time synchronization facility on your system. Usually the ntpdate
-or xntpd programs are used for this purpose which are based on the
-Network Time Protocol (NTP). See the Usenet newsgroup <a
-href="news:comp.protocols.time.ntp">comp.protocols.time.ntp</a> and
-the <a href="http://www.eecis.udel.edu/~ntp/">NTP homepage</a> for more
-details about NTP software and public time servers.<br><br></li>
-
-<li><a href="http://www.perl.org/">Perl 5</a> [OPTIONAL]<br><br> For
-some of the support scripts like <a href="programs/apxs.html">apxs</a>
-or <a href="programs/dbmmanage.html">dbmmanage</a> (which are written
-in Perl) the Perl 5 interpreter is required (versions 5.003 and 5.004
-are fine). If no such interpreter is found by the `configure' script
-there is no harm. Of course, you still can build and install Apache
-2.0. Only those support scripts cannot be used. If you have multiple
-Perl interpreters installed (perhaps a Perl 4 from the vendor and a
-Perl 5 from your own), then it is recommended to use the --with-perl
-option (see below) to make sure the correct one is selected by
-./configure. <br><br></li>
-
-</ul>
-
-<h3><a name="download">Download</a></h3>
-
-<p>Apache can be downloaded from the <a
-href="http://www.apache.org/dist/httpd/">Apache Software Foundation
-download site</a> or from a <a
-href="http://www.apache.org/dyn/closer.cgi">nearby mirror</a>.</p>
-
-<p>Version numbers that end in <code>alpha</code> indicate early
-pre-test versions which may or may not work. Version numbers ending
-in <code>beta</code> indicate more reliable releases that still
-require further testing or bug fixing. If you wish to download the
-best available production release of the Apache HTTP Server, you
-should choose the latest version with neither <code>alpha</code> nor
-<code>beta</code> in its filename.</p>
-
-<p>After downloading, especially if a mirror site is used, it is
-important to verify that you have a complete and unmodified version of
-the Apache HTTP Server. This can be accomplished by testing the
-downloaded tarball against the PGP signature. This, in turn, is a two
-step procedure. First, you must obtain the <code>KEYS</code> file
-from the <a href="http://www.apache.org/dist/">Apache distribution
-site</a>. (To assure that the <code>KEYS</code> file itself has not
-been modified, it may be a good idea to use a file from a previous
-distribution of Apache or import the keys from a public key server.)
-The keys are imported into your personal key ring using
-one of the following commands (depending on your pgp version):</p>
-<blockquote><code>
-$ pgp < KEYS
-</code></blockquote>
-or
-<blockquote><code>
-$ gpg --import KEYS
-</code></blockquote>
-
-<p>The next step is to test the tarball against the PGP signature,
-which should always be obtained from the <a
-href="http://www.apache.org/dist/httpd">main Apache website</a>. The
-signature file has a filename identical to the source tarball with the
-addition of <code>.asc</code>. Then you can check the distribution
-with one of the following commands (again, depending on your pgp
-version):</p>
-<blockquote><code>
-$ pgp httpd-2_0_<em>NN</em>.tar.gz.asc
-</code></blockquote>
-or
-<blockquote><code>
-$ gpg --verify httpd-2_0_<em>NN</em>.tar.gz.asc
-</code></blockquote
-
-<p>You should receive a message like</p>
-<blockquote><code>
-Good signature from user "Martin Kraemer <martin@apache.org>".
-</code></blockquote>
-<p>Depending on the trust relationships contained
-in your key ring, you may also receive a message saying that
-the relationship between the key and the signer of the key
-cannot be verified. This is not a problem if you trust the
-authenticity of the <code>KEYS</code> file.</p>
-
-<h3><a name="extract">Extract</a></h3>
-
-<p>Extracting the source from the Apache HTTPD tarball is a simple
-matter of uncompressing, and then untarring:</p>
-
-<blockquote><code>
-$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br>
-$ tar xvf httpd-2_0_<em>NN</em>.tar
-</code></blockquote>
-
-<p>This will create a new directory under the current directory
-containing the source code for the distribution. You should
-<code>cd</code> into that directory before proceeding with
-compiling the server.</p>
-
-<h3><a name="configure">Configuring the source tree</a></h3>
-
-<p>The next step is to configure the Apache source tree for your
-particular platform and personal requirements. This is done using the
-script <code>configure</code> included in the root directory of the
-distribution. (Developers downloading the CVS version of the Apache
-source tree will need to have <code>autoconf</code> and
-<code>libtool</code> installed and will need to run
-<code>buildconf</code> before proceeding with the next steps. This is
-not necessary for official releases.)</p>
-
-<p>To configure the source tree using all the default options, simply
-type <code>./configure</code>. To change the default options,
-<code>configure</code> accepts a variety of variables and command line
-options. Environment variables are generally placed before the
-<code>./configure</code> command, while other options are placed
-after. The most important option here is the location prefix where
-Apache is to be installed later, because Apache has to be configured
-for this location to work correctly. But there are a lot of other
-options available for your pleasure.</p>
-
-<p>For a short impression of what possibilities you have, here is a
-typical example which compiles Apache for the installation tree
-/sw/pkg/apache with a particular compiler and flags plus the two
-additional modules mod_rewrite and mod_speling for later loading
-through the DSO mechanism:</p>
-
-<blockquote><code>
- $ CC="pgcc" CFLAGS="-O2" \<br>
- ./configure --prefix=/sw/pkg/apache \<br>
- --enable-rewrite=shared \<br>
- --enable-speling=shared
-</code></blockquote>
-
-<p>When configure is run it will take several minutes to test for
-the availability of features on your system and build Makefiles
-which will later be used to compile the server.</p>
-
-<p>The easiest way to find all of the configuration flags for Apache
-is to run ./configure --help. What follows is a brief description
-of most of the arguments and environment variables.</p>
-
-<h4><a name="environment">Environment Variables</a></h4>
-
-<p>The autoconf build process uses several environment variables to
-configure the build environment. In general, these variables change
-the method used to build Apache, but not the eventual features of the
-server. These variables can be placed in the environment before
-invoking <code>configure</code>, but it is usually easier to specify
-them on the <code>configure</code> command line as demonstrated
-in the example above.</p>
-
-<dl>
-
-<dt><code>CC=...</code></dt>
-<dd>The name of the C compiler command.</dd>
-
-<dt><code>CPPFLAGS=...</code></dt> <dd>Miscellaneous C preprocessor
-and compiler options.</dd>
-
-<dt><code>CFLAGS=...</code></dt>
-<dd>Debugging and optimization options for the C compiler.</dd>
-
-<dt><code>LDFLAGS=...</code></dt>
-<dd>Miscellaneous options to be passed to the linker.</dd>
-
-<dt><code>LIBS=...</code></dt>
-<dd>Library location information ("-L" and "-l" options)
-to pass to the linker.</dd>
-
-<dt><code>INCLUDES=...</code></dt>
-<dd>Header file search directories ("-I<em>dir</em>").</dd>
-
-<dt><code>TARGET=...</code> [Default: apache]</dt>
-<dd>Name of the executable which will be built.</dd>
-
-<dt><code>NOTEST_CPPFLAGS=...</code></dt>
-<dt><code>NOTEST_CFLAGS=...</code></dt>
-<dt><code>NOTEST_LDFLAGS=...</code></dt>
-<dt><code>NOTEST_LIBS=...</code></dt>
-<dd>These variables share the same function as their non-NOTEST namesakes.
-However, the variables are applied to the build process only after
-autoconf has performed its feature testing. This allows the inclusion of
-flags which will cause problems during feature testing, but must be used
-for the final compilation.</dd>
-
-<dt><code>SHLIB_PATH=...</code></dt>
-<dd>Options which specify shared library paths for the compiler and
-linker.</dd>
-
-</dl>
-
-<h4><a name="output">autoconf Output Options</a></h4>
-
-<dl>
-
-<dt><code>--help</code></dt>
-<dd>Prints the usage message including all available options, but
-does not actually configure anything.</dd>
-
-<dt><code>--quiet</code></dt>
-<dd>Prevents the printing of the usual "checking..." messages.</dd>
-
-<dt><code>--verbose</code></dt>
-<dd>Prints much more information during the configuration process,
-including the names of all the files examined.</dd>
-
-</dl>
-
-<h4><a name="pathnames">Pathnames</a></h4>
-
-<p>There are currently two ways to configure the pathnames under
-which Apache will install its files. First, you can specify
-a directory and have Apache install itself under that directory
-in its default locations.</p>
-
-<dl>
-<dt><code>--prefix=<em>PREFIX</em></code> [Default:
-/usr/local/apache2]</dt>
-<dd>Specifies the directory under which the Apache files will be
-installed.</dd>
-</dl>
-
-<p>It is possible to specify that architecture-dependent files should
-be placed under a different directory.</p>
-
-<dl>
-<dt><code>--exec-prefix=<em>EPREFIX</em></code> [Default:
-<em>PREFIX</em>]</dt>
-<dd>Specifies the directory under which architecture-dependent files
-will be placed.</dd>
-</dl>
-
-<p>The second, and more flexible way to configure the install path
-locations for Apache is using the <code>config.layout</code> file.
-Using this method, it is possible to separately specify the location
-for each type of file within the Apache installation. The
-<code>config.layout</code> file contains several example
-configurations, and you can also create your own custom configuration
-following the examples. The different layouts in this file are
-grouped into <code><Layout FOO>...</Layout></code>
-sections and referred to by name as in <code>FOO</code>.</p>
-
-<dl>
-
-<dt><code>--enable-layout=<em>LAYOUT</em></code></dt>
-<dd>Use the named layout in the <code>config.layout</code> file
-to specify the installation paths.</dd>
-
-</dl>
-
-<p>Presently it is not possible to mix the
-<code>--enable-layout</code> and <code>--prefix</code> options. Nor
-is it possible to individually specify detailed pathnames on the
-<code>configure</code> command line. If you want just a basic
-install, you can simply use the <code>--prefix</code> option on its
-own. If you want to customize your install, you should edit the
-<code>config.layout</code> file and use the
-<code>--enable-layout</code> option.</p>
-
-<h4><a name="modules">Modules</a></h4>
-
-<p>Apache is a modular server. Only the most basic functionality is
-included in the core server. Extended features are available in
-various modules. During the configuration process, you must select
-which modules to compile for use with your server. You can view a <a
-href="mod/index-bytype.html">list of modules</a> included in the
-documentation. Those modules with a <a
-href="mod/module-dict.html#Status">status</a>
-of "Base" are included by default and must be specifically disabled if
-you do not want them. Modules with any other status must be
-specifically enabled if you wish to use them.</p>
-
-<p>There are two ways for a module to be compiled and used with
-Apache. Modules may be <em>statically compiled</em>, which means that
-they are permanently included in the Apache binary. Alternatively, if
-your operating system supports Dynamic Shared Objects (DSOs) and
-autoconf can detect that support, then modules may be <em>dynamically
-compiled</em>. DSO modules are stored separately from the Apache
-binary, and may be included or excluded from the server using the
-run-time configuration directives provided by <a
-href="mod/mod_so.html">mod_so</a>. The mod_so is automatically
-included in the server if any dynamic modules are included in the
-compilation. If you would like to make your server capable of loading
-DSOs without actually compiling any dynamic modules, you can
-explicitly <code>--enable-so</code>.</p>
-
-<dl>
-
-<dt><code>--enable-<em>MODULE</em>[=shared]</code></dt> <dd>Compile
-and include the module <em>MODULE</em>. The identifier
-<em>MODULE</em> is the <a
-href="mod/module-dict.html#ModuleIdentifier"
->Module Identifier</a> from the module documentation without the
-"_module" string. To compile the module as a DSO, add the
-option <code>=shared</code>.</dd>
-
-<dt><code>--disable-<em>MODULE</em></code></dt>
-<dd>Remove the module <em>MODULE</em> which would otherwise be
-compiled and included.</dd>
-
-<dt><code>--enable-modules=<em>MODULE-LIST</em></code> <dd>Compile and
-include the modules listed in the space-separated
-<em>MODULE-LIST</em>.</dd>
-
-<dt><code>--enable-mods-shared=<em>MODULE-LIST</em></code> <dd>Compile
-and include the modules in the space-separated <em>MODULE-LIST</em> as
-dynamically loadable (DSO) modules.</dd>
-
-</dl>
-
-<p>The <em>MODULE-LIST</em> in the <code>--enable-modules</code> and
-<code>--enable-mods-shared</code> options is usually a space-separated list
-of module identifiers. For example, to enable mod_dav and mod_info, you
-can either use</p>
-<blockquote><code>
-./configure --enable-dav --enable-info
-</code></blockquote>
-<p>or, equivalently,</p>
-<blockquote><code>
-./configure --enable-modules="dav info"
-</code></blockquote>
-<p>In addition, the special keywords <code>all</code>
-or <code>most</code> can be used to add all or most of the modules
-in one step. You can then remove any modules that you do not want
-with the <code>--disable-<em>MODULE</em></code> option. For example,
-to include all modules as DSOs with the exception of mod_info, you can use</p>
-<blockquote><code>
-./configure --enable-mods-shared=all --disable-info
-</code></blockquote>
-
-<p>In addition to the standard set of modules, Apache 2.0 also
-includes a choice of <a href="mpm.html">Multi-Processing Modules</a>
-(MPMs). One, and only one MPM must be included in the compilation
-process. The default MPMs for each platform are listed on the <a
-href="mpm.html">MPM documentation page</a>, but can be overridden
-on the <code>configure</code> command line.
-
-<dl>
-
-<dt><code>--with-mpm=<em>NAME</em></code></dt>
-<dd>Choose the mpm <em>NAME</em>.
-
-</dl>
-
-<h4><a name="suexec">Suexec</a></h4>
-
-<p>Apache includes a support program called <a
-href="suexec.html">suexec</a> which can be used to isolate user CGI
-programs. However, if suexec is improperly configured, it can cause
-serious security problems. Therefore, you should carefully read and
-consider the <a href="suexec.html">suexec documentation</a> before
-implementing this feature.</p>
-
-
-<h3><a name="compile">Build</a></h3>
-
-<p>Now you can build the various parts which form the Apache package
-by simply running the command:</p>
-
-<blockquote><code>
- $ make
-</code></blockquote>
-
-<p>Please be patient here, since a base configuration takes
-approximately 3 minutes to compile under a Pentium III/Linux 2.2
-system, but this will vary widely depending on your hardware and the
-number of modules which you have enabled.</p>
-
-
-<h3><a name="install">Install</a></h3>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Compiling and Installing Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Compiling and Installing</h1>
+
+ <p>This document covers compilation and installation of Apache
+ on Unix and Unix-like systems only. For compiling and
+ installation on Windows, see <a
+ href="platform/windows.html">Using Apache with Microsoft
+ Windows</a>. For other platforms, see the <a
+ href="platform/">platform</a> documentation.</p>
+
+ <p>Apache 2.0's configuration and installation environment has
+ changed completely from Apache 1.3. Apache 1.3 used a custom
+ set of scripts to achieve easy installation. Apache 2.0 now
+ uses libtool and autoconf to create an environment that looks
+ like many other Open Source projects.</p>
+
+ <ul>
+ <li><a href="#overview">Overview for the impatient</a></li>
+
+ <li><a href="#requirements">Requirements</a></li>
+
+ <li><a href="#download">Download</a></li>
+
+ <li><a href="#extract">Extract</a></li>
+
+ <li>
+ <a href="#configure">Configuring the source tree</a>
+
+ <ul>
+ <li><a href="#environment">Environment Variables</a></li>
+
+ <li><a href="#output">autoconf Output Options</a></li>
+
+ <li><a href="#pathnames">Pathnames</a></li>
+
+ <li><a href="#modules">Modules</a></li>
+
+ <li><a href="#suexec">Suexec</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#compile">Build</a></li>
+
+ <li><a href="#install">Install</a></li>
+
+ <li><a href="#customize">Customize</a></li>
+
+ <li><a href="#test">Test</a></li>
+ </ul>
+ <hr />
+
+ <h3><a id="overview" name="overview">Overview for the
+ impatient</a></h3>
+
+ <table>
+ <tr>
+ <td><a href="#download">Download</a></td>
+
+ <td><code>$ lynx
+ http://www.apache.org/dist/httpd/httpd-2_0_<em>NN</em>.tar.gz</code>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="#extract">Extract</a></td>
+
+ <td><code>$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br />
+ $ tar xvf httpd-2_0_<em>NN</em>.tar</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#configure">Configure</a></td>
+
+ <td><code>$ ./configure --prefix=<em>PREFIX</em></code>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="#compile">Compile</a></td>
+
+ <td><code>$ make</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#install">Install</a></td>
+
+ <td><code>$ make install</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#customize">Customize</a></td>
+
+ <td><code>$ vi <em>PREFIX</em>/conf/httpd.conf</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#test">Test</a></td>
+
+ <td><code>$ <em>PREFIX</em>/bin/apachectl start</code>
+ </td>
+ </tr>
+ </table>
+
+ <p><em>NN</em> must be replaced with the current minor version
+ number, and <em>PREFIX</em> must be replaced with the
+ filesystem path under which the server should be installed. If
+ <em>PREFIX</em> is not specified, it defaults to
+ <code>/usr/local/apache2</code>.</p>
+
+ <p>Each section of the compilation and installation process is
+ described in more detail below, beginning with the requirements
+ for compiling and installing Apache HTTPD.</p>
+
+ <h3><a id="requirements"
+ name="requirements">Requirements</a></h3>
+
+ <p>The following requirements exist for building Apache:</p>
+
+ <ul>
+ <li>Disk Space<br />
+ <br />
+ Make sure you have at least 50 MB of temporary free disk
+ space available. After installation Apache occupies
+ approximately 10 MB of disk space. The actual disk space
+ requirements will vary considerably based on your chosen
+ configuration options and any third-party modules.<br />
+ <br />
+ </li>
+
+ <li>ANSI-C Compiler and Build System<br />
+ <br />
+ Make sure you have an ANSI-C compiler installed. The <a
+ href="http://www.gnu.org/software/gcc/gcc.html">GNU C
+ compiler (GCC)</a> from the <a
+ href="http://www.gnu.org/">Free Software Foundation (FSF)</a>
+ is recommended (version 2.7.2 is fine). If you don't have GCC
+ then at least make sure your vendor's compiler is ANSI
+ compliant. In addition, your <code>PATH</code> must contain
+ basic build tools such as <code>make</code>.<br />
+ <br />
+ </li>
+
+ <li>Accurate time keeping<br />
+ <br />
+ Elements of the HTTP protocol are expressed as the time of
+ day. So, it's time to investigate setting some time
+ synchronization facility on your system. Usually the ntpdate
+ or xntpd programs are used for this purpose which are based
+ on the Network Time Protocol (NTP). See the Usenet newsgroup
+ <a
+ href="news:comp.protocols.time.ntp">comp.protocols.time.ntp</a>
+ and the <a href="http://www.eecis.udel.edu/~ntp/">NTP
+ homepage</a> for more details about NTP software and public
+ time servers.<br />
+ <br />
+ </li>
+
+ <li><a href="http://www.perl.org/">Perl 5</a>
+ [OPTIONAL]<br />
+ <br />
+ For some of the support scripts like <a
+ href="programs/apxs.html">apxs</a> or <a
+ href="programs/dbmmanage.html">dbmmanage</a> (which are
+ written in Perl) the Perl 5 interpreter is required (versions
+ 5.003 and 5.004 are fine). If no such interpreter is found by
+ the `configure' script there is no harm. Of course, you still
+ can build and install Apache 2.0. Only those support scripts
+ cannot be used. If you have multiple Perl interpreters
+ installed (perhaps a Perl 4 from the vendor and a Perl 5 from
+ your own), then it is recommended to use the --with-perl
+ option (see below) to make sure the correct one is selected
+ by ./configure.<br />
+ <br />
+ </li>
+ </ul>
+
+ <h3><a id="download" name="download">Download</a></h3>
+
+ <p>Apache can be downloaded from the <a
+ href="http://www.apache.org/dist/httpd/">Apache Software
+ Foundation download site</a> or from a <a
+ href="http://www.apache.org/dyn/closer.cgi">nearby
+ mirror</a>.</p>
+
+ <p>Version numbers that end in <code>alpha</code> indicate
+ early pre-test versions which may or may not work. Version
+ numbers ending in <code>beta</code> indicate more reliable
+ releases that still require further testing or bug fixing. If
+ you wish to download the best available production release of
+ the Apache HTTP Server, you should choose the latest version
+ with neither <code>alpha</code> nor <code>beta</code> in its
+ filename.</p>
+
+ <p>After downloading, especially if a mirror site is used, it
+ is important to verify that you have a complete and unmodified
+ version of the Apache HTTP Server. This can be accomplished by
+ testing the downloaded tarball against the PGP signature. This,
+ in turn, is a two step procedure. First, you must obtain the
+ <code>KEYS</code> file from the <a
+ href="http://www.apache.org/dist/">Apache distribution
+ site</a>. (To assure that the <code>KEYS</code> file itself has
+ not been modified, it may be a good idea to use a file from a
+ previous distribution of Apache or import the keys from a
+ public key server.) The keys are imported into your personal
+ key ring using one of the following commands (depending on your
+ pgp version):</p>
+
+ <blockquote>
+ <code>$ pgp < KEYS</code>
+ </blockquote>
+ or
+
+ <blockquote>
+ <code>$ gpg --import KEYS</code>
+ </blockquote>
+
+ <p>The next step is to test the tarball against the PGP
+ signature, which should always be obtained from the <a
+ href="http://www.apache.org/dist/httpd">main Apache
+ website</a>. The signature file has a filename identical to the
+ source tarball with the addition of <code>.asc</code>. Then you
+ can check the distribution with one of the following commands
+ (again, depending on your pgp version):</p>
+
+ <blockquote>
+ <code>$ pgp httpd-2_0_<em>NN</em>.tar.gz.asc</code>
+ </blockquote>
+ or
+
+ <blockquote>
+ <code>$ gpg --verify httpd-2_0_<em>NN</em>.tar.gz.asc</code>
+ </blockquote>
+ You should receive a message like<br />
+ <br />
-<p>Now its time to install the package under the configured
-installation <em>PREFIX</em> (see <code>--prefix</code> option above)
-by running:</h3> <blockquote><code> $ make install
-</code></blockquote>
-
-<p>If you are upgrading, the installation will not overwrite
-your configuration files or documents.</p>
-
-
-<h3><a name="customize">Customize</a></h3>
-
-<p>Next, you can customize your Apache HTTP server by editing the <a
-href="configuring.html">configuration files</a> under
-<em>PREFIX</em>/conf/.</p>
-
-<blockquote><code>
-$ vi <em>PREFIX</em>/conf/httpd.conf
-</code></blockquote>
-
-<p>Have a look at the Apache manual under <a
-href="./">docs/manual/</a> or <a
-href="http://httpd.apache.org/docs/">http://httpd.apache.org/docs/</a>
-for a complete reference of available <a
-href="mod/directives.html">configuration directives</a>.</p>
-
-<h3><a name="test">Test</a></h3>
-
-<p>Now you can <a href="invoking.html">start</a> your Apache HTTP
-server by immediately running:</p>
-
-<blockquote><code>
- $ <em>PREFIX</em>/bin/apachectl start
-</code></blockquote>
-
-<p>and then you should be able to request your first document via URL
-http://localhost/. The web page you see is located under the <a
-href="mod/core.html#documentroot">DocumentRoot</a> which will usually
-be <code><em>PREFIX</em>/htdocs/</code>. Then <a
-href="stopping.html">stop</a> the server again by running:</p>
-
-<blockquote><code> $ <em>PREFIX</em>/bin/apachectl stop
-</code></blockquote>
-
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+
+ <blockquote>
+ <code>Good signature from user "Martin Kraemer
+ <martin@apache.org>".</code>
+ </blockquote>
+
+ <p>Depending on the trust relationships contained in your key
+ ring, you may also receive a message saying that the
+ relationship between the key and the signer of the key cannot
+ be verified. This is not a problem if you trust the
+ authenticity of the <code>KEYS</code> file.</p>
+
+ <h3><a id="extract" name="extract">Extract</a></h3>
+
+ <p>Extracting the source from the Apache HTTPD tarball is a
+ simple matter of uncompressing, and then untarring:</p>
+
+ <blockquote>
+ <code>$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br />
+ $ tar xvf httpd-2_0_<em>NN</em>.tar</code>
+ </blockquote>
+
+ <p>This will create a new directory under the current directory
+ containing the source code for the distribution. You should
+ <code>cd</code> into that directory before proceeding with
+ compiling the server.</p>
+
+ <h3><a id="configure" name="configure">Configuring the source
+ tree</a></h3>
+
+ <p>The next step is to configure the Apache source tree for
+ your particular platform and personal requirements. This is
+ done using the script <code>configure</code> included in the
+ root directory of the distribution. (Developers downloading the
+ CVS version of the Apache source tree will need to have
+ <code>autoconf</code> and <code>libtool</code> installed and
+ will need to run <code>buildconf</code> before proceeding with
+ the next steps. This is not necessary for official
+ releases.)</p>
+
+ <p>To configure the source tree using all the default options,
+ simply type <code>./configure</code>. To change the default
+ options, <code>configure</code> accepts a variety of variables
+ and command line options. Environment variables are generally
+ placed before the <code>./configure</code> command, while other
+ options are placed after. The most important option here is the
+ location prefix where Apache is to be installed later, because
+ Apache has to be configured for this location to work
+ correctly. But there are a lot of other options available for
+ your pleasure.</p>
+
+ <p>For a short impression of what possibilities you have, here
+ is a typical example which compiles Apache for the installation
+ tree /sw/pkg/apache with a particular compiler and flags plus
+ the two additional modules mod_rewrite and mod_speling for
+ later loading through the DSO mechanism:</p>
+
+ <blockquote>
+ <code>$ CC="pgcc" CFLAGS="-O2" \<br />
+ ./configure --prefix=/sw/pkg/apache \<br />
+ --enable-rewrite=shared \<br />
+ --enable-speling=shared</code>
+ </blockquote>
+
+ <p>When configure is run it will take several minutes to test
+ for the availability of features on your system and build
+ Makefiles which will later be used to compile the server.</p>
+
+ <p>The easiest way to find all of the configuration flags for
+ Apache is to run ./configure --help. What follows is a brief
+ description of most of the arguments and environment
+ variables.</p>
+
+ <h4><a id="environment" name="environment">Environment
+ Variables</a></h4>
+
+ <p>The autoconf build process uses several environment
+ variables to configure the build environment. In general, these
+ variables change the method used to build Apache, but not the
+ eventual features of the server. These variables can be placed
+ in the environment before invoking <code>configure</code>, but
+ it is usually easier to specify them on the
+ <code>configure</code> command line as demonstrated in the
+ example above.</p>
+
+ <dl>
+ <dt><code>CC=...</code></dt>
+
+ <dd>The name of the C compiler command.</dd>
+
+ <dt><code>CPPFLAGS=...</code></dt>
+
+ <dd>Miscellaneous C preprocessor and compiler options.</dd>
+
+ <dt><code>CFLAGS=...</code></dt>
+
+ <dd>Debugging and optimization options for the C
+ compiler.</dd>
+
+ <dt><code>LDFLAGS=...</code></dt>
+
+ <dd>Miscellaneous options to be passed to the linker.</dd>
+
+ <dt><code>LIBS=...</code></dt>
+
+ <dd>Library location information ("-L" and "-l" options) to
+ pass to the linker.</dd>
+
+ <dt><code>INCLUDES=...</code></dt>
+
+ <dd>Header file search directories ("-I<em>dir</em>").</dd>
+
+ <dt><code>TARGET=...</code> [Default: apache]</dt>
+
+ <dd>Name of the executable which will be built.</dd>
+
+ <dt><code>NOTEST_CPPFLAGS=...</code></dt>
+
+ <dt><code>NOTEST_CFLAGS=...</code></dt>
+
+ <dt><code>NOTEST_LDFLAGS=...</code></dt>
+
+ <dt><code>NOTEST_LIBS=...</code></dt>
+
+ <dd>These variables share the same function as their
+ non-NOTEST namesakes. However, the variables are applied to
+ the build process only after autoconf has performed its
+ feature testing. This allows the inclusion of flags which
+ will cause problems during feature testing, but must be used
+ for the final compilation.</dd>
+
+ <dt><code>SHLIB_PATH=...</code></dt>
+
+ <dd>Options which specify shared library paths for the
+ compiler and linker.</dd>
+ </dl>
+
+ <h4><a id="output" name="output">autoconf Output
+ Options</a></h4>
+
+ <dl>
+ <dt><code>--help</code></dt>
+
+ <dd>Prints the usage message including all available options,
+ but does not actually configure anything.</dd>
+
+ <dt><code>--quiet</code></dt>
+
+ <dd>Prevents the printing of the usual "checking..."
+ messages.</dd>
+
+ <dt><code>--verbose</code></dt>
+
+ <dd>Prints much more information during the configuration
+ process, including the names of all the files examined.</dd>
+ </dl>
+
+ <h4><a id="pathnames" name="pathnames">Pathnames</a></h4>
+
+ <p>There are currently two ways to configure the pathnames
+ under which Apache will install its files. First, you can
+ specify a directory and have Apache install itself under that
+ directory in its default locations.</p>
+
+ <dl>
+ <dt><code>--prefix=<em>PREFIX</em></code> [Default:
+ /usr/local/apache2]</dt>
+
+ <dd>Specifies the directory under which the Apache files will
+ be installed.</dd>
+ </dl>
+
+ <p>It is possible to specify that architecture-dependent files
+ should be placed under a different directory.</p>
+
+ <dl>
+ <dt><code>--exec-prefix=<em>EPREFIX</em></code> [Default:
+ <em>PREFIX</em>]</dt>
+
+ <dd>Specifies the directory under which
+ architecture-dependent files will be placed.</dd>
+ </dl>
+
+ <p>The second, and more flexible way to configure the install
+ path locations for Apache is using the
+ <code>config.layout</code> file. Using this method, it is
+ possible to separately specify the location for each type of
+ file within the Apache installation. The
+ <code>config.layout</code> file contains several example
+ configurations, and you can also create your own custom
+ configuration following the examples. The different layouts in
+ this file are grouped into <code><Layout
+ FOO>...</Layout></code> sections and referred to by
+ name as in <code>FOO</code>.</p>
+
+ <dl>
+ <dt><code>--enable-layout=<em>LAYOUT</em></code></dt>
+
+ <dd>Use the named layout in the <code>config.layout</code>
+ file to specify the installation paths.</dd>
+ </dl>
+
+ <p>Presently it is not possible to mix the
+ <code>--enable-layout</code> and <code>--prefix</code> options.
+ Nor is it possible to individually specify detailed pathnames
+ on the <code>configure</code> command line. If you want just a
+ basic install, you can simply use the <code>--prefix</code>
+ option on its own. If you want to customize your install, you
+ should edit the <code>config.layout</code> file and use the
+ <code>--enable-layout</code> option.</p>
+
+ <h4><a id="modules" name="modules">Modules</a></h4>
+
+ <p>Apache is a modular server. Only the most basic
+ functionality is included in the core server. Extended features
+ are available in various modules. During the configuration
+ process, you must select which modules to compile for use with
+ your server. You can view a <a
+ href="mod/index-bytype.html">list of modules</a> included in
+ the documentation. Those modules with a <a
+ href="mod/module-dict.html#Status">status</a> of "Base" are
+ included by default and must be specifically disabled if you do
+ not want them. Modules with any other status must be
+ specifically enabled if you wish to use them.</p>
+
+ <p>There are two ways for a module to be compiled and used with
+ Apache. Modules may be <em>statically compiled</em>, which
+ means that they are permanently included in the Apache binary.
+ Alternatively, if your operating system supports Dynamic Shared
+ Objects (DSOs) and autoconf can detect that support, then
+ modules may be <em>dynamically compiled</em>. DSO modules are
+ stored separately from the Apache binary, and may be included
+ or excluded from the server using the run-time configuration
+ directives provided by <a href="mod/mod_so.html">mod_so</a>.
+ The mod_so is automatically included in the server if any
+ dynamic modules are included in the compilation. If you would
+ like to make your server capable of loading DSOs without
+ actually compiling any dynamic modules, you can explicitly
+ <code>--enable-so</code>.</p>
+
+ <dl>
+ <dt><code>--enable-<em>MODULE</em>[=shared]</code></dt>
+
+ <dd>Compile and include the module <em>MODULE</em>. The
+ identifier <em>MODULE</em> is the <a
+ href="mod/module-dict.html#ModuleIdentifier">Module
+ Identifier</a> from the module documentation without the
+ "_module" string. To compile the module as a DSO, add the
+ option <code>=shared</code>.</dd>
+
+ <dt><code>--disable-<em>MODULE</em></code></dt>
+
+ <dd>Remove the module <em>MODULE</em> which would otherwise
+ be compiled and included.</dd>
+
+ <dt><code>--enable-modules=<em>MODULE-LIST</em></code></dt>
+
+ <dd>Compile and include the modules listed in the
+ space-separated <em>MODULE-LIST</em>.</dd>
+
+ <dt>
+ <code>--enable-mods-shared=<em>MODULE-LIST</em></code></dt>
+
+ <dd>Compile and include the modules in the space-separated
+ <em>MODULE-LIST</em> as dynamically loadable (DSO)
+ modules.</dd>
+ </dl>
+
+ <p>The <em>MODULE-LIST</em> in the
+ <code>--enable-modules</code> and
+ <code>--enable-mods-shared</code> options is usually a
+ space-separated list of module identifiers. For example, to
+ enable mod_dav and mod_info, you can either use</p>
+
+ <blockquote>
+ <code>./configure --enable-dav --enable-info</code>
+ </blockquote>
+
+ <p>or, equivalently,</p>
+
+ <blockquote>
+ <code>./configure --enable-modules="dav info"</code>
+ </blockquote>
+
+ <p>In addition, the special keywords <code>all</code> or
+ <code>most</code> can be used to add all or most of the modules
+ in one step. You can then remove any modules that you do not
+ want with the <code>--disable-<em>MODULE</em></code> option.
+ For example, to include all modules as DSOs with the exception
+ of mod_info, you can use</p>
+
+ <blockquote>
+ <code>./configure --enable-mods-shared=all
+ --disable-info</code>
+ </blockquote>
+
+ <p>In addition to the standard set of modules, Apache 2.0 also
+ includes a choice of <a href="mpm.html">Multi-Processing
+ Modules</a> (MPMs). One, and only one MPM must be included in
+ the compilation process. The default MPMs for each platform are
+ listed on the <a href="mpm.html">MPM documentation page</a>,
+ but can be overridden on the <code>configure</code> command
+ line.</p>
+
+ <dl>
+ <dt><code>--with-mpm=<em>NAME</em></code></dt>
+
+ <dd>Choose the mpm <em>NAME</em>.</dd>
+ </dl>
+
+ <h4><a id="suexec" name="suexec">Suexec</a></h4>
+
+ <p>Apache includes a support program called <a
+ href="suexec.html">suexec</a> which can be used to isolate user
+ CGI programs. However, if suexec is improperly configured, it
+ can cause serious security problems. Therefore, you should
+ carefully read and consider the <a href="suexec.html">suexec
+ documentation</a> before implementing this feature.</p>
+
+ <h3><a id="compile" name="compile">Build</a></h3>
+
+ <p>Now you can build the various parts which form the Apache
+ package by simply running the command:</p>
+
+ <blockquote>
+ <code>$ make</code>
+ </blockquote>
+
+ <p>Please be patient here, since a base configuration takes
+ approximately 3 minutes to compile under a Pentium III/Linux
+ 2.2 system, but this will vary widely depending on your
+ hardware and the number of modules which you have enabled.</p>
+
+ <h3><a id="install" name="install">Install</a></h3>
+
+ <p>Now its time to install the package under the configured
+ installation <em>PREFIX</em> (see <code>--prefix</code> option
+ above) by running:</p>
+
+ <blockquote>
+ <code>$ make install</code>
+ </blockquote>
+
+ <p>If you are upgrading, the installation will not overwrite
+ your configuration files or documents.</p>
+
+ <h3><a id="customize" name="customize">Customize</a></h3>
+
+ <p>Next, you can customize your Apache HTTP server by editing
+ the <a href="configuring.html">configuration files</a> under
+ <em>PREFIX</em>/conf/.</p>
+
+ <blockquote>
+ <code>$ vi <em>PREFIX</em>/conf/httpd.conf</code>
+ </blockquote>
+
+ <p>Have a look at the Apache manual under <a
+ href="./">docs/manual/</a> or <a
+ href="http://httpd.apache.org/docs/">http://httpd.apache.org/docs/</a>
+ for a complete reference of available <a
+ href="mod/directives.html">configuration directives</a>.</p>
+
+ <h3><a id="test" name="test">Test</a></h3>
+
+ <p>Now you can <a href="invoking.html">start</a> your Apache
+ HTTP server by immediately running:</p>
+
+ <blockquote>
+ <code>$ <em>PREFIX</em>/bin/apachectl start</code>
+ </blockquote>
+
+ <p>and then you should be able to request your first document
+ via URL http://localhost/. The web page you see is located
+ under the <a href="mod/core.html#documentroot">DocumentRoot</a>
+ which will usually be <code><em>PREFIX</em>/htdocs/</code>.
+ Then <a href="stopping.html">stop</a> the server again by
+ running:</p>
+
+ <blockquote>
+ <code>$ <em>PREFIX</em>/bin/apachectl stop</code>
+ </blockquote>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Compiling and Installing Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">Compiling and Installing</H1>
-
-
-<p>This document covers compilation and installation of Apache on Unix
-and Unix-like systems only. For compiling and installation on Windows,
-see <A HREF="platform/windows.html">Using Apache with Microsoft
-Windows</A>. For other platforms, see the <a
-href="platform/">platform</a> documentation.</p>
-
-<p>Apache 2.0's configuration and installation environment has changed
-completely from Apache 1.3. Apache 1.3 used a custom set of scripts
-to achieve easy installation. Apache 2.0 now uses libtool and
-autoconf to create an environment that looks like many other Open
-Source projects.</p>
-
-<ul>
-<li><a href="#overview">Overview for the impatient</a></li>
-<li><a href="#requirements">Requirements</a></li>
-<li><a href="#download">Download</a></li>
-<li><a href="#extract">Extract</a></li>
-<li><a href="#configure">Configuring the source tree</a>
- <ul>
- <li><a href="#environment">Environment Variables</a></li>
- <li><a href="#output">autoconf Output Options</a></li>
- <li><a href="#pathnames">Pathnames</a></li>
- <li><a href="#modules">Modules</a></li>
- <li><a href="#suexec">Suexec</a></li>
- </ul></li>
-<li><a href="#compile">Build</a></li>
-<li><a href="#install">Install</a></li>
-<li><a href="#customize">Customize</a></li>
-<li><a href="#test">Test</a></li>
-</ul>
-
-<hr>
-
-<h3><a name="overview">Overview for the impatient</a></h3>
-
-<table>
-<tr><td><a href="#download">Download</a></td>
-<td><code>$ lynx http://www.apache.org/dist/httpd/httpd-2_0_<em>NN</em>.tar.gz
-</code></td></tr>
-
-<tr><td><a href="#extract">Extract</a></td>
-<td><code>$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br>
-$ tar xvf httpd-2_0_<em>NN</em>.tar
-</code></td></tr>
-
-<tr><td><a href="#configure">Configure</a></td>
-<td><code>$ ./configure --prefix=<em>PREFIX</em>
-</code></td></tr>
-
-<tr><td><a href="#compile">Compile</a></td>
-<td><code>$ make
-</code></td></tr>
-
-<tr><td><a href="#install">Install</a></td>
-<td><code>$ make install
-</code></td></tr>
-
-<tr><td><a href="#customize">Customize</a></td>
-<td><code>$ vi <em>PREFIX</em>/conf/httpd.conf
-</code></td></tr>
-
-<tr><td><a href="#test">Test</a></td>
-<td><code>$ <em>PREFIX</em>/bin/apachectl start
-</code></td></tr>
-
-</table>
-
-<p><em>NN</em> must be replaced with the current minor version number,
-and <em>PREFIX</em> must be replaced with the filesystem path under
-which the server should be installed. If <em>PREFIX</em> is not
-specified, it defaults to <code>/usr/local/apache2</code>.</p>
-
-<p>Each section of the compilation and installation process is
-described in more detail below, beginning with the requirements
-for compiling and installing Apache HTTPD.</p>
-
-<h3><a name="requirements">Requirements</a></h3>
-
-<p>The following requirements exist for building Apache:</p>
-
-<ul>
-
-<li>Disk Space<br><br> Make sure you have at least 50 MB of temporary
-free disk space available. After installation Apache occupies
-approximately 10 MB of disk space. The actual disk space requirements
-will vary considerably based on your chosen configuration options and
-any third-party modules.<br><br></li>
-
-<li>ANSI-C Compiler and Build System<br><br> Make sure you have an
-ANSI-C compiler installed. The <a
-href="http://www.gnu.org/software/gcc/gcc.html">GNU C compiler
-(GCC)</a> from the <a href="http://www.gnu.org/">Free Software
-Foundation (FSF)</a> is recommended (version 2.7.2 is fine). If you
-don't have GCC then at least make sure your vendor's compiler is ANSI
-compliant. In addition, your <code>PATH</code> must contain basic
-build tools such as <code>make</code>.<br><br></li>
-
-<li>Accurate time keeping<br><br> Elements of the HTTP protocol are
-expressed as the time of day. So, it's time to investigate setting
-some time synchronization facility on your system. Usually the ntpdate
-or xntpd programs are used for this purpose which are based on the
-Network Time Protocol (NTP). See the Usenet newsgroup <a
-href="news:comp.protocols.time.ntp">comp.protocols.time.ntp</a> and
-the <a href="http://www.eecis.udel.edu/~ntp/">NTP homepage</a> for more
-details about NTP software and public time servers.<br><br></li>
-
-<li><a href="http://www.perl.org/">Perl 5</a> [OPTIONAL]<br><br> For
-some of the support scripts like <a href="programs/apxs.html">apxs</a>
-or <a href="programs/dbmmanage.html">dbmmanage</a> (which are written
-in Perl) the Perl 5 interpreter is required (versions 5.003 and 5.004
-are fine). If no such interpreter is found by the `configure' script
-there is no harm. Of course, you still can build and install Apache
-2.0. Only those support scripts cannot be used. If you have multiple
-Perl interpreters installed (perhaps a Perl 4 from the vendor and a
-Perl 5 from your own), then it is recommended to use the --with-perl
-option (see below) to make sure the correct one is selected by
-./configure. <br><br></li>
-
-</ul>
-
-<h3><a name="download">Download</a></h3>
-
-<p>Apache can be downloaded from the <a
-href="http://www.apache.org/dist/httpd/">Apache Software Foundation
-download site</a> or from a <a
-href="http://www.apache.org/dyn/closer.cgi">nearby mirror</a>.</p>
-
-<p>Version numbers that end in <code>alpha</code> indicate early
-pre-test versions which may or may not work. Version numbers ending
-in <code>beta</code> indicate more reliable releases that still
-require further testing or bug fixing. If you wish to download the
-best available production release of the Apache HTTP Server, you
-should choose the latest version with neither <code>alpha</code> nor
-<code>beta</code> in its filename.</p>
-
-<p>After downloading, especially if a mirror site is used, it is
-important to verify that you have a complete and unmodified version of
-the Apache HTTP Server. This can be accomplished by testing the
-downloaded tarball against the PGP signature. This, in turn, is a two
-step procedure. First, you must obtain the <code>KEYS</code> file
-from the <a href="http://www.apache.org/dist/">Apache distribution
-site</a>. (To assure that the <code>KEYS</code> file itself has not
-been modified, it may be a good idea to use a file from a previous
-distribution of Apache or import the keys from a public key server.)
-The keys are imported into your personal key ring using
-one of the following commands (depending on your pgp version):</p>
-<blockquote><code>
-$ pgp < KEYS
-</code></blockquote>
-or
-<blockquote><code>
-$ gpg --import KEYS
-</code></blockquote>
-
-<p>The next step is to test the tarball against the PGP signature,
-which should always be obtained from the <a
-href="http://www.apache.org/dist/httpd">main Apache website</a>. The
-signature file has a filename identical to the source tarball with the
-addition of <code>.asc</code>. Then you can check the distribution
-with one of the following commands (again, depending on your pgp
-version):</p>
-<blockquote><code>
-$ pgp httpd-2_0_<em>NN</em>.tar.gz.asc
-</code></blockquote>
-or
-<blockquote><code>
-$ gpg --verify httpd-2_0_<em>NN</em>.tar.gz.asc
-</code></blockquote
-
-<p>You should receive a message like</p>
-<blockquote><code>
-Good signature from user "Martin Kraemer <martin@apache.org>".
-</code></blockquote>
-<p>Depending on the trust relationships contained
-in your key ring, you may also receive a message saying that
-the relationship between the key and the signer of the key
-cannot be verified. This is not a problem if you trust the
-authenticity of the <code>KEYS</code> file.</p>
-
-<h3><a name="extract">Extract</a></h3>
-
-<p>Extracting the source from the Apache HTTPD tarball is a simple
-matter of uncompressing, and then untarring:</p>
-
-<blockquote><code>
-$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br>
-$ tar xvf httpd-2_0_<em>NN</em>.tar
-</code></blockquote>
-
-<p>This will create a new directory under the current directory
-containing the source code for the distribution. You should
-<code>cd</code> into that directory before proceeding with
-compiling the server.</p>
-
-<h3><a name="configure">Configuring the source tree</a></h3>
-
-<p>The next step is to configure the Apache source tree for your
-particular platform and personal requirements. This is done using the
-script <code>configure</code> included in the root directory of the
-distribution. (Developers downloading the CVS version of the Apache
-source tree will need to have <code>autoconf</code> and
-<code>libtool</code> installed and will need to run
-<code>buildconf</code> before proceeding with the next steps. This is
-not necessary for official releases.)</p>
-
-<p>To configure the source tree using all the default options, simply
-type <code>./configure</code>. To change the default options,
-<code>configure</code> accepts a variety of variables and command line
-options. Environment variables are generally placed before the
-<code>./configure</code> command, while other options are placed
-after. The most important option here is the location prefix where
-Apache is to be installed later, because Apache has to be configured
-for this location to work correctly. But there are a lot of other
-options available for your pleasure.</p>
-
-<p>For a short impression of what possibilities you have, here is a
-typical example which compiles Apache for the installation tree
-/sw/pkg/apache with a particular compiler and flags plus the two
-additional modules mod_rewrite and mod_speling for later loading
-through the DSO mechanism:</p>
-
-<blockquote><code>
- $ CC="pgcc" CFLAGS="-O2" \<br>
- ./configure --prefix=/sw/pkg/apache \<br>
- --enable-rewrite=shared \<br>
- --enable-speling=shared
-</code></blockquote>
-
-<p>When configure is run it will take several minutes to test for
-the availability of features on your system and build Makefiles
-which will later be used to compile the server.</p>
-
-<p>The easiest way to find all of the configuration flags for Apache
-is to run ./configure --help. What follows is a brief description
-of most of the arguments and environment variables.</p>
-
-<h4><a name="environment">Environment Variables</a></h4>
-
-<p>The autoconf build process uses several environment variables to
-configure the build environment. In general, these variables change
-the method used to build Apache, but not the eventual features of the
-server. These variables can be placed in the environment before
-invoking <code>configure</code>, but it is usually easier to specify
-them on the <code>configure</code> command line as demonstrated
-in the example above.</p>
-
-<dl>
-
-<dt><code>CC=...</code></dt>
-<dd>The name of the C compiler command.</dd>
-
-<dt><code>CPPFLAGS=...</code></dt> <dd>Miscellaneous C preprocessor
-and compiler options.</dd>
-
-<dt><code>CFLAGS=...</code></dt>
-<dd>Debugging and optimization options for the C compiler.</dd>
-
-<dt><code>LDFLAGS=...</code></dt>
-<dd>Miscellaneous options to be passed to the linker.</dd>
-
-<dt><code>LIBS=...</code></dt>
-<dd>Library location information ("-L" and "-l" options)
-to pass to the linker.</dd>
-
-<dt><code>INCLUDES=...</code></dt>
-<dd>Header file search directories ("-I<em>dir</em>").</dd>
-
-<dt><code>TARGET=...</code> [Default: apache]</dt>
-<dd>Name of the executable which will be built.</dd>
-
-<dt><code>NOTEST_CPPFLAGS=...</code></dt>
-<dt><code>NOTEST_CFLAGS=...</code></dt>
-<dt><code>NOTEST_LDFLAGS=...</code></dt>
-<dt><code>NOTEST_LIBS=...</code></dt>
-<dd>These variables share the same function as their non-NOTEST namesakes.
-However, the variables are applied to the build process only after
-autoconf has performed its feature testing. This allows the inclusion of
-flags which will cause problems during feature testing, but must be used
-for the final compilation.</dd>
-
-<dt><code>SHLIB_PATH=...</code></dt>
-<dd>Options which specify shared library paths for the compiler and
-linker.</dd>
-
-</dl>
-
-<h4><a name="output">autoconf Output Options</a></h4>
-
-<dl>
-
-<dt><code>--help</code></dt>
-<dd>Prints the usage message including all available options, but
-does not actually configure anything.</dd>
-
-<dt><code>--quiet</code></dt>
-<dd>Prevents the printing of the usual "checking..." messages.</dd>
-
-<dt><code>--verbose</code></dt>
-<dd>Prints much more information during the configuration process,
-including the names of all the files examined.</dd>
-
-</dl>
-
-<h4><a name="pathnames">Pathnames</a></h4>
-
-<p>There are currently two ways to configure the pathnames under
-which Apache will install its files. First, you can specify
-a directory and have Apache install itself under that directory
-in its default locations.</p>
-
-<dl>
-<dt><code>--prefix=<em>PREFIX</em></code> [Default:
-/usr/local/apache2]</dt>
-<dd>Specifies the directory under which the Apache files will be
-installed.</dd>
-</dl>
-
-<p>It is possible to specify that architecture-dependent files should
-be placed under a different directory.</p>
-
-<dl>
-<dt><code>--exec-prefix=<em>EPREFIX</em></code> [Default:
-<em>PREFIX</em>]</dt>
-<dd>Specifies the directory under which architecture-dependent files
-will be placed.</dd>
-</dl>
-
-<p>The second, and more flexible way to configure the install path
-locations for Apache is using the <code>config.layout</code> file.
-Using this method, it is possible to separately specify the location
-for each type of file within the Apache installation. The
-<code>config.layout</code> file contains several example
-configurations, and you can also create your own custom configuration
-following the examples. The different layouts in this file are
-grouped into <code><Layout FOO>...</Layout></code>
-sections and referred to by name as in <code>FOO</code>.</p>
-
-<dl>
-
-<dt><code>--enable-layout=<em>LAYOUT</em></code></dt>
-<dd>Use the named layout in the <code>config.layout</code> file
-to specify the installation paths.</dd>
-
-</dl>
-
-<p>Presently it is not possible to mix the
-<code>--enable-layout</code> and <code>--prefix</code> options. Nor
-is it possible to individually specify detailed pathnames on the
-<code>configure</code> command line. If you want just a basic
-install, you can simply use the <code>--prefix</code> option on its
-own. If you want to customize your install, you should edit the
-<code>config.layout</code> file and use the
-<code>--enable-layout</code> option.</p>
-
-<h4><a name="modules">Modules</a></h4>
-
-<p>Apache is a modular server. Only the most basic functionality is
-included in the core server. Extended features are available in
-various modules. During the configuration process, you must select
-which modules to compile for use with your server. You can view a <a
-href="mod/index-bytype.html">list of modules</a> included in the
-documentation. Those modules with a <a
-href="mod/module-dict.html#Status">status</a>
-of "Base" are included by default and must be specifically disabled if
-you do not want them. Modules with any other status must be
-specifically enabled if you wish to use them.</p>
-
-<p>There are two ways for a module to be compiled and used with
-Apache. Modules may be <em>statically compiled</em>, which means that
-they are permanently included in the Apache binary. Alternatively, if
-your operating system supports Dynamic Shared Objects (DSOs) and
-autoconf can detect that support, then modules may be <em>dynamically
-compiled</em>. DSO modules are stored separately from the Apache
-binary, and may be included or excluded from the server using the
-run-time configuration directives provided by <a
-href="mod/mod_so.html">mod_so</a>. The mod_so is automatically
-included in the server if any dynamic modules are included in the
-compilation. If you would like to make your server capable of loading
-DSOs without actually compiling any dynamic modules, you can
-explicitly <code>--enable-so</code>.</p>
-
-<dl>
-
-<dt><code>--enable-<em>MODULE</em>[=shared]</code></dt> <dd>Compile
-and include the module <em>MODULE</em>. The identifier
-<em>MODULE</em> is the <a
-href="mod/module-dict.html#ModuleIdentifier"
->Module Identifier</a> from the module documentation without the
-"_module" string. To compile the module as a DSO, add the
-option <code>=shared</code>.</dd>
-
-<dt><code>--disable-<em>MODULE</em></code></dt>
-<dd>Remove the module <em>MODULE</em> which would otherwise be
-compiled and included.</dd>
-
-<dt><code>--enable-modules=<em>MODULE-LIST</em></code> <dd>Compile and
-include the modules listed in the space-separated
-<em>MODULE-LIST</em>.</dd>
-
-<dt><code>--enable-mods-shared=<em>MODULE-LIST</em></code> <dd>Compile
-and include the modules in the space-separated <em>MODULE-LIST</em> as
-dynamically loadable (DSO) modules.</dd>
-
-</dl>
-
-<p>The <em>MODULE-LIST</em> in the <code>--enable-modules</code> and
-<code>--enable-mods-shared</code> options is usually a space-separated list
-of module identifiers. For example, to enable mod_dav and mod_info, you
-can either use</p>
-<blockquote><code>
-./configure --enable-dav --enable-info
-</code></blockquote>
-<p>or, equivalently,</p>
-<blockquote><code>
-./configure --enable-modules="dav info"
-</code></blockquote>
-<p>In addition, the special keywords <code>all</code>
-or <code>most</code> can be used to add all or most of the modules
-in one step. You can then remove any modules that you do not want
-with the <code>--disable-<em>MODULE</em></code> option. For example,
-to include all modules as DSOs with the exception of mod_info, you can use</p>
-<blockquote><code>
-./configure --enable-mods-shared=all --disable-info
-</code></blockquote>
-
-<p>In addition to the standard set of modules, Apache 2.0 also
-includes a choice of <a href="mpm.html">Multi-Processing Modules</a>
-(MPMs). One, and only one MPM must be included in the compilation
-process. The default MPMs for each platform are listed on the <a
-href="mpm.html">MPM documentation page</a>, but can be overridden
-on the <code>configure</code> command line.
-
-<dl>
-
-<dt><code>--with-mpm=<em>NAME</em></code></dt>
-<dd>Choose the mpm <em>NAME</em>.
-
-</dl>
-
-<h4><a name="suexec">Suexec</a></h4>
-
-<p>Apache includes a support program called <a
-href="suexec.html">suexec</a> which can be used to isolate user CGI
-programs. However, if suexec is improperly configured, it can cause
-serious security problems. Therefore, you should carefully read and
-consider the <a href="suexec.html">suexec documentation</a> before
-implementing this feature.</p>
-
-
-<h3><a name="compile">Build</a></h3>
-
-<p>Now you can build the various parts which form the Apache package
-by simply running the command:</p>
-
-<blockquote><code>
- $ make
-</code></blockquote>
-
-<p>Please be patient here, since a base configuration takes
-approximately 3 minutes to compile under a Pentium III/Linux 2.2
-system, but this will vary widely depending on your hardware and the
-number of modules which you have enabled.</p>
-
-
-<h3><a name="install">Install</a></h3>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Compiling and Installing Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Compiling and Installing</h1>
+
+ <p>This document covers compilation and installation of Apache
+ on Unix and Unix-like systems only. For compiling and
+ installation on Windows, see <a
+ href="platform/windows.html">Using Apache with Microsoft
+ Windows</a>. For other platforms, see the <a
+ href="platform/">platform</a> documentation.</p>
+
+ <p>Apache 2.0's configuration and installation environment has
+ changed completely from Apache 1.3. Apache 1.3 used a custom
+ set of scripts to achieve easy installation. Apache 2.0 now
+ uses libtool and autoconf to create an environment that looks
+ like many other Open Source projects.</p>
+
+ <ul>
+ <li><a href="#overview">Overview for the impatient</a></li>
+
+ <li><a href="#requirements">Requirements</a></li>
+
+ <li><a href="#download">Download</a></li>
+
+ <li><a href="#extract">Extract</a></li>
+
+ <li>
+ <a href="#configure">Configuring the source tree</a>
+
+ <ul>
+ <li><a href="#environment">Environment Variables</a></li>
+
+ <li><a href="#output">autoconf Output Options</a></li>
+
+ <li><a href="#pathnames">Pathnames</a></li>
+
+ <li><a href="#modules">Modules</a></li>
+
+ <li><a href="#suexec">Suexec</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#compile">Build</a></li>
+
+ <li><a href="#install">Install</a></li>
+
+ <li><a href="#customize">Customize</a></li>
+
+ <li><a href="#test">Test</a></li>
+ </ul>
+ <hr />
+
+ <h3><a id="overview" name="overview">Overview for the
+ impatient</a></h3>
+
+ <table>
+ <tr>
+ <td><a href="#download">Download</a></td>
+
+ <td><code>$ lynx
+ http://www.apache.org/dist/httpd/httpd-2_0_<em>NN</em>.tar.gz</code>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="#extract">Extract</a></td>
+
+ <td><code>$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br />
+ $ tar xvf httpd-2_0_<em>NN</em>.tar</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#configure">Configure</a></td>
+
+ <td><code>$ ./configure --prefix=<em>PREFIX</em></code>
+ </td>
+ </tr>
+
+ <tr>
+ <td><a href="#compile">Compile</a></td>
+
+ <td><code>$ make</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#install">Install</a></td>
+
+ <td><code>$ make install</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#customize">Customize</a></td>
+
+ <td><code>$ vi <em>PREFIX</em>/conf/httpd.conf</code> </td>
+ </tr>
+
+ <tr>
+ <td><a href="#test">Test</a></td>
+
+ <td><code>$ <em>PREFIX</em>/bin/apachectl start</code>
+ </td>
+ </tr>
+ </table>
+
+ <p><em>NN</em> must be replaced with the current minor version
+ number, and <em>PREFIX</em> must be replaced with the
+ filesystem path under which the server should be installed. If
+ <em>PREFIX</em> is not specified, it defaults to
+ <code>/usr/local/apache2</code>.</p>
+
+ <p>Each section of the compilation and installation process is
+ described in more detail below, beginning with the requirements
+ for compiling and installing Apache HTTPD.</p>
+
+ <h3><a id="requirements"
+ name="requirements">Requirements</a></h3>
+
+ <p>The following requirements exist for building Apache:</p>
+
+ <ul>
+ <li>Disk Space<br />
+ <br />
+ Make sure you have at least 50 MB of temporary free disk
+ space available. After installation Apache occupies
+ approximately 10 MB of disk space. The actual disk space
+ requirements will vary considerably based on your chosen
+ configuration options and any third-party modules.<br />
+ <br />
+ </li>
+
+ <li>ANSI-C Compiler and Build System<br />
+ <br />
+ Make sure you have an ANSI-C compiler installed. The <a
+ href="http://www.gnu.org/software/gcc/gcc.html">GNU C
+ compiler (GCC)</a> from the <a
+ href="http://www.gnu.org/">Free Software Foundation (FSF)</a>
+ is recommended (version 2.7.2 is fine). If you don't have GCC
+ then at least make sure your vendor's compiler is ANSI
+ compliant. In addition, your <code>PATH</code> must contain
+ basic build tools such as <code>make</code>.<br />
+ <br />
+ </li>
+
+ <li>Accurate time keeping<br />
+ <br />
+ Elements of the HTTP protocol are expressed as the time of
+ day. So, it's time to investigate setting some time
+ synchronization facility on your system. Usually the ntpdate
+ or xntpd programs are used for this purpose which are based
+ on the Network Time Protocol (NTP). See the Usenet newsgroup
+ <a
+ href="news:comp.protocols.time.ntp">comp.protocols.time.ntp</a>
+ and the <a href="http://www.eecis.udel.edu/~ntp/">NTP
+ homepage</a> for more details about NTP software and public
+ time servers.<br />
+ <br />
+ </li>
+
+ <li><a href="http://www.perl.org/">Perl 5</a>
+ [OPTIONAL]<br />
+ <br />
+ For some of the support scripts like <a
+ href="programs/apxs.html">apxs</a> or <a
+ href="programs/dbmmanage.html">dbmmanage</a> (which are
+ written in Perl) the Perl 5 interpreter is required (versions
+ 5.003 and 5.004 are fine). If no such interpreter is found by
+ the `configure' script there is no harm. Of course, you still
+ can build and install Apache 2.0. Only those support scripts
+ cannot be used. If you have multiple Perl interpreters
+ installed (perhaps a Perl 4 from the vendor and a Perl 5 from
+ your own), then it is recommended to use the --with-perl
+ option (see below) to make sure the correct one is selected
+ by ./configure.<br />
+ <br />
+ </li>
+ </ul>
+
+ <h3><a id="download" name="download">Download</a></h3>
+
+ <p>Apache can be downloaded from the <a
+ href="http://www.apache.org/dist/httpd/">Apache Software
+ Foundation download site</a> or from a <a
+ href="http://www.apache.org/dyn/closer.cgi">nearby
+ mirror</a>.</p>
+
+ <p>Version numbers that end in <code>alpha</code> indicate
+ early pre-test versions which may or may not work. Version
+ numbers ending in <code>beta</code> indicate more reliable
+ releases that still require further testing or bug fixing. If
+ you wish to download the best available production release of
+ the Apache HTTP Server, you should choose the latest version
+ with neither <code>alpha</code> nor <code>beta</code> in its
+ filename.</p>
+
+ <p>After downloading, especially if a mirror site is used, it
+ is important to verify that you have a complete and unmodified
+ version of the Apache HTTP Server. This can be accomplished by
+ testing the downloaded tarball against the PGP signature. This,
+ in turn, is a two step procedure. First, you must obtain the
+ <code>KEYS</code> file from the <a
+ href="http://www.apache.org/dist/">Apache distribution
+ site</a>. (To assure that the <code>KEYS</code> file itself has
+ not been modified, it may be a good idea to use a file from a
+ previous distribution of Apache or import the keys from a
+ public key server.) The keys are imported into your personal
+ key ring using one of the following commands (depending on your
+ pgp version):</p>
+
+ <blockquote>
+ <code>$ pgp < KEYS</code>
+ </blockquote>
+ or
+
+ <blockquote>
+ <code>$ gpg --import KEYS</code>
+ </blockquote>
+
+ <p>The next step is to test the tarball against the PGP
+ signature, which should always be obtained from the <a
+ href="http://www.apache.org/dist/httpd">main Apache
+ website</a>. The signature file has a filename identical to the
+ source tarball with the addition of <code>.asc</code>. Then you
+ can check the distribution with one of the following commands
+ (again, depending on your pgp version):</p>
+
+ <blockquote>
+ <code>$ pgp httpd-2_0_<em>NN</em>.tar.gz.asc</code>
+ </blockquote>
+ or
+
+ <blockquote>
+ <code>$ gpg --verify httpd-2_0_<em>NN</em>.tar.gz.asc</code>
+ </blockquote>
+ You should receive a message like<br />
+ <br />
-<p>Now its time to install the package under the configured
-installation <em>PREFIX</em> (see <code>--prefix</code> option above)
-by running:</h3> <blockquote><code> $ make install
-</code></blockquote>
-
-<p>If you are upgrading, the installation will not overwrite
-your configuration files or documents.</p>
-
-
-<h3><a name="customize">Customize</a></h3>
-
-<p>Next, you can customize your Apache HTTP server by editing the <a
-href="configuring.html">configuration files</a> under
-<em>PREFIX</em>/conf/.</p>
-
-<blockquote><code>
-$ vi <em>PREFIX</em>/conf/httpd.conf
-</code></blockquote>
-
-<p>Have a look at the Apache manual under <a
-href="./">docs/manual/</a> or <a
-href="http://httpd.apache.org/docs/">http://httpd.apache.org/docs/</a>
-for a complete reference of available <a
-href="mod/directives.html">configuration directives</a>.</p>
-
-<h3><a name="test">Test</a></h3>
-
-<p>Now you can <a href="invoking.html">start</a> your Apache HTTP
-server by immediately running:</p>
-
-<blockquote><code>
- $ <em>PREFIX</em>/bin/apachectl start
-</code></blockquote>
-
-<p>and then you should be able to request your first document via URL
-http://localhost/. The web page you see is located under the <a
-href="mod/core.html#documentroot">DocumentRoot</a> which will usually
-be <code><em>PREFIX</em>/htdocs/</code>. Then <a
-href="stopping.html">stop</a> the server again by running:</p>
-
-<blockquote><code> $ <em>PREFIX</em>/bin/apachectl stop
-</code></blockquote>
-
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+
+ <blockquote>
+ <code>Good signature from user "Martin Kraemer
+ <martin@apache.org>".</code>
+ </blockquote>
+
+ <p>Depending on the trust relationships contained in your key
+ ring, you may also receive a message saying that the
+ relationship between the key and the signer of the key cannot
+ be verified. This is not a problem if you trust the
+ authenticity of the <code>KEYS</code> file.</p>
+
+ <h3><a id="extract" name="extract">Extract</a></h3>
+
+ <p>Extracting the source from the Apache HTTPD tarball is a
+ simple matter of uncompressing, and then untarring:</p>
+
+ <blockquote>
+ <code>$ gzip -d httpd-2_0_<em>NN</em>.tar.gz<br />
+ $ tar xvf httpd-2_0_<em>NN</em>.tar</code>
+ </blockquote>
+
+ <p>This will create a new directory under the current directory
+ containing the source code for the distribution. You should
+ <code>cd</code> into that directory before proceeding with
+ compiling the server.</p>
+
+ <h3><a id="configure" name="configure">Configuring the source
+ tree</a></h3>
+
+ <p>The next step is to configure the Apache source tree for
+ your particular platform and personal requirements. This is
+ done using the script <code>configure</code> included in the
+ root directory of the distribution. (Developers downloading the
+ CVS version of the Apache source tree will need to have
+ <code>autoconf</code> and <code>libtool</code> installed and
+ will need to run <code>buildconf</code> before proceeding with
+ the next steps. This is not necessary for official
+ releases.)</p>
+
+ <p>To configure the source tree using all the default options,
+ simply type <code>./configure</code>. To change the default
+ options, <code>configure</code> accepts a variety of variables
+ and command line options. Environment variables are generally
+ placed before the <code>./configure</code> command, while other
+ options are placed after. The most important option here is the
+ location prefix where Apache is to be installed later, because
+ Apache has to be configured for this location to work
+ correctly. But there are a lot of other options available for
+ your pleasure.</p>
+
+ <p>For a short impression of what possibilities you have, here
+ is a typical example which compiles Apache for the installation
+ tree /sw/pkg/apache with a particular compiler and flags plus
+ the two additional modules mod_rewrite and mod_speling for
+ later loading through the DSO mechanism:</p>
+
+ <blockquote>
+ <code>$ CC="pgcc" CFLAGS="-O2" \<br />
+ ./configure --prefix=/sw/pkg/apache \<br />
+ --enable-rewrite=shared \<br />
+ --enable-speling=shared</code>
+ </blockquote>
+
+ <p>When configure is run it will take several minutes to test
+ for the availability of features on your system and build
+ Makefiles which will later be used to compile the server.</p>
+
+ <p>The easiest way to find all of the configuration flags for
+ Apache is to run ./configure --help. What follows is a brief
+ description of most of the arguments and environment
+ variables.</p>
+
+ <h4><a id="environment" name="environment">Environment
+ Variables</a></h4>
+
+ <p>The autoconf build process uses several environment
+ variables to configure the build environment. In general, these
+ variables change the method used to build Apache, but not the
+ eventual features of the server. These variables can be placed
+ in the environment before invoking <code>configure</code>, but
+ it is usually easier to specify them on the
+ <code>configure</code> command line as demonstrated in the
+ example above.</p>
+
+ <dl>
+ <dt><code>CC=...</code></dt>
+
+ <dd>The name of the C compiler command.</dd>
+
+ <dt><code>CPPFLAGS=...</code></dt>
+
+ <dd>Miscellaneous C preprocessor and compiler options.</dd>
+
+ <dt><code>CFLAGS=...</code></dt>
+
+ <dd>Debugging and optimization options for the C
+ compiler.</dd>
+
+ <dt><code>LDFLAGS=...</code></dt>
+
+ <dd>Miscellaneous options to be passed to the linker.</dd>
+
+ <dt><code>LIBS=...</code></dt>
+
+ <dd>Library location information ("-L" and "-l" options) to
+ pass to the linker.</dd>
+
+ <dt><code>INCLUDES=...</code></dt>
+
+ <dd>Header file search directories ("-I<em>dir</em>").</dd>
+
+ <dt><code>TARGET=...</code> [Default: apache]</dt>
+
+ <dd>Name of the executable which will be built.</dd>
+
+ <dt><code>NOTEST_CPPFLAGS=...</code></dt>
+
+ <dt><code>NOTEST_CFLAGS=...</code></dt>
+
+ <dt><code>NOTEST_LDFLAGS=...</code></dt>
+
+ <dt><code>NOTEST_LIBS=...</code></dt>
+
+ <dd>These variables share the same function as their
+ non-NOTEST namesakes. However, the variables are applied to
+ the build process only after autoconf has performed its
+ feature testing. This allows the inclusion of flags which
+ will cause problems during feature testing, but must be used
+ for the final compilation.</dd>
+
+ <dt><code>SHLIB_PATH=...</code></dt>
+
+ <dd>Options which specify shared library paths for the
+ compiler and linker.</dd>
+ </dl>
+
+ <h4><a id="output" name="output">autoconf Output
+ Options</a></h4>
+
+ <dl>
+ <dt><code>--help</code></dt>
+
+ <dd>Prints the usage message including all available options,
+ but does not actually configure anything.</dd>
+
+ <dt><code>--quiet</code></dt>
+
+ <dd>Prevents the printing of the usual "checking..."
+ messages.</dd>
+
+ <dt><code>--verbose</code></dt>
+
+ <dd>Prints much more information during the configuration
+ process, including the names of all the files examined.</dd>
+ </dl>
+
+ <h4><a id="pathnames" name="pathnames">Pathnames</a></h4>
+
+ <p>There are currently two ways to configure the pathnames
+ under which Apache will install its files. First, you can
+ specify a directory and have Apache install itself under that
+ directory in its default locations.</p>
+
+ <dl>
+ <dt><code>--prefix=<em>PREFIX</em></code> [Default:
+ /usr/local/apache2]</dt>
+
+ <dd>Specifies the directory under which the Apache files will
+ be installed.</dd>
+ </dl>
+
+ <p>It is possible to specify that architecture-dependent files
+ should be placed under a different directory.</p>
+
+ <dl>
+ <dt><code>--exec-prefix=<em>EPREFIX</em></code> [Default:
+ <em>PREFIX</em>]</dt>
+
+ <dd>Specifies the directory under which
+ architecture-dependent files will be placed.</dd>
+ </dl>
+
+ <p>The second, and more flexible way to configure the install
+ path locations for Apache is using the
+ <code>config.layout</code> file. Using this method, it is
+ possible to separately specify the location for each type of
+ file within the Apache installation. The
+ <code>config.layout</code> file contains several example
+ configurations, and you can also create your own custom
+ configuration following the examples. The different layouts in
+ this file are grouped into <code><Layout
+ FOO>...</Layout></code> sections and referred to by
+ name as in <code>FOO</code>.</p>
+
+ <dl>
+ <dt><code>--enable-layout=<em>LAYOUT</em></code></dt>
+
+ <dd>Use the named layout in the <code>config.layout</code>
+ file to specify the installation paths.</dd>
+ </dl>
+
+ <p>Presently it is not possible to mix the
+ <code>--enable-layout</code> and <code>--prefix</code> options.
+ Nor is it possible to individually specify detailed pathnames
+ on the <code>configure</code> command line. If you want just a
+ basic install, you can simply use the <code>--prefix</code>
+ option on its own. If you want to customize your install, you
+ should edit the <code>config.layout</code> file and use the
+ <code>--enable-layout</code> option.</p>
+
+ <h4><a id="modules" name="modules">Modules</a></h4>
+
+ <p>Apache is a modular server. Only the most basic
+ functionality is included in the core server. Extended features
+ are available in various modules. During the configuration
+ process, you must select which modules to compile for use with
+ your server. You can view a <a
+ href="mod/index-bytype.html">list of modules</a> included in
+ the documentation. Those modules with a <a
+ href="mod/module-dict.html#Status">status</a> of "Base" are
+ included by default and must be specifically disabled if you do
+ not want them. Modules with any other status must be
+ specifically enabled if you wish to use them.</p>
+
+ <p>There are two ways for a module to be compiled and used with
+ Apache. Modules may be <em>statically compiled</em>, which
+ means that they are permanently included in the Apache binary.
+ Alternatively, if your operating system supports Dynamic Shared
+ Objects (DSOs) and autoconf can detect that support, then
+ modules may be <em>dynamically compiled</em>. DSO modules are
+ stored separately from the Apache binary, and may be included
+ or excluded from the server using the run-time configuration
+ directives provided by <a href="mod/mod_so.html">mod_so</a>.
+ The mod_so is automatically included in the server if any
+ dynamic modules are included in the compilation. If you would
+ like to make your server capable of loading DSOs without
+ actually compiling any dynamic modules, you can explicitly
+ <code>--enable-so</code>.</p>
+
+ <dl>
+ <dt><code>--enable-<em>MODULE</em>[=shared]</code></dt>
+
+ <dd>Compile and include the module <em>MODULE</em>. The
+ identifier <em>MODULE</em> is the <a
+ href="mod/module-dict.html#ModuleIdentifier">Module
+ Identifier</a> from the module documentation without the
+ "_module" string. To compile the module as a DSO, add the
+ option <code>=shared</code>.</dd>
+
+ <dt><code>--disable-<em>MODULE</em></code></dt>
+
+ <dd>Remove the module <em>MODULE</em> which would otherwise
+ be compiled and included.</dd>
+
+ <dt><code>--enable-modules=<em>MODULE-LIST</em></code></dt>
+
+ <dd>Compile and include the modules listed in the
+ space-separated <em>MODULE-LIST</em>.</dd>
+
+ <dt>
+ <code>--enable-mods-shared=<em>MODULE-LIST</em></code></dt>
+
+ <dd>Compile and include the modules in the space-separated
+ <em>MODULE-LIST</em> as dynamically loadable (DSO)
+ modules.</dd>
+ </dl>
+
+ <p>The <em>MODULE-LIST</em> in the
+ <code>--enable-modules</code> and
+ <code>--enable-mods-shared</code> options is usually a
+ space-separated list of module identifiers. For example, to
+ enable mod_dav and mod_info, you can either use</p>
+
+ <blockquote>
+ <code>./configure --enable-dav --enable-info</code>
+ </blockquote>
+
+ <p>or, equivalently,</p>
+
+ <blockquote>
+ <code>./configure --enable-modules="dav info"</code>
+ </blockquote>
+
+ <p>In addition, the special keywords <code>all</code> or
+ <code>most</code> can be used to add all or most of the modules
+ in one step. You can then remove any modules that you do not
+ want with the <code>--disable-<em>MODULE</em></code> option.
+ For example, to include all modules as DSOs with the exception
+ of mod_info, you can use</p>
+
+ <blockquote>
+ <code>./configure --enable-mods-shared=all
+ --disable-info</code>
+ </blockquote>
+
+ <p>In addition to the standard set of modules, Apache 2.0 also
+ includes a choice of <a href="mpm.html">Multi-Processing
+ Modules</a> (MPMs). One, and only one MPM must be included in
+ the compilation process. The default MPMs for each platform are
+ listed on the <a href="mpm.html">MPM documentation page</a>,
+ but can be overridden on the <code>configure</code> command
+ line.</p>
+
+ <dl>
+ <dt><code>--with-mpm=<em>NAME</em></code></dt>
+
+ <dd>Choose the mpm <em>NAME</em>.</dd>
+ </dl>
+
+ <h4><a id="suexec" name="suexec">Suexec</a></h4>
+
+ <p>Apache includes a support program called <a
+ href="suexec.html">suexec</a> which can be used to isolate user
+ CGI programs. However, if suexec is improperly configured, it
+ can cause serious security problems. Therefore, you should
+ carefully read and consider the <a href="suexec.html">suexec
+ documentation</a> before implementing this feature.</p>
+
+ <h3><a id="compile" name="compile">Build</a></h3>
+
+ <p>Now you can build the various parts which form the Apache
+ package by simply running the command:</p>
+
+ <blockquote>
+ <code>$ make</code>
+ </blockquote>
+
+ <p>Please be patient here, since a base configuration takes
+ approximately 3 minutes to compile under a Pentium III/Linux
+ 2.2 system, but this will vary widely depending on your
+ hardware and the number of modules which you have enabled.</p>
+
+ <h3><a id="install" name="install">Install</a></h3>
+
+ <p>Now its time to install the package under the configured
+ installation <em>PREFIX</em> (see <code>--prefix</code> option
+ above) by running:</p>
+
+ <blockquote>
+ <code>$ make install</code>
+ </blockquote>
+
+ <p>If you are upgrading, the installation will not overwrite
+ your configuration files or documents.</p>
+
+ <h3><a id="customize" name="customize">Customize</a></h3>
+
+ <p>Next, you can customize your Apache HTTP server by editing
+ the <a href="configuring.html">configuration files</a> under
+ <em>PREFIX</em>/conf/.</p>
+
+ <blockquote>
+ <code>$ vi <em>PREFIX</em>/conf/httpd.conf</code>
+ </blockquote>
+
+ <p>Have a look at the Apache manual under <a
+ href="./">docs/manual/</a> or <a
+ href="http://httpd.apache.org/docs/">http://httpd.apache.org/docs/</a>
+ for a complete reference of available <a
+ href="mod/directives.html">configuration directives</a>.</p>
+
+ <h3><a id="test" name="test">Test</a></h3>
+
+ <p>Now you can <a href="invoking.html">start</a> your Apache
+ HTTP server by immediately running:</p>
+
+ <blockquote>
+ <code>$ <em>PREFIX</em>/bin/apachectl start</code>
+ </blockquote>
+
+ <p>and then you should be able to request your first document
+ via URL http://localhost/. The web page you see is located
+ under the <a href="mod/core.html#documentroot">DocumentRoot</a>
+ which will usually be <code><em>PREFIX</em>/htdocs/</code>.
+ Then <a href="stopping.html">stop</a> the server again by
+ running:</p>
+
+ <blockquote>
+ <code>$ <em>PREFIX</em>/bin/apachectl stop</code>
+ </blockquote>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Starting Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Starting Apache</H1>
-
-
-<ul>
-<li><a href="#windows">Starting Apache on Windows</a></li>
-<li><a href="#unix">Starting Apache on Unix</a>
-<ul>
-<li><a href="#errors">Errors During Start-up</a></li>
-<li><a href="#boot">Starting at Boot-Time</a></li>
-<li><a href="#info">Additional Information</a></li>
-</ul>
-</li>
-</ul>
-
-<hr>
-
-<h2><a name="windows">Starting Apache On Windows</a></h2>
-
-<p>On Windows, Apache is normally run as a service on Windows NT, or
-as a console application on Windows 95. For details, see <A
-HREF="platform/windows.html#run">running Apache for Windows</A>.</p>
-
-<h2><a name="unix">Starting Apache on Unix</a></h2>
-
-<p>On Unix, the <a href="programs/httpd.html">httpd</a> program is run
-as a daemon which executes continuously in the background to handle
-requests.</p>
-
-<p>If the <a href="mod/core.html#port">Port</a> specified in the
-configuration file is the default of 80 (or any other port below
-1024), then it is necessary to have root privileges in order to start
-apache, so that it can bind to this privileged port. Once the server
-has started and performed a few preliminary activities such as opening
-its log files, it will launch several <em>child</em> processes which
-do the work of listening for and answering requests from clients. The
-main <code>httpd</code> process continues to run as the root user, but
-the child processes run as a less privileged user. This is controlled
-by the selected <a href="mpm.html">Multi-Processing Module</a>.</p>
-
-<p>The first thing that <code>httpd</code> does when it is invoked is
-to locate and read the <a href="configuring.html">configuration
-file</a> <code>httpd.conf</code>. The location of this file is set at
-compile-time, but it is possible to specify its location at run time
-using the <code>-f</code> command-line option as in</p>
-<blockquote><code> /usr/local/apache/bin/httpd -f
-/usr/local/apache/conf/httpd.conf </code></blockquote>
-
-<p>As an alternative to invoking the <code>httpd</code> binary
-directly, a shell script called <a
-href="programs/apachectl.html">apachectl</a> is provided which can be
-used to control the daemon process with simple commands such as
-<code>apachectl start</code> and <code>apachectl stop</code>.</p>
-
-<p>If all goes well during startup, the server will detach from the
-terminal and the command prompt will return almost immediately.
-This indicates that the server is up and running. You can then
-use your browser to connect to the server and view the test
-page in the <a href="mod/core.html#documentroot">DocumentRoot</a>
-directory and the local copy of the documentation linked from
-that page.</p>
-
-<h3><a name="errors">Errors During Start-up</a></h3>
-
-<p>If Apache suffers a fatal problem during startup, it will write a
-message describing the problem either to the console or to the <a
-href="mod/core.html#errorlog">ErrorLog</a> before exiting. One of the
-most common error messages is "<code>Unable to bind to Port
-...</code>". This message is usually caused by either:</p>
-<ul>
-<li>Trying to start the server on a privileged port when not
-logged in as the root user; or</li>
-<li>Trying to start the server when there is another instance
-of Apache or some other web server already bound to the same Port.</li>
-</ul>
-<p>For further trouble-shooting instructions, consult the Apache <a
-href="faq/">FAQ</a>.</p>
-
-<h3><a name="boot">Starting at Boot-Time</a></h3>
-
-<p>If you want your server to continue running after a system reboot,
-you should add a call to <code>httpd</code> or <code>apachectl</code>
-to your system startup files (typically <code>rc.local</code> or a
-file in an <code>rc.N</code> directory). This will start Apache as
-root. Before doing this ensure that your server is properly configured
-for security and access restrictions. The <code>apachectl</code>
-script is designed so that it can often be linked directly as an init
-script, but be sure to check the exact requirements of your system.</p>
-
-<h3><a name="info">Additional Information</a></h3>
-
-<p>Additional information about the command-line options of <a
-href="programs/httpd.html">httpd</a> and <a
-href="programs/apachectl.html">apachectl</a> as well as other support
-programs included with the server is available on the <a
-href="programs/">Server and Supporting Programs</a> page. There is
-also documentation on all the <a href="mod/">modules</a> included with
-the Apache distribution and the <a
-href="mod/directives.html">directives</a> that they provide.</p>
-
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Starting Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Starting Apache</h1>
+
+ <ul>
+ <li><a href="#windows">Starting Apache on Windows</a></li>
+
+ <li>
+ <a href="#unix">Starting Apache on Unix</a>
+
+ <ul>
+ <li><a href="#errors">Errors During Start-up</a></li>
+
+ <li><a href="#boot">Starting at Boot-Time</a></li>
+
+ <li><a href="#info">Additional Information</a></li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+
+ <h2><a id="windows" name="windows">Starting Apache On
+ Windows</a></h2>
+
+ <p>On Windows, Apache is normally run as a service on Windows
+ NT, or as a console application on Windows 95. For details, see
+ <a href="platform/windows.html#run">running Apache for
+ Windows</a>.</p>
+
+ <h2><a id="unix" name="unix">Starting Apache on Unix</a></h2>
+
+ <p>On Unix, the <a href="programs/httpd.html">httpd</a> program
+ is run as a daemon which executes continuously in the
+ background to handle requests.</p>
+
+ <p>If the <a href="mod/core.html#port">Port</a> specified in
+ the configuration file is the default of 80 (or any other port
+ below 1024), then it is necessary to have root privileges in
+ order to start apache, so that it can bind to this privileged
+ port. Once the server has started and performed a few
+ preliminary activities such as opening its log files, it will
+ launch several <em>child</em> processes which do the work of
+ listening for and answering requests from clients. The main
+ <code>httpd</code> process continues to run as the root user,
+ but the child processes run as a less privileged user. This is
+ controlled by the selected <a href="mpm.html">Multi-Processing
+ Module</a>.</p>
+
+ <p>The first thing that <code>httpd</code> does when it is
+ invoked is to locate and read the <a
+ href="configuring.html">configuration file</a>
+ <code>httpd.conf</code>. The location of this file is set at
+ compile-time, but it is possible to specify its location at run
+ time using the <code>-f</code> command-line option as in</p>
+
+ <blockquote>
+ <code>/usr/local/apache/bin/httpd -f
+ /usr/local/apache/conf/httpd.conf</code>
+ </blockquote>
+
+ <p>As an alternative to invoking the <code>httpd</code> binary
+ directly, a shell script called <a
+ href="programs/apachectl.html">apachectl</a> is provided which
+ can be used to control the daemon process with simple commands
+ such as <code>apachectl start</code> and <code>apachectl
+ stop</code>.</p>
+
+ <p>If all goes well during startup, the server will detach from
+ the terminal and the command prompt will return almost
+ immediately. This indicates that the server is up and running.
+ You can then use your browser to connect to the server and view
+ the test page in the <a
+ href="mod/core.html#documentroot">DocumentRoot</a> directory
+ and the local copy of the documentation linked from that
+ page.</p>
+
+ <h3><a id="errors" name="errors">Errors During
+ Start-up</a></h3>
+
+ <p>If Apache suffers a fatal problem during startup, it will
+ write a message describing the problem either to the console or
+ to the <a href="mod/core.html#errorlog">ErrorLog</a> before
+ exiting. One of the most common error messages is "<code>Unable
+ to bind to Port ...</code>". This message is usually caused by
+ either:</p>
+
+ <ul>
+ <li>Trying to start the server on a privileged port when not
+ logged in as the root user; or</li>
+
+ <li>Trying to start the server when there is another instance
+ of Apache or some other web server already bound to the same
+ Port.</li>
+ </ul>
+
+ <p>For further trouble-shooting instructions, consult the
+ Apache <a href="faq/">FAQ</a>.</p>
+
+ <h3><a id="boot" name="boot">Starting at Boot-Time</a></h3>
+
+ <p>If you want your server to continue running after a system
+ reboot, you should add a call to <code>httpd</code> or
+ <code>apachectl</code> to your system startup files (typically
+ <code>rc.local</code> or a file in an <code>rc.N</code>
+ directory). This will start Apache as root. Before doing this
+ ensure that your server is properly configured for security and
+ access restrictions. The <code>apachectl</code> script is
+ designed so that it can often be linked directly as an init
+ script, but be sure to check the exact requirements of your
+ system.</p>
+
+ <h3><a id="info" name="info">Additional Information</a></h3>
+
+ <p>Additional information about the command-line options of <a
+ href="programs/httpd.html">httpd</a> and <a
+ href="programs/apachectl.html">apachectl</a> as well as other
+ support programs included with the server is available on the
+ <a href="programs/">Server and Supporting Programs</a> page.
+ There is also documentation on all the <a
+ href="mod/">modules</a> included with the Apache distribution
+ and the <a href="mod/directives.html">directives</a> that they
+ provide.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Starting Apache</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Starting Apache</H1>
-
-
-<ul>
-<li><a href="#windows">Starting Apache on Windows</a></li>
-<li><a href="#unix">Starting Apache on Unix</a>
-<ul>
-<li><a href="#errors">Errors During Start-up</a></li>
-<li><a href="#boot">Starting at Boot-Time</a></li>
-<li><a href="#info">Additional Information</a></li>
-</ul>
-</li>
-</ul>
-
-<hr>
-
-<h2><a name="windows">Starting Apache On Windows</a></h2>
-
-<p>On Windows, Apache is normally run as a service on Windows NT, or
-as a console application on Windows 95. For details, see <A
-HREF="platform/windows.html#run">running Apache for Windows</A>.</p>
-
-<h2><a name="unix">Starting Apache on Unix</a></h2>
-
-<p>On Unix, the <a href="programs/httpd.html">httpd</a> program is run
-as a daemon which executes continuously in the background to handle
-requests.</p>
-
-<p>If the <a href="mod/core.html#port">Port</a> specified in the
-configuration file is the default of 80 (or any other port below
-1024), then it is necessary to have root privileges in order to start
-apache, so that it can bind to this privileged port. Once the server
-has started and performed a few preliminary activities such as opening
-its log files, it will launch several <em>child</em> processes which
-do the work of listening for and answering requests from clients. The
-main <code>httpd</code> process continues to run as the root user, but
-the child processes run as a less privileged user. This is controlled
-by the selected <a href="mpm.html">Multi-Processing Module</a>.</p>
-
-<p>The first thing that <code>httpd</code> does when it is invoked is
-to locate and read the <a href="configuring.html">configuration
-file</a> <code>httpd.conf</code>. The location of this file is set at
-compile-time, but it is possible to specify its location at run time
-using the <code>-f</code> command-line option as in</p>
-<blockquote><code> /usr/local/apache/bin/httpd -f
-/usr/local/apache/conf/httpd.conf </code></blockquote>
-
-<p>As an alternative to invoking the <code>httpd</code> binary
-directly, a shell script called <a
-href="programs/apachectl.html">apachectl</a> is provided which can be
-used to control the daemon process with simple commands such as
-<code>apachectl start</code> and <code>apachectl stop</code>.</p>
-
-<p>If all goes well during startup, the server will detach from the
-terminal and the command prompt will return almost immediately.
-This indicates that the server is up and running. You can then
-use your browser to connect to the server and view the test
-page in the <a href="mod/core.html#documentroot">DocumentRoot</a>
-directory and the local copy of the documentation linked from
-that page.</p>
-
-<h3><a name="errors">Errors During Start-up</a></h3>
-
-<p>If Apache suffers a fatal problem during startup, it will write a
-message describing the problem either to the console or to the <a
-href="mod/core.html#errorlog">ErrorLog</a> before exiting. One of the
-most common error messages is "<code>Unable to bind to Port
-...</code>". This message is usually caused by either:</p>
-<ul>
-<li>Trying to start the server on a privileged port when not
-logged in as the root user; or</li>
-<li>Trying to start the server when there is another instance
-of Apache or some other web server already bound to the same Port.</li>
-</ul>
-<p>For further trouble-shooting instructions, consult the Apache <a
-href="faq/">FAQ</a>.</p>
-
-<h3><a name="boot">Starting at Boot-Time</a></h3>
-
-<p>If you want your server to continue running after a system reboot,
-you should add a call to <code>httpd</code> or <code>apachectl</code>
-to your system startup files (typically <code>rc.local</code> or a
-file in an <code>rc.N</code> directory). This will start Apache as
-root. Before doing this ensure that your server is properly configured
-for security and access restrictions. The <code>apachectl</code>
-script is designed so that it can often be linked directly as an init
-script, but be sure to check the exact requirements of your system.</p>
-
-<h3><a name="info">Additional Information</a></h3>
-
-<p>Additional information about the command-line options of <a
-href="programs/httpd.html">httpd</a> and <a
-href="programs/apachectl.html">apachectl</a> as well as other support
-programs included with the server is available on the <a
-href="programs/">Server and Supporting Programs</a> page. There is
-also documentation on all the <a href="mod/">modules</a> included with
-the Apache distribution and the <a
-href="mod/directives.html">directives</a> that they provide.</p>
-
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Starting Apache</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Starting Apache</h1>
+
+ <ul>
+ <li><a href="#windows">Starting Apache on Windows</a></li>
+
+ <li>
+ <a href="#unix">Starting Apache on Unix</a>
+
+ <ul>
+ <li><a href="#errors">Errors During Start-up</a></li>
+
+ <li><a href="#boot">Starting at Boot-Time</a></li>
+
+ <li><a href="#info">Additional Information</a></li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+
+ <h2><a id="windows" name="windows">Starting Apache On
+ Windows</a></h2>
+
+ <p>On Windows, Apache is normally run as a service on Windows
+ NT, or as a console application on Windows 95. For details, see
+ <a href="platform/windows.html#run">running Apache for
+ Windows</a>.</p>
+
+ <h2><a id="unix" name="unix">Starting Apache on Unix</a></h2>
+
+ <p>On Unix, the <a href="programs/httpd.html">httpd</a> program
+ is run as a daemon which executes continuously in the
+ background to handle requests.</p>
+
+ <p>If the <a href="mod/core.html#port">Port</a> specified in
+ the configuration file is the default of 80 (or any other port
+ below 1024), then it is necessary to have root privileges in
+ order to start apache, so that it can bind to this privileged
+ port. Once the server has started and performed a few
+ preliminary activities such as opening its log files, it will
+ launch several <em>child</em> processes which do the work of
+ listening for and answering requests from clients. The main
+ <code>httpd</code> process continues to run as the root user,
+ but the child processes run as a less privileged user. This is
+ controlled by the selected <a href="mpm.html">Multi-Processing
+ Module</a>.</p>
+
+ <p>The first thing that <code>httpd</code> does when it is
+ invoked is to locate and read the <a
+ href="configuring.html">configuration file</a>
+ <code>httpd.conf</code>. The location of this file is set at
+ compile-time, but it is possible to specify its location at run
+ time using the <code>-f</code> command-line option as in</p>
+
+ <blockquote>
+ <code>/usr/local/apache/bin/httpd -f
+ /usr/local/apache/conf/httpd.conf</code>
+ </blockquote>
+
+ <p>As an alternative to invoking the <code>httpd</code> binary
+ directly, a shell script called <a
+ href="programs/apachectl.html">apachectl</a> is provided which
+ can be used to control the daemon process with simple commands
+ such as <code>apachectl start</code> and <code>apachectl
+ stop</code>.</p>
+
+ <p>If all goes well during startup, the server will detach from
+ the terminal and the command prompt will return almost
+ immediately. This indicates that the server is up and running.
+ You can then use your browser to connect to the server and view
+ the test page in the <a
+ href="mod/core.html#documentroot">DocumentRoot</a> directory
+ and the local copy of the documentation linked from that
+ page.</p>
+
+ <h3><a id="errors" name="errors">Errors During
+ Start-up</a></h3>
+
+ <p>If Apache suffers a fatal problem during startup, it will
+ write a message describing the problem either to the console or
+ to the <a href="mod/core.html#errorlog">ErrorLog</a> before
+ exiting. One of the most common error messages is "<code>Unable
+ to bind to Port ...</code>". This message is usually caused by
+ either:</p>
+
+ <ul>
+ <li>Trying to start the server on a privileged port when not
+ logged in as the root user; or</li>
+
+ <li>Trying to start the server when there is another instance
+ of Apache or some other web server already bound to the same
+ Port.</li>
+ </ul>
+
+ <p>For further trouble-shooting instructions, consult the
+ Apache <a href="faq/">FAQ</a>.</p>
+
+ <h3><a id="boot" name="boot">Starting at Boot-Time</a></h3>
+
+ <p>If you want your server to continue running after a system
+ reboot, you should add a call to <code>httpd</code> or
+ <code>apachectl</code> to your system startup files (typically
+ <code>rc.local</code> or a file in an <code>rc.N</code>
+ directory). This will start Apache as root. Before doing this
+ ensure that your server is properly configured for security and
+ access restrictions. The <code>apachectl</code> script is
+ designed so that it can often be linked directly as an init
+ script, but be sure to check the exact requirements of your
+ system.</p>
+
+ <h3><a id="info" name="info">Additional Information</a></h3>
+
+ <p>Additional information about the command-line options of <a
+ href="programs/httpd.html">httpd</a> and <a
+ href="programs/apachectl.html">apachectl</a> as well as other
+ support programs included with the server is available on the
+ <a href="programs/">Server and Supporting Programs</a> page.
+ There is also documentation on all the <a
+ href="mod/">modules</a> included with the Apache distribution
+ and the <a href="mod/directives.html">directives</a> that they
+ provide.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Log Files - Apache HTTP Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Log Files</h1>
-
-<p>In order to effectively manage a web server, it is necessary to get
-feedback about the activity and performance of the server as well as
-any problems that may be occuring. The Apache HTTP Server provides
-very comprehensive and flexible logging capabilities. This document
-describes how to configure its logging capabilities, and how to
-understand what the logs contain.</p>
-
-<ul>
-<li><a href="#security">Security Warning</a></li>
-<li><a href="#errorlog">Error Log</a></li>
-<li><a href="#accesslog">Access Log</a>
- <ul>
- <li><a href="#common">Common Log Format</a></li>
- <li><a href="#combined">Combined Log Format</a></li>
- <li><a href="#multiple">Multiple Access Logs</a></li>
- <li><a href="#conditional">Conditional Logging</a></li>
- </ul></li>
-<li><a href="#rotation">Log Rotation</a></li>
-<li><a href="#piped">Piped Logs</a></li>
-<li><a href="#virtualhosts">VirtualHosts</a>
-<li><a href="#other">Other Log Files</a>
- <ul>
- <li><a href="#pidfile">PID File</a></li>
- <li><a href="#scriptlog">Script Log</a></li>
- <li><a href="#rewritelog">Rewrite Log</a></li>
- </ul></li>
-</ul>
-
-<hr>
-
-<h2><a name="security">Security Warning</a></h2>
-
-<p>Anyone who can write to the directory where Apache is writing a
-log file can almost certainly gain access to the uid that the server is
-started as, which is normally root. Do <EM>NOT</EM> give people write
-access to the directory the logs are stored in without being aware of
-the consequences; see the <A HREF="misc/security_tips.html">security tips</A>
-document for details.</p>
-
-<p>In addition, log files may contain information supplied directly
-by the client, without escaping. Therefore, it is possible for
-malicious clients to insert control-characters in the log files, so
-care must be taken in dealing with raw logs.</p>
-
-<hr>
-
-<h2><a name="errorlog">Error Log</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/core.html#errorlog">ErrorLog</a><br>
-<a href="mod/core.html#loglevel">LogLevel</a>
-</td></tr></table>
-
-<p>The server error log, whose name and location is set by the <a
-href="mod/core.html#errorlog">ErrorLog</a> directive, is the most
-important log file. This is the place where Apache httpd will send
-diagnostic information and record any errors that it encounters in
-processing requests. It is the first place to look when a problem
-occurs with starting the server or with the operation of the server,
-since it will often contain details of what went wrong and how to fix
-it.</p>
-
-<p>The error log is usually written to a file (typically
-<code>error_log</code> on unix systems and <code>error.log</code> on
-Windows and OS/2). On unix systems it is also possible to have the
-server send errors to <code>syslog</code> or <a href="#pipe">pipe
-them to a program</a>.</p>
-
-<p>The format of the error log is relatively free-form and
-descriptive. But there is certain information that is contained
-in most error log entries. For example, here is a typical message.</p>
-
-<blockquote><code>
-[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test
-</code></blockquote>
-
-<p>The first item in the log entry is the date and time of the
-message. The second entry lists the severity of the error being
-reported. The <a href="mod/core.html#loglevel">LogLevel</a> directive
-is used to control the types of errors that are sent to the error log
-by restricting the severity level. The third entry gives the IP
-address of the client that generated the error. Beyond that is the
-message itself, which in this case indicates that the server has been
-configured to deny the client access. The server reports the
-file-system path (as opposed to the web path) of the requested
-document.</p>
-
-<p>A very wide variety of different messages can appear in the error
-log. Most look similar to the example above. The error log will also
-contain debugging output from CGI scripts. Any information written to
-<code>stderr</code> by a CGI script will be copied directly to the
-error log.</p>
-
-<p>It is not possible to customize the error log by adding or removing
-information. However, error log entries dealing with particular
-requests have corresponding entries in the <a href="accesslog">access
-log</a>. For example, the above example entry corresponds to an
-access log entry with status code 403. Since it is possible to
-customize the access log, you can obtain more information about error
-conditions using that log file.</p>
-
-<p>During testing, it is often useful to continuously monitor the
-error log for any problems. On unix systems, you can accomplish this
-using:</p>
-<blockquote><code>
-tail -f error_log
-</code></blockquote>
-
-<hr>
-
-<h2><a name="accesslog">Access Log</a></h2>
-
-<table border=1><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_log_config.html">mod_log_config</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/mod_log_config.html#customlog">CustomLog</a><br>
-<a href="mod/mod_log_config.html#logformat">LogFormat</a><br>
-<a href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>
-
-</td></tr></table>
-
-<p>The server access log records all requests processed by the server.
-The location and content of the access log are controlled
-by the <a href="mod/mod_log_config.html#customlog">CustomLog</a>
-directive. The <a
-href="mod/mod_log_config.html#logformat">LogFormat</a> directive can
-be used to simplify the selection of the contents of the logs.
-This section describes how to configure the server to record
-information in the access log.</p>
-
-<p>Of course, storing the information in the access log is only the
-start of log management. The next step is to analyze this information
-to produce useful statistics. Log analysis in general is beyond the
-scope of this document, and not really part of the job of the
-web server itself. For more information about this topic, and for
-applications which perform log analysis, check the <a
-href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/"
->Open Directory</a> or <a
-href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/"
->Yahoo</a>.</p>
-
-<p>Various versions of Apache httpd have used other modules and
-directives to control access logging, including mod_log_referer,
-mod_log_agent, and the <code>TransferLog</code> directive. The
-<code>CustomLog</code> directive now subsumes the functionality of all
-the older directives.</p>
-
-<p>The format of the access log is highly configurable. The format is
-specified using a <a href="mod/mod_log_config.html#format">format
-string</a> that looks much like a C-style printf(1) format string.
-Some examples are presented in the next sections. For a complete list
-of the possible contents of the format string, see the <a
-href="mod/mod_log_config.html">mod_log_config documentation</a>.</p>
-
-<h3><a name="common">Common Log Format</a></h3>
-
-<p>A typical configuration for the access log might look
-as follows.</p>
-
-<blockquote><code>
-LogFormat "%h %l %u %t \"%r\" %>s %b" common<br>
-CustomLog logs/access_log common
-</code></blockquote>
-
-<p>This defines the <em>nickname</em> <code>common</code> and
-associates it with a particular log format string. The format string
-consists of percent directives, each of which tell the server to log a
-particular piece of information. Literal characters may also be
-placed in the format string and will be copied directly into the log
-output. The quote character (<code>"</code>) must be escaped by
-placing a back-slash before it to prevent it from being interpreted as
-the end of the format string. The format string may also contain the
-special control characters "<code>\n</code>" for new-line and
-"<code>\t</code>" for tab.</p>
-
-<p>The <code>CustomLog</code> directive sets up a new log file using
-the defined <em>nickname</em>. The filename for the access log is
-relative to the <a href="mod/core.html#serverroot">ServerRoot</a>
-unless it begins with a slash.</p>
-
-<p>The above configuration will write log entries in a format known as
-the Common Log Format (CLF). This standard format can be produced by
-many different web servers and read by many log analysis programs.
-The log file entries produced in CLF will look something like
-this:</p>
-
-<blockquote><code>
-127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
-</code></blockquote>
-
-<p>Each part of this log entry is described below.</p>
-
-<dl>
-<dt><code>127.0.0.1</code> (<code>%h</code>)</dt> <dd>This is the IP
-address of the client (remote host) which made the request to the
-server. If <a
-href="mod/core.html#hostnamelookups">HostNameLookups</a> is set to
-<code>On</code>, then the server will try to determine the hostname
-and log it in place of the IP address. However, this configuration is
-not recommended since it can significantly slow the server. Instead,
-it is best to use a log post-processor such as <a
-href="programs/logresolve.html">logresolve</a> to determine the
-hostnames. The IP address reported here is not necessarily the
-address of the machine at which the user is sitting. If a proxy
-server exists between the user and the server, this address will be
-the address of the proxy, rather than the originating machine.</dd>
-
-<dt><code>-</code> (<code>%l</code>)</dt> <dd>The "hyphen" in the
-output indicates that the requested piece of information is not
-available. In this case, the information that is not available is the
-RFC 1413 identity of the client determined by <code>identd</code> on
-the clients machine. This information is highly unreliable and should
-almost never be used except on tightly controlled internal networks.
-Apache httpd will not even attempt to determine this information
-unless <a href="mod/core.html#identitycheck">IdentityCheck</a> is set
-to <code>On</code>.</dd>
-
-<dt><code>frank</code> (<code>%u</code>)</dt> <dd>This is the userid
-of the person requesting the document as determined by HTTP
-authentication. The same value is typically provided to CGI scripts
-in the <code>REMOTE_USER</code> environment variable. If the status
-code for the request (see below) is 401, then this value should not be
-trusted because the user is not yet authenticated. If the document is
-not password protected, this entry will be "<code>-</code>" just like
-the previous one.</dd>
-
-<dt><code>[10/Oct/2000:13:55:36 -0700]</code> (<code>%t</code>)</dt>
-<dd>The time that the server finished processing the request. The
-format is:
-<BLOCKQUOTE><CODE> [day/month/year:hour:minute:second zone] <BR>
-day = 2*digit<BR>
-month = 3*letter<BR>
-year = 4*digit<BR>
-hour = 2*digit<BR>
-minute = 2*digit<BR>
-second = 2*digit<BR>
-zone = (`+' | `-') 4*digit</CODE></BLOCKQUOTE>
-It is possible to have the time displayed in another format
-by specifying <code>%{format}t</code> in the log format string, where
-<code>format</code> is as in <code>strftime(3)</code> from the C
-standard library.
-</dd>
-
-<dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
-(<code>\"%r\"</code>)</dt> <dd>The request line from the client is
-given in double quotes. The request line contains a great deal of
-useful information. First, the method used by the client is
-<code>GET</code>. Second, the client requested the resource
-<code>/apache_pb.gif</code>, and third, the client used the protocol
-<code>HTTP/1.0</code>. It is also possible to log one or more
-parts of the request line independently. For example, the format
-string "<code>%m %U%q %H</code>" will log the method, path,
-query-string, and protocol, resulting in exactly the same output as
-"<code>%r</code>".</dd>
-
-<dt><code>200</code> (<code>%>s</code>)</dt> <dd>This is the status
-code that the server sends back to the client. This information is
-very valuable, because it reveals whether the request resulted in a
-successful response (codes beginning in 2), a redirection (codes
-beginning in 3), an error caused by the client (codes beginning in 4),
-or an error in the server (codes beginning in 5).
-The full list of possible status codes can be
-found in the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt"
->HTTP specification</a> (RFC2616 section 10).</dd>
-
-<dt><code>2326</code> (<code>%b</code>)
-<dd>The last entry indicates the size of the object returned to
-the client, not including the response headers. If no content
-was returned to the client, this value will be "<code>-</code>".
-To log "<code>0</code>" for no content, use <code>%B</code>
-instead.</dd>
-
-</dl>
-
-<h4><a name="combined">Combined Log Format</a></h4>
-
-<p>Another commonly used format string is called the
-Combined Log Format. It can be used as follows.</p>
-
-<blockquote><code>
-LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined<br>
-CustomLog log/acces_log combined
-</code></blockquote>
-
-<p>This format is exactly the same as the Common Log Format, with the
-addition of two more fields. Each of the additional fields uses the
-percent-directive <code>%{<em>header</em>}i</code>, where
-<em>header</em> can be any HTTP request header. The access log under
-this format will look like:</p>
-
-<blockquote><code>
-127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
-</code></blockquote>
-
-<p>The additional fields are:</p>
-
-<dl>
-
-<dt><code>"http://www.example.com/start.html"</code>
-(<code>\"%{Referer}i\"</code>)</dt> <dd>The "Referer" (sic) HTTP
-request header. This gives the site that the client reports having
-been referred from. (This should be the page that links to or includes
-<code>/apache_pb.gif</code>).
-
-<dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
-(<code>\"%{User-agent}i\"</code>)</dt> <dd>The User-Agent HTTP request
-header. This is the identifying information that the client browser
-reports about itself.</dd>
-
-</dl>
-
-<h3><a name="multiple">Multiple Access Logs</a></h3>
-
-<p>Multiple access logs can be created simply by specifying multiple
-<code>CustomLog</code> directives in the configuration file. For
-example, the following directives will create three access logs. The
-first contains the basic CLF information, while the second and third
-contain referer and browser information. The last two
-<code>CustomLog</code> lines show how to mimic the effects of the
-<code>ReferLog</code> and <code>AgentLog</code> directives.</p>
-
-<blockquote><code>
-LogFormat "%h %l %u %t \"%r\" %>s %b" common<br>
-CustomLog logs/access_log common<br>
-CustomLog logs/referer_log "%{Referer}i -> %U"<br>
-CustomLog logs/agent_log "%{User-agent}i"
-</code></blockquote>
-
-<p>This example also shows that it is not necessary to define a
-nickname with the <code>LogFormat</code> directive. Instead, the log
-format can be specified directly in the <code>CustomLog</code>
-directive.</p>
-
-<h3><a name="conditional">Conditional Logging</a></h3>
-
-<p>There are times when it is convenient to exclude certain entries
-from the access logs based on characteristics of the client request.
-This is easily accomplished with the help of <a
-href="env.html">environment variables</a>. First, an environment
-variable must be set to indicate that the request meets certain
-conditions. This is usually accomplished with <a
-href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>. Then the
-<code>env=</code> clause of the <code>CustomLog</code> directive is
-used to include or exclude requests where the environment variable is
-set. Some examples:</p>
-
-<blockquote><code>
-# Mark requests from the loop-back interface<br>
-SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br>
-# Mark requests for the robots.txt file<br>
-SetEnvIf Request_URI "^/robots\.txt$" dontlog<br>
-# Log what remains<br>
-CustomLog logs/access_log common env=!dontlog
-</code></blockquote>
-
-<p>As another example, consider logging requests from english-speakers
-to one log file, and non-english speakers to a different log file.</p>
-
-<blockquote><code>
-SetEnvIf Accept-Language "en" english<br>
-CustomLog logs/english_log common env=english<br>
-CustomLog logs/non_english_log common env=!english
-</code></blockquote>
-
-<p>Although we have just shown that conditional logging is very
-powerful and flexibly, it is not the only way to control the contents
-of the logs. Log files are more useful when they contain a complete
-record of server activity. It is often easier to simply post-process
-the log files to remove requests that you do not want to consider.</p>
-
-<hr>
-
-<h2><a name="rotation">Log Rotation</a></h2>
-
-<p>On even a moderately busy server, the quantity of information
-stored in the log files is very large. The access log file typically
-grows 1 MB or more per 10,000 requests. It will consequently be
-necessary to periodically rotate the log files by moving or deleting
-the existing logs. This cannot be done while the server is running,
-because Apache will continue writing to the old log file as long as it
-holds the file open. Instead, the server must be <a
-href="stopping.html">restarted</a> after the log files are moved or
-deleted so that it will open new log files.</p>
-
-<p>By using a <em>graceful</em> restart, the server can be instructed
-to open new log files without losing any existing or pending
-connections from clients. However, in order to accomplish this, the
-server must continue to write to the old log files while it finishes
-serving old requests. It is therefore necessary to wait for some time
-after the restart before doing any processing on the log files. A
-typical scenario that simply rotates the logs and compresses the old
-logs to save space is:</p>
-
-<blockquote><code>
-mv access_log access_log.old<br>
-mv error_log error_log.old<br>
-apachectl graceful<br>
-sleep 600<br>
-gzip access_log.old error_log.old
-</code></blockquote>
-
-<p>Another way to perform log rotation is using <a href="#piped">piped
-logs</a> as discussed in the next section.</p>
-
-<hr>
-
-<h2><a name="piped">Piped Logs</a></h2>
-
-<p>Apache httpd is capable of writing error and access log files
-through a pipe to another process, rather than directly to a file.
-This capability dramatically increases the flexibility of logging,
-without adding code to the main server. In order to write logs to a
-pipe, simply replace the filename with the pipe character
-"<code>|</code>", followed by the name of the executable which should
-accept log entries on its standard input. Apache will start the
-piped-log process when the server starts, and will restart it if it
-crashes while the server is running. (This last feature is why we can
-refer to this technique as "reliable piped logging".)</p>
-
-<p>Piped log processes are spawned by the parent Apache httpd process,
-and inherit the userid of that process. This means that piped log
-programs usually run as root. It is therefore very important to keep
-the programs simple and secure.</p>
-
-<p>Some simple examples using piped logs:</p>
-
-<blockquote><code>
-# compressed logs<br>
-CustomLog "|/usr/bin/gzip -c >> /var/log/access_log.gz" common<br>
-# almost-real-time name resolution<br>
-CustomLog "|/usr/local/apache/bin/logresolve >> /var/log/access_log" common
-</code></blockquote>
-
-<p>Notice that quotes are used to enclose the entire command
-that will be called for the pipe. Although these examples are
-for the access log, the same technique can be used for the
-error log.</p>
-
-<p>One important use of piped logs is to allow log rotation without
-having to restart the server. The Apache HTTP Server includes a
-simple program called <a
-href="programs/rotatelogs.html">rotatelogs</a> for this purpose. For
-example, to rotate the logs every 24 hours, you can use:</p>
-
-<blockquote><code>
-CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
-</code></blockquote>
-
-<p>A similar, but much more flexible log rotation program
-called <a href="http://www.ford-mason.co.uk/resources/cronolog/">cronolog</a>
-is available at an external site.</p>
-
-<p>As with conditional logging, piped logs are a very powerful tool,
-but they should not be used where a simpler solution like
-off-line post-processing is available.</p>
-
-<hr>
-
-<h2><a name="virtualhosts">Virtual Hosts</a></h2>
-
-<p>When running a server with many <a href="vhosts/">virtual
-hosts</a>, there are several options for dealing with log files.
-First, it is possible to use logs exactly as in a single-host server.
-Simply by placing the logging directives outside the
-<code><VirtualHost></code> sections in the main server context,
-it is possible to log all requests in the same access log and error
-log. This technique does not allow for easy collection of statistics
-on individual virtual hosts.</p>
-
-<p>If <code>CustomLog</code> or <code>ErrorLog</code> directives are
-placed inside a <code><VirtualHost></code> section, all requests
-or errors for that virtual host will be logged only to the specified
-file. Any virtual host which does not have logging directives will
-still have its requests sent to the main server logs. This technique
-is very useful for a small number of virtual hosts, but if the number
-of hosts is very large, it can be complicated to manage. In addition,
-it can often create problems with <a
-href="vhosts/fd-limits.html">insufficient file descriptors</a>.</p>
-
-<p>For the access log, there is a very good compromise. By adding
-information on the virtual host to the log format string,
-it is possible to log all hosts to the same log, and later
-split the log into individual files. For example, consider the
-following directives.</p>
-
-<blockquote><code>
-LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost<br>
-CustomLog logs/access_log comonvhost
-</code></blockquote>
-
-<p>The <code>%v</code> is used to log the name of the virtual host
-that is serving the request. Then a program like <a
-href="programs/other.html">split-logfile</a> can be used to
-post-process the access log in order to split it into one file per
-virtual host.</p>
-
-<p>Unfortunately, no similar technique is available for the error log,
-so you must choose between mixing all virtual hosts in the same error
-log and using one error log per virtual host.</p>
-
-<hr>
-
-<h2><a name="other">Other Log Files</a></h2>
-
-<table border=1><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_cgi.html">mod_cgi</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/core.html#pidfile">PidFile</a><br>
-<a href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a></br>
-<a href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a></br>
-<a href="mod/mod_cgi.html#scriptlog">ScriptLog</a><br>
-<a href="mod/mod_cgi.html#scriptloglength">ScriptLogLength</a><br>
-<a href="mod/mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</a>
-
-</td></tr></table>
-
-<h3><a name="pidfile">PID File</a></h3>
-
-<p>On startup, Apache httpd saves the process id of the parent httpd
-process to the file <code>logs/httpd.pid</code>. This filename can be
-changed with the <A HREF="mod/core.html#pidfile">PidFile</A>
-directive. The process-id is for use by the administrator in
-restarting and terminating the daemon by sending signals
-to the parent process; on Windows, use the -k command line
-option instead. For more information see the <A
-HREF="stopping.html">Stopping and Restarting</A> page.
-
-<h3><a name="scriptlog">Script Log</a></h3>
-
-<p>In order to aid in debugging, the
-<a href="mod/mod_cgi.html#scriptlog">ScriptLog</a>
-directive allows you to record the input to and output from
-CGI scripts. This should only be used in testing - not for
-live servers. More information is available in the
-<a href="mod/mod_cgi.html">mod_cgi documentation</a>.
-
-<h3><a name="rewritelog">Rewrite Log</a></h3>
-
-<p>When using the powerful and complex features of <a
-href="mod/mod_rewrite.html">mod_rewrite</a>, it is almost always
-necessary to use the <a
-href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a> to help in
-debugging. This log file produces a detailed analysis of how the
-rewriting engine transforms requests. The level of detail is
-controlled by the <a
-href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a>
-directive.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Log Files - Apache HTTP Server</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Log Files</h1>
+
+ <p>In order to effectively manage a web server, it is necessary
+ to get feedback about the activity and performance of the
+ server as well as any problems that may be occuring. The Apache
+ HTTP Server provides very comprehensive and flexible logging
+ capabilities. This document describes how to configure its
+ logging capabilities, and how to understand what the logs
+ contain.</p>
+
+ <ul>
+ <li><a href="#security">Security Warning</a></li>
+
+ <li><a href="#errorlog">Error Log</a></li>
+
+ <li>
+ <a href="#accesslog">Access Log</a>
+
+ <ul>
+ <li><a href="#common">Common Log Format</a></li>
+
+ <li><a href="#combined">Combined Log Format</a></li>
+
+ <li><a href="#multiple">Multiple Access Logs</a></li>
+
+ <li><a href="#conditional">Conditional Logging</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#rotation">Log Rotation</a></li>
+
+ <li><a href="#piped">Piped Logs</a></li>
+
+ <li><a href="#virtualhosts">VirtualHosts</a></li>
+
+ <li>
+ <a href="#other">Other Log Files</a>
+
+ <ul>
+ <li><a href="#pidfile">PID File</a></li>
+
+ <li><a href="#scriptlog">Script Log</a></li>
+
+ <li><a href="#rewritelog">Rewrite Log</a></li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+
+ <h2><a id="security" name="security">Security Warning</a></h2>
+
+ <p>Anyone who can write to the directory where Apache is
+ writing a log file can almost certainly gain access to the uid
+ that the server is started as, which is normally root. Do
+ <em>NOT</em> give people write access to the directory the logs
+ are stored in without being aware of the consequences; see the
+ <a href="misc/security_tips.html">security tips</a> document
+ for details.</p>
+
+ <p>In addition, log files may contain information supplied
+ directly by the client, without escaping. Therefore, it is
+ possible for malicious clients to insert control-characters in
+ the log files, so care must be taken in dealing with raw
+ logs.</p>
+ <hr />
+
+ <h2><a id="errorlog" name="errorlog">Error Log</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/core.html#errorlog">ErrorLog</a><br />
+ <a href="mod/core.html#loglevel">LogLevel</a> </td>
+ </tr>
+ </table>
+
+ <p>The server error log, whose name and location is set by the
+ <a href="mod/core.html#errorlog">ErrorLog</a> directive, is the
+ most important log file. This is the place where Apache httpd
+ will send diagnostic information and record any errors that it
+ encounters in processing requests. It is the first place to
+ look when a problem occurs with starting the server or with the
+ operation of the server, since it will often contain details of
+ what went wrong and how to fix it.</p>
+
+ <p>The error log is usually written to a file (typically
+ <code>error_log</code> on unix systems and
+ <code>error.log</code> on Windows and OS/2). On unix systems it
+ is also possible to have the server send errors to
+ <code>syslog</code> or <a href="#pipe">pipe them to a
+ program</a>.</p>
+
+ <p>The format of the error log is relatively free-form and
+ descriptive. But there is certain information that is contained
+ in most error log entries. For example, here is a typical
+ message.</p>
+
+ <blockquote>
+ <code>[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
+ client denied by server configuration:
+ /export/home/live/ap/htdocs/test</code>
+ </blockquote>
+
+ <p>The first item in the log entry is the date and time of the
+ message. The second entry lists the severity of the error being
+ reported. The <a href="mod/core.html#loglevel">LogLevel</a>
+ directive is used to control the types of errors that are sent
+ to the error log by restricting the severity level. The third
+ entry gives the IP address of the client that generated the
+ error. Beyond that is the message itself, which in this case
+ indicates that the server has been configured to deny the
+ client access. The server reports the file-system path (as
+ opposed to the web path) of the requested document.</p>
+
+ <p>A very wide variety of different messages can appear in the
+ error log. Most look similar to the example above. The error
+ log will also contain debugging output from CGI scripts. Any
+ information written to <code>stderr</code> by a CGI script will
+ be copied directly to the error log.</p>
+
+ <p>It is not possible to customize the error log by adding or
+ removing information. However, error log entries dealing with
+ particular requests have corresponding entries in the <a
+ href="accesslog">access log</a>. For example, the above example
+ entry corresponds to an access log entry with status code 403.
+ Since it is possible to customize the access log, you can
+ obtain more information about error conditions using that log
+ file.</p>
+
+ <p>During testing, it is often useful to continuously monitor
+ the error log for any problems. On unix systems, you can
+ accomplish this using:</p>
+
+ <blockquote>
+ <code>tail -f error_log</code>
+ </blockquote>
+ <hr />
+
+ <h2><a id="accesslog" name="accesslog">Access Log</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_log_config.html">mod_log_config</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a><br />
+ <a
+ href="mod/mod_log_config.html#logformat">LogFormat</a><br />
+ <a href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>
+ </td>
+ </tr>
+ </table>
+
+ <p>The server access log records all requests processed by the
+ server. The location and content of the access log are
+ controlled by the <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a>
+ directive. The <a
+ href="mod/mod_log_config.html#logformat">LogFormat</a>
+ directive can be used to simplify the selection of the contents
+ of the logs. This section describes how to configure the server
+ to record information in the access log.</p>
+
+ <p>Of course, storing the information in the access log is only
+ the start of log management. The next step is to analyze this
+ information to produce useful statistics. Log analysis in
+ general is beyond the scope of this document, and not really
+ part of the job of the web server itself. For more information
+ about this topic, and for applications which perform log
+ analysis, check the <a
+ href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/">
+ Open Directory</a> or <a
+ href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">
+ Yahoo</a>.</p>
+
+ <p>Various versions of Apache httpd have used other modules and
+ directives to control access logging, including
+ mod_log_referer, mod_log_agent, and the
+ <code>TransferLog</code> directive. The <code>CustomLog</code>
+ directive now subsumes the functionality of all the older
+ directives.</p>
+
+ <p>The format of the access log is highly configurable. The
+ format is specified using a <a
+ href="mod/mod_log_config.html#format">format string</a> that
+ looks much like a C-style printf(1) format string. Some
+ examples are presented in the next sections. For a complete
+ list of the possible contents of the format string, see the <a
+ href="mod/mod_log_config.html">mod_log_config
+ documentation</a>.</p>
+
+ <h3><a id="common" name="common">Common Log Format</a></h3>
+
+ <p>A typical configuration for the access log might look as
+ follows.</p>
+
+ <blockquote>
+ <code>LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common</code>
+ </blockquote>
+
+ <p>This defines the <em>nickname</em> <code>common</code> and
+ associates it with a particular log format string. The format
+ string consists of percent directives, each of which tell the
+ server to log a particular piece of information. Literal
+ characters may also be placed in the format string and will be
+ copied directly into the log output. The quote character
+ (<code>"</code>) must be escaped by placing a back-slash before
+ it to prevent it from being interpreted as the end of the
+ format string. The format string may also contain the special
+ control characters "<code>\n</code>" for new-line and
+ "<code>\t</code>" for tab.</p>
+
+ <p>The <code>CustomLog</code> directive sets up a new log file
+ using the defined <em>nickname</em>. The filename for the
+ access log is relative to the <a
+ href="mod/core.html#serverroot">ServerRoot</a> unless it begins
+ with a slash.</p>
+
+ <p>The above configuration will write log entries in a format
+ known as the Common Log Format (CLF). This standard format can
+ be produced by many different web servers and read by many log
+ analysis programs. The log file entries produced in CLF will
+ look something like this:</p>
+
+ <blockquote>
+ <code>127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326</code>
+ </blockquote>
+
+ <p>Each part of this log entry is described below.</p>
+
+ <dl>
+ <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
+
+ <dd>This is the IP address of the client (remote host) which
+ made the request to the server. If <a
+ href="mod/core.html#hostnamelookups">HostNameLookups</a> is
+ set to <code>On</code>, then the server will try to determine
+ the hostname and log it in place of the IP address. However,
+ this configuration is not recommended since it can
+ significantly slow the server. Instead, it is best to use a
+ log post-processor such as <a
+ href="programs/logresolve.html">logresolve</a> to determine
+ the hostnames. The IP address reported here is not
+ necessarily the address of the machine at which the user is
+ sitting. If a proxy server exists between the user and the
+ server, this address will be the address of the proxy, rather
+ than the originating machine.</dd>
+
+ <dt><code>-</code> (<code>%l</code>)</dt>
+
+ <dd>The "hyphen" in the output indicates that the requested
+ piece of information is not available. In this case, the
+ information that is not available is the RFC 1413 identity of
+ the client determined by <code>identd</code> on the clients
+ machine. This information is highly unreliable and should
+ almost never be used except on tightly controlled internal
+ networks. Apache httpd will not even attempt to determine
+ this information unless <a
+ href="mod/core.html#identitycheck">IdentityCheck</a> is set
+ to <code>On</code>.</dd>
+
+ <dt><code>frank</code> (<code>%u</code>)</dt>
+
+ <dd>This is the userid of the person requesting the document
+ as determined by HTTP authentication. The same value is
+ typically provided to CGI scripts in the
+ <code>REMOTE_USER</code> environment variable. If the status
+ code for the request (see below) is 401, then this value
+ should not be trusted because the user is not yet
+ authenticated. If the document is not password protected,
+ this entry will be "<code>-</code>" just like the previous
+ one.</dd>
+
+ <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
+ (<code>%t</code>)</dt>
+
+ <dd>
+ The time that the server finished processing the request.
+ The format is:
+
+ <blockquote>
+ <code>[day/month/year:hour:minute:second zone]<br />
+ day = 2*digit<br />
+ month = 3*letter<br />
+ year = 4*digit<br />
+ hour = 2*digit<br />
+ minute = 2*digit<br />
+ second = 2*digit<br />
+ zone = (`+' | `-') 4*digit</code>
+ </blockquote>
+ It is possible to have the time displayed in another format
+ by specifying <code>%{format}t</code> in the log format
+ string, where <code>format</code> is as in
+ <code>strftime(3)</code> from the C standard library.
+ </dd>
+
+ <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
+ (<code>\"%r\"</code>)</dt>
+
+ <dd>The request line from the client is given in double
+ quotes. The request line contains a great deal of useful
+ information. First, the method used by the client is
+ <code>GET</code>. Second, the client requested the resource
+ <code>/apache_pb.gif</code>, and third, the client used the
+ protocol <code>HTTP/1.0</code>. It is also possible to log
+ one or more parts of the request line independently. For
+ example, the format string "<code>%m %U%q %H</code>" will log
+ the method, path, query-string, and protocol, resulting in
+ exactly the same output as "<code>%r</code>".</dd>
+
+ <dt><code>200</code> (<code>%>s</code>)</dt>
+
+ <dd>This is the status code that the server sends back to the
+ client. This information is very valuable, because it reveals
+ whether the request resulted in a successful response (codes
+ beginning in 2), a redirection (codes beginning in 3), an
+ error caused by the client (codes beginning in 4), or an
+ error in the server (codes beginning in 5). The full list of
+ possible status codes can be found in the <a
+ href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">HTTP
+ specification</a> (RFC2616 section 10).</dd>
+
+ <dt><code>2326</code> (<code>%b</code>)</dt>
+
+ <dd>The last entry indicates the size of the object returned
+ to the client, not including the response headers. If no
+ content was returned to the client, this value will be
+ "<code>-</code>". To log "<code>0</code>" for no content, use
+ <code>%B</code> instead.</dd>
+ </dl>
+
+ <h4><a id="combined" name="combined">Combined Log
+ Format</a></h4>
+
+ <p>Another commonly used format string is called the Combined
+ Log Format. It can be used as follows.</p>
+
+ <blockquote>
+ <code>LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\"" combined<br />
+ CustomLog log/acces_log combined</code>
+ </blockquote>
+
+ <p>This format is exactly the same as the Common Log Format,
+ with the addition of two more fields. Each of the additional
+ fields uses the percent-directive
+ <code>%{<em>header</em>}i</code>, where <em>header</em> can be
+ any HTTP request header. The access log under this format will
+ look like:</p>
+
+ <blockquote>
+ <code>127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ "http://www.example.com/start.html" "Mozilla/4.08 [en]
+ (Win98; I ;Nav)"</code>
+ </blockquote>
+
+ <p>The additional fields are:</p>
+
+ <dl>
+ <dt><code>"http://www.example.com/start.html"</code>
+ (<code>\"%{Referer}i\"</code>)</dt>
+
+ <dd>The "Referer" (sic) HTTP request header. This gives the
+ site that the client reports having been referred from. (This
+ should be the page that links to or includes
+ <code>/apache_pb.gif</code>).</dd>
+
+ <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
+ (<code>\"%{User-agent}i\"</code>)</dt>
+
+ <dd>The User-Agent HTTP request header. This is the
+ identifying information that the client browser reports about
+ itself.</dd>
+ </dl>
+
+ <h3><a id="multiple" name="multiple">Multiple Access
+ Logs</a></h3>
+
+ <p>Multiple access logs can be created simply by specifying
+ multiple <code>CustomLog</code> directives in the configuration
+ file. For example, the following directives will create three
+ access logs. The first contains the basic CLF information,
+ while the second and third contain referer and browser
+ information. The last two <code>CustomLog</code> lines show how
+ to mimic the effects of the <code>ReferLog</code> and
+ <code>AgentLog</code> directives.</p>
+
+ <blockquote>
+ <code>LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common<br />
+ CustomLog logs/referer_log "%{Referer}i -> %U"<br />
+ CustomLog logs/agent_log "%{User-agent}i"</code>
+ </blockquote>
+
+ <p>This example also shows that it is not necessary to define a
+ nickname with the <code>LogFormat</code> directive. Instead,
+ the log format can be specified directly in the
+ <code>CustomLog</code> directive.</p>
+
+ <h3><a id="conditional" name="conditional">Conditional
+ Logging</a></h3>
+
+ <p>There are times when it is convenient to exclude certain
+ entries from the access logs based on characteristics of the
+ client request. This is easily accomplished with the help of <a
+ href="env.html">environment variables</a>. First, an
+ environment variable must be set to indicate that the request
+ meets certain conditions. This is usually accomplished with <a
+ href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>. Then the
+ <code>env=</code> clause of the <code>CustomLog</code>
+ directive is used to include or exclude requests where the
+ environment variable is set. Some examples:</p>
+
+ <blockquote>
+ <code># Mark requests from the loop-back interface<br />
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
+ # Mark requests for the robots.txt file<br />
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
+ # Log what remains<br />
+ CustomLog logs/access_log common env=!dontlog</code>
+ </blockquote>
+
+ <p>As another example, consider logging requests from
+ english-speakers to one log file, and non-english speakers to a
+ different log file.</p>
+
+ <blockquote>
+ <code>SetEnvIf Accept-Language "en" english<br />
+ CustomLog logs/english_log common env=english<br />
+ CustomLog logs/non_english_log common env=!english</code>
+ </blockquote>
+
+ <p>Although we have just shown that conditional logging is very
+ powerful and flexibly, it is not the only way to control the
+ contents of the logs. Log files are more useful when they
+ contain a complete record of server activity. It is often
+ easier to simply post-process the log files to remove requests
+ that you do not want to consider.</p>
+ <hr />
+
+ <h2><a id="rotation" name="rotation">Log Rotation</a></h2>
+
+ <p>On even a moderately busy server, the quantity of
+ information stored in the log files is very large. The access
+ log file typically grows 1 MB or more per 10,000 requests. It
+ will consequently be necessary to periodically rotate the log
+ files by moving or deleting the existing logs. This cannot be
+ done while the server is running, because Apache will continue
+ writing to the old log file as long as it holds the file open.
+ Instead, the server must be <a
+ href="stopping.html">restarted</a> after the log files are
+ moved or deleted so that it will open new log files.</p>
+
+ <p>By using a <em>graceful</em> restart, the server can be
+ instructed to open new log files without losing any existing or
+ pending connections from clients. However, in order to
+ accomplish this, the server must continue to write to the old
+ log files while it finishes serving old requests. It is
+ therefore necessary to wait for some time after the restart
+ before doing any processing on the log files. A typical
+ scenario that simply rotates the logs and compresses the old
+ logs to save space is:</p>
+
+ <blockquote>
+ <code>mv access_log access_log.old<br />
+ mv error_log error_log.old<br />
+ apachectl graceful<br />
+ sleep 600<br />
+ gzip access_log.old error_log.old</code>
+ </blockquote>
+
+ <p>Another way to perform log rotation is using <a
+ href="#piped">piped logs</a> as discussed in the next
+ section.</p>
+ <hr />
+
+ <h2><a id="piped" name="piped">Piped Logs</a></h2>
+
+ <p>Apache httpd is capable of writing error and access log
+ files through a pipe to another process, rather than directly
+ to a file. This capability dramatically increases the
+ flexibility of logging, without adding code to the main server.
+ In order to write logs to a pipe, simply replace the filename
+ with the pipe character "<code>|</code>", followed by the name
+ of the executable which should accept log entries on its
+ standard input. Apache will start the piped-log process when
+ the server starts, and will restart it if it crashes while the
+ server is running. (This last feature is why we can refer to
+ this technique as "reliable piped logging".)</p>
+
+ <p>Piped log processes are spawned by the parent Apache httpd
+ process, and inherit the userid of that process. This means
+ that piped log programs usually run as root. It is therefore
+ very important to keep the programs simple and secure.</p>
+
+ <p>Some simple examples using piped logs:</p>
+
+ <blockquote>
+ <code># compressed logs<br />
+ CustomLog "|/usr/bin/gzip -c >>
+ /var/log/access_log.gz" common<br />
+ # almost-real-time name resolution<br />
+ CustomLog "|/usr/local/apache/bin/logresolve >>
+ /var/log/access_log" common</code>
+ </blockquote>
+
+ <p>Notice that quotes are used to enclose the entire command
+ that will be called for the pipe. Although these examples are
+ for the access log, the same technique can be used for the
+ error log.</p>
+
+ <p>One important use of piped logs is to allow log rotation
+ without having to restart the server. The Apache HTTP Server
+ includes a simple program called <a
+ href="programs/rotatelogs.html">rotatelogs</a> for this
+ purpose. For example, to rotate the logs every 24 hours, you
+ can use:</p>
+
+ <blockquote>
+ <code>CustomLog "|/usr/local/apache/bin/rotatelogs
+ /var/log/access_log 86400" common</code>
+ </blockquote>
+
+ <p>A similar, but much more flexible log rotation program
+ called <a
+ href="http://www.ford-mason.co.uk/resources/cronolog/">cronolog</a>
+ is available at an external site.</p>
+
+ <p>As with conditional logging, piped logs are a very powerful
+ tool, but they should not be used where a simpler solution like
+ off-line post-processing is available.</p>
+ <hr />
+
+ <h2><a id="virtualhosts" name="virtualhosts">Virtual
+ Hosts</a></h2>
+
+ <p>When running a server with many <a href="vhosts/">virtual
+ hosts</a>, there are several options for dealing with log
+ files. First, it is possible to use logs exactly as in a
+ single-host server. Simply by placing the logging directives
+ outside the <code><VirtualHost></code> sections in the
+ main server context, it is possible to log all requests in the
+ same access log and error log. This technique does not allow
+ for easy collection of statistics on individual virtual
+ hosts.</p>
+
+ <p>If <code>CustomLog</code> or <code>ErrorLog</code>
+ directives are placed inside a <code><VirtualHost></code>
+ section, all requests or errors for that virtual host will be
+ logged only to the specified file. Any virtual host which does
+ not have logging directives will still have its requests sent
+ to the main server logs. This technique is very useful for a
+ small number of virtual hosts, but if the number of hosts is
+ very large, it can be complicated to manage. In addition, it
+ can often create problems with <a
+ href="vhosts/fd-limits.html">insufficient file
+ descriptors</a>.</p>
+
+ <p>For the access log, there is a very good compromise. By
+ adding information on the virtual host to the log format
+ string, it is possible to log all hosts to the same log, and
+ later split the log into individual files. For example,
+ consider the following directives.</p>
+
+ <blockquote>
+ <code>LogFormat "%v %l %u %t \"%r\" %>s %b"
+ comonvhost<br />
+ CustomLog logs/access_log comonvhost</code>
+ </blockquote>
+
+ <p>The <code>%v</code> is used to log the name of the virtual
+ host that is serving the request. Then a program like <a
+ href="programs/other.html">split-logfile</a> can be used to
+ post-process the access log in order to split it into one file
+ per virtual host.</p>
+
+ <p>Unfortunately, no similar technique is available for the
+ error log, so you must choose between mixing all virtual hosts
+ in the same error log and using one error log per virtual
+ host.</p>
+ <hr />
+
+ <h2><a id="other" name="other">Other Log Files</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_cgi.html">mod_cgi</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a> </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/core.html#pidfile">PidFile</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a><br />
+ <a href="mod/mod_cgi.html#scriptlog">ScriptLog</a><br />
+ <a
+ href="mod/mod_cgi.html#scriptloglength">ScriptLogLength</a><br />
+ <a
+ href="mod/mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</a>
+ </td>
+ </tr>
+ </table>
+
+ <h3><a id="pidfile" name="pidfile">PID File</a></h3>
+
+ <p>On startup, Apache httpd saves the process id of the parent
+ httpd process to the file <code>logs/httpd.pid</code>. This
+ filename can be changed with the <a
+ href="mod/core.html#pidfile">PidFile</a> directive. The
+ process-id is for use by the administrator in restarting and
+ terminating the daemon by sending signals to the parent
+ process; on Windows, use the -k command line option instead.
+ For more information see the <a href="stopping.html">Stopping
+ and Restarting</a> page.</p>
+
+ <h3><a id="scriptlog" name="scriptlog">Script Log</a></h3>
+
+ <p>In order to aid in debugging, the <a
+ href="mod/mod_cgi.html#scriptlog">ScriptLog</a> directive
+ allows you to record the input to and output from CGI scripts.
+ This should only be used in testing - not for live servers.
+ More information is available in the <a
+ href="mod/mod_cgi.html">mod_cgi documentation</a>.</p>
+
+ <h3><a id="rewritelog" name="rewritelog">Rewrite Log</a></h3>
+
+ <p>When using the powerful and complex features of <a
+ href="mod/mod_rewrite.html">mod_rewrite</a>, it is almost
+ always necessary to use the <a
+ href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a> to help
+ in debugging. This log file produces a detailed analysis of how
+ the rewriting engine transforms requests. The level of detail
+ is controlled by the <a
+ href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a>
+ directive.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Log Files - Apache HTTP Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Log Files</h1>
-
-<p>In order to effectively manage a web server, it is necessary to get
-feedback about the activity and performance of the server as well as
-any problems that may be occuring. The Apache HTTP Server provides
-very comprehensive and flexible logging capabilities. This document
-describes how to configure its logging capabilities, and how to
-understand what the logs contain.</p>
-
-<ul>
-<li><a href="#security">Security Warning</a></li>
-<li><a href="#errorlog">Error Log</a></li>
-<li><a href="#accesslog">Access Log</a>
- <ul>
- <li><a href="#common">Common Log Format</a></li>
- <li><a href="#combined">Combined Log Format</a></li>
- <li><a href="#multiple">Multiple Access Logs</a></li>
- <li><a href="#conditional">Conditional Logging</a></li>
- </ul></li>
-<li><a href="#rotation">Log Rotation</a></li>
-<li><a href="#piped">Piped Logs</a></li>
-<li><a href="#virtualhosts">VirtualHosts</a>
-<li><a href="#other">Other Log Files</a>
- <ul>
- <li><a href="#pidfile">PID File</a></li>
- <li><a href="#scriptlog">Script Log</a></li>
- <li><a href="#rewritelog">Rewrite Log</a></li>
- </ul></li>
-</ul>
-
-<hr>
-
-<h2><a name="security">Security Warning</a></h2>
-
-<p>Anyone who can write to the directory where Apache is writing a
-log file can almost certainly gain access to the uid that the server is
-started as, which is normally root. Do <EM>NOT</EM> give people write
-access to the directory the logs are stored in without being aware of
-the consequences; see the <A HREF="misc/security_tips.html">security tips</A>
-document for details.</p>
-
-<p>In addition, log files may contain information supplied directly
-by the client, without escaping. Therefore, it is possible for
-malicious clients to insert control-characters in the log files, so
-care must be taken in dealing with raw logs.</p>
-
-<hr>
-
-<h2><a name="errorlog">Error Log</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/core.html#errorlog">ErrorLog</a><br>
-<a href="mod/core.html#loglevel">LogLevel</a>
-</td></tr></table>
-
-<p>The server error log, whose name and location is set by the <a
-href="mod/core.html#errorlog">ErrorLog</a> directive, is the most
-important log file. This is the place where Apache httpd will send
-diagnostic information and record any errors that it encounters in
-processing requests. It is the first place to look when a problem
-occurs with starting the server or with the operation of the server,
-since it will often contain details of what went wrong and how to fix
-it.</p>
-
-<p>The error log is usually written to a file (typically
-<code>error_log</code> on unix systems and <code>error.log</code> on
-Windows and OS/2). On unix systems it is also possible to have the
-server send errors to <code>syslog</code> or <a href="#pipe">pipe
-them to a program</a>.</p>
-
-<p>The format of the error log is relatively free-form and
-descriptive. But there is certain information that is contained
-in most error log entries. For example, here is a typical message.</p>
-
-<blockquote><code>
-[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test
-</code></blockquote>
-
-<p>The first item in the log entry is the date and time of the
-message. The second entry lists the severity of the error being
-reported. The <a href="mod/core.html#loglevel">LogLevel</a> directive
-is used to control the types of errors that are sent to the error log
-by restricting the severity level. The third entry gives the IP
-address of the client that generated the error. Beyond that is the
-message itself, which in this case indicates that the server has been
-configured to deny the client access. The server reports the
-file-system path (as opposed to the web path) of the requested
-document.</p>
-
-<p>A very wide variety of different messages can appear in the error
-log. Most look similar to the example above. The error log will also
-contain debugging output from CGI scripts. Any information written to
-<code>stderr</code> by a CGI script will be copied directly to the
-error log.</p>
-
-<p>It is not possible to customize the error log by adding or removing
-information. However, error log entries dealing with particular
-requests have corresponding entries in the <a href="accesslog">access
-log</a>. For example, the above example entry corresponds to an
-access log entry with status code 403. Since it is possible to
-customize the access log, you can obtain more information about error
-conditions using that log file.</p>
-
-<p>During testing, it is often useful to continuously monitor the
-error log for any problems. On unix systems, you can accomplish this
-using:</p>
-<blockquote><code>
-tail -f error_log
-</code></blockquote>
-
-<hr>
-
-<h2><a name="accesslog">Access Log</a></h2>
-
-<table border=1><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_log_config.html">mod_log_config</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/mod_log_config.html#customlog">CustomLog</a><br>
-<a href="mod/mod_log_config.html#logformat">LogFormat</a><br>
-<a href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>
-
-</td></tr></table>
-
-<p>The server access log records all requests processed by the server.
-The location and content of the access log are controlled
-by the <a href="mod/mod_log_config.html#customlog">CustomLog</a>
-directive. The <a
-href="mod/mod_log_config.html#logformat">LogFormat</a> directive can
-be used to simplify the selection of the contents of the logs.
-This section describes how to configure the server to record
-information in the access log.</p>
-
-<p>Of course, storing the information in the access log is only the
-start of log management. The next step is to analyze this information
-to produce useful statistics. Log analysis in general is beyond the
-scope of this document, and not really part of the job of the
-web server itself. For more information about this topic, and for
-applications which perform log analysis, check the <a
-href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/"
->Open Directory</a> or <a
-href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/"
->Yahoo</a>.</p>
-
-<p>Various versions of Apache httpd have used other modules and
-directives to control access logging, including mod_log_referer,
-mod_log_agent, and the <code>TransferLog</code> directive. The
-<code>CustomLog</code> directive now subsumes the functionality of all
-the older directives.</p>
-
-<p>The format of the access log is highly configurable. The format is
-specified using a <a href="mod/mod_log_config.html#format">format
-string</a> that looks much like a C-style printf(1) format string.
-Some examples are presented in the next sections. For a complete list
-of the possible contents of the format string, see the <a
-href="mod/mod_log_config.html">mod_log_config documentation</a>.</p>
-
-<h3><a name="common">Common Log Format</a></h3>
-
-<p>A typical configuration for the access log might look
-as follows.</p>
-
-<blockquote><code>
-LogFormat "%h %l %u %t \"%r\" %>s %b" common<br>
-CustomLog logs/access_log common
-</code></blockquote>
-
-<p>This defines the <em>nickname</em> <code>common</code> and
-associates it with a particular log format string. The format string
-consists of percent directives, each of which tell the server to log a
-particular piece of information. Literal characters may also be
-placed in the format string and will be copied directly into the log
-output. The quote character (<code>"</code>) must be escaped by
-placing a back-slash before it to prevent it from being interpreted as
-the end of the format string. The format string may also contain the
-special control characters "<code>\n</code>" for new-line and
-"<code>\t</code>" for tab.</p>
-
-<p>The <code>CustomLog</code> directive sets up a new log file using
-the defined <em>nickname</em>. The filename for the access log is
-relative to the <a href="mod/core.html#serverroot">ServerRoot</a>
-unless it begins with a slash.</p>
-
-<p>The above configuration will write log entries in a format known as
-the Common Log Format (CLF). This standard format can be produced by
-many different web servers and read by many log analysis programs.
-The log file entries produced in CLF will look something like
-this:</p>
-
-<blockquote><code>
-127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
-</code></blockquote>
-
-<p>Each part of this log entry is described below.</p>
-
-<dl>
-<dt><code>127.0.0.1</code> (<code>%h</code>)</dt> <dd>This is the IP
-address of the client (remote host) which made the request to the
-server. If <a
-href="mod/core.html#hostnamelookups">HostNameLookups</a> is set to
-<code>On</code>, then the server will try to determine the hostname
-and log it in place of the IP address. However, this configuration is
-not recommended since it can significantly slow the server. Instead,
-it is best to use a log post-processor such as <a
-href="programs/logresolve.html">logresolve</a> to determine the
-hostnames. The IP address reported here is not necessarily the
-address of the machine at which the user is sitting. If a proxy
-server exists between the user and the server, this address will be
-the address of the proxy, rather than the originating machine.</dd>
-
-<dt><code>-</code> (<code>%l</code>)</dt> <dd>The "hyphen" in the
-output indicates that the requested piece of information is not
-available. In this case, the information that is not available is the
-RFC 1413 identity of the client determined by <code>identd</code> on
-the clients machine. This information is highly unreliable and should
-almost never be used except on tightly controlled internal networks.
-Apache httpd will not even attempt to determine this information
-unless <a href="mod/core.html#identitycheck">IdentityCheck</a> is set
-to <code>On</code>.</dd>
-
-<dt><code>frank</code> (<code>%u</code>)</dt> <dd>This is the userid
-of the person requesting the document as determined by HTTP
-authentication. The same value is typically provided to CGI scripts
-in the <code>REMOTE_USER</code> environment variable. If the status
-code for the request (see below) is 401, then this value should not be
-trusted because the user is not yet authenticated. If the document is
-not password protected, this entry will be "<code>-</code>" just like
-the previous one.</dd>
-
-<dt><code>[10/Oct/2000:13:55:36 -0700]</code> (<code>%t</code>)</dt>
-<dd>The time that the server finished processing the request. The
-format is:
-<BLOCKQUOTE><CODE> [day/month/year:hour:minute:second zone] <BR>
-day = 2*digit<BR>
-month = 3*letter<BR>
-year = 4*digit<BR>
-hour = 2*digit<BR>
-minute = 2*digit<BR>
-second = 2*digit<BR>
-zone = (`+' | `-') 4*digit</CODE></BLOCKQUOTE>
-It is possible to have the time displayed in another format
-by specifying <code>%{format}t</code> in the log format string, where
-<code>format</code> is as in <code>strftime(3)</code> from the C
-standard library.
-</dd>
-
-<dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
-(<code>\"%r\"</code>)</dt> <dd>The request line from the client is
-given in double quotes. The request line contains a great deal of
-useful information. First, the method used by the client is
-<code>GET</code>. Second, the client requested the resource
-<code>/apache_pb.gif</code>, and third, the client used the protocol
-<code>HTTP/1.0</code>. It is also possible to log one or more
-parts of the request line independently. For example, the format
-string "<code>%m %U%q %H</code>" will log the method, path,
-query-string, and protocol, resulting in exactly the same output as
-"<code>%r</code>".</dd>
-
-<dt><code>200</code> (<code>%>s</code>)</dt> <dd>This is the status
-code that the server sends back to the client. This information is
-very valuable, because it reveals whether the request resulted in a
-successful response (codes beginning in 2), a redirection (codes
-beginning in 3), an error caused by the client (codes beginning in 4),
-or an error in the server (codes beginning in 5).
-The full list of possible status codes can be
-found in the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt"
->HTTP specification</a> (RFC2616 section 10).</dd>
-
-<dt><code>2326</code> (<code>%b</code>)
-<dd>The last entry indicates the size of the object returned to
-the client, not including the response headers. If no content
-was returned to the client, this value will be "<code>-</code>".
-To log "<code>0</code>" for no content, use <code>%B</code>
-instead.</dd>
-
-</dl>
-
-<h4><a name="combined">Combined Log Format</a></h4>
-
-<p>Another commonly used format string is called the
-Combined Log Format. It can be used as follows.</p>
-
-<blockquote><code>
-LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined<br>
-CustomLog log/acces_log combined
-</code></blockquote>
-
-<p>This format is exactly the same as the Common Log Format, with the
-addition of two more fields. Each of the additional fields uses the
-percent-directive <code>%{<em>header</em>}i</code>, where
-<em>header</em> can be any HTTP request header. The access log under
-this format will look like:</p>
-
-<blockquote><code>
-127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
-</code></blockquote>
-
-<p>The additional fields are:</p>
-
-<dl>
-
-<dt><code>"http://www.example.com/start.html"</code>
-(<code>\"%{Referer}i\"</code>)</dt> <dd>The "Referer" (sic) HTTP
-request header. This gives the site that the client reports having
-been referred from. (This should be the page that links to or includes
-<code>/apache_pb.gif</code>).
-
-<dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
-(<code>\"%{User-agent}i\"</code>)</dt> <dd>The User-Agent HTTP request
-header. This is the identifying information that the client browser
-reports about itself.</dd>
-
-</dl>
-
-<h3><a name="multiple">Multiple Access Logs</a></h3>
-
-<p>Multiple access logs can be created simply by specifying multiple
-<code>CustomLog</code> directives in the configuration file. For
-example, the following directives will create three access logs. The
-first contains the basic CLF information, while the second and third
-contain referer and browser information. The last two
-<code>CustomLog</code> lines show how to mimic the effects of the
-<code>ReferLog</code> and <code>AgentLog</code> directives.</p>
-
-<blockquote><code>
-LogFormat "%h %l %u %t \"%r\" %>s %b" common<br>
-CustomLog logs/access_log common<br>
-CustomLog logs/referer_log "%{Referer}i -> %U"<br>
-CustomLog logs/agent_log "%{User-agent}i"
-</code></blockquote>
-
-<p>This example also shows that it is not necessary to define a
-nickname with the <code>LogFormat</code> directive. Instead, the log
-format can be specified directly in the <code>CustomLog</code>
-directive.</p>
-
-<h3><a name="conditional">Conditional Logging</a></h3>
-
-<p>There are times when it is convenient to exclude certain entries
-from the access logs based on characteristics of the client request.
-This is easily accomplished with the help of <a
-href="env.html">environment variables</a>. First, an environment
-variable must be set to indicate that the request meets certain
-conditions. This is usually accomplished with <a
-href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>. Then the
-<code>env=</code> clause of the <code>CustomLog</code> directive is
-used to include or exclude requests where the environment variable is
-set. Some examples:</p>
-
-<blockquote><code>
-# Mark requests from the loop-back interface<br>
-SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br>
-# Mark requests for the robots.txt file<br>
-SetEnvIf Request_URI "^/robots\.txt$" dontlog<br>
-# Log what remains<br>
-CustomLog logs/access_log common env=!dontlog
-</code></blockquote>
-
-<p>As another example, consider logging requests from english-speakers
-to one log file, and non-english speakers to a different log file.</p>
-
-<blockquote><code>
-SetEnvIf Accept-Language "en" english<br>
-CustomLog logs/english_log common env=english<br>
-CustomLog logs/non_english_log common env=!english
-</code></blockquote>
-
-<p>Although we have just shown that conditional logging is very
-powerful and flexibly, it is not the only way to control the contents
-of the logs. Log files are more useful when they contain a complete
-record of server activity. It is often easier to simply post-process
-the log files to remove requests that you do not want to consider.</p>
-
-<hr>
-
-<h2><a name="rotation">Log Rotation</a></h2>
-
-<p>On even a moderately busy server, the quantity of information
-stored in the log files is very large. The access log file typically
-grows 1 MB or more per 10,000 requests. It will consequently be
-necessary to periodically rotate the log files by moving or deleting
-the existing logs. This cannot be done while the server is running,
-because Apache will continue writing to the old log file as long as it
-holds the file open. Instead, the server must be <a
-href="stopping.html">restarted</a> after the log files are moved or
-deleted so that it will open new log files.</p>
-
-<p>By using a <em>graceful</em> restart, the server can be instructed
-to open new log files without losing any existing or pending
-connections from clients. However, in order to accomplish this, the
-server must continue to write to the old log files while it finishes
-serving old requests. It is therefore necessary to wait for some time
-after the restart before doing any processing on the log files. A
-typical scenario that simply rotates the logs and compresses the old
-logs to save space is:</p>
-
-<blockquote><code>
-mv access_log access_log.old<br>
-mv error_log error_log.old<br>
-apachectl graceful<br>
-sleep 600<br>
-gzip access_log.old error_log.old
-</code></blockquote>
-
-<p>Another way to perform log rotation is using <a href="#piped">piped
-logs</a> as discussed in the next section.</p>
-
-<hr>
-
-<h2><a name="piped">Piped Logs</a></h2>
-
-<p>Apache httpd is capable of writing error and access log files
-through a pipe to another process, rather than directly to a file.
-This capability dramatically increases the flexibility of logging,
-without adding code to the main server. In order to write logs to a
-pipe, simply replace the filename with the pipe character
-"<code>|</code>", followed by the name of the executable which should
-accept log entries on its standard input. Apache will start the
-piped-log process when the server starts, and will restart it if it
-crashes while the server is running. (This last feature is why we can
-refer to this technique as "reliable piped logging".)</p>
-
-<p>Piped log processes are spawned by the parent Apache httpd process,
-and inherit the userid of that process. This means that piped log
-programs usually run as root. It is therefore very important to keep
-the programs simple and secure.</p>
-
-<p>Some simple examples using piped logs:</p>
-
-<blockquote><code>
-# compressed logs<br>
-CustomLog "|/usr/bin/gzip -c >> /var/log/access_log.gz" common<br>
-# almost-real-time name resolution<br>
-CustomLog "|/usr/local/apache/bin/logresolve >> /var/log/access_log" common
-</code></blockquote>
-
-<p>Notice that quotes are used to enclose the entire command
-that will be called for the pipe. Although these examples are
-for the access log, the same technique can be used for the
-error log.</p>
-
-<p>One important use of piped logs is to allow log rotation without
-having to restart the server. The Apache HTTP Server includes a
-simple program called <a
-href="programs/rotatelogs.html">rotatelogs</a> for this purpose. For
-example, to rotate the logs every 24 hours, you can use:</p>
-
-<blockquote><code>
-CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
-</code></blockquote>
-
-<p>A similar, but much more flexible log rotation program
-called <a href="http://www.ford-mason.co.uk/resources/cronolog/">cronolog</a>
-is available at an external site.</p>
-
-<p>As with conditional logging, piped logs are a very powerful tool,
-but they should not be used where a simpler solution like
-off-line post-processing is available.</p>
-
-<hr>
-
-<h2><a name="virtualhosts">Virtual Hosts</a></h2>
-
-<p>When running a server with many <a href="vhosts/">virtual
-hosts</a>, there are several options for dealing with log files.
-First, it is possible to use logs exactly as in a single-host server.
-Simply by placing the logging directives outside the
-<code><VirtualHost></code> sections in the main server context,
-it is possible to log all requests in the same access log and error
-log. This technique does not allow for easy collection of statistics
-on individual virtual hosts.</p>
-
-<p>If <code>CustomLog</code> or <code>ErrorLog</code> directives are
-placed inside a <code><VirtualHost></code> section, all requests
-or errors for that virtual host will be logged only to the specified
-file. Any virtual host which does not have logging directives will
-still have its requests sent to the main server logs. This technique
-is very useful for a small number of virtual hosts, but if the number
-of hosts is very large, it can be complicated to manage. In addition,
-it can often create problems with <a
-href="vhosts/fd-limits.html">insufficient file descriptors</a>.</p>
-
-<p>For the access log, there is a very good compromise. By adding
-information on the virtual host to the log format string,
-it is possible to log all hosts to the same log, and later
-split the log into individual files. For example, consider the
-following directives.</p>
-
-<blockquote><code>
-LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost<br>
-CustomLog logs/access_log comonvhost
-</code></blockquote>
-
-<p>The <code>%v</code> is used to log the name of the virtual host
-that is serving the request. Then a program like <a
-href="programs/other.html">split-logfile</a> can be used to
-post-process the access log in order to split it into one file per
-virtual host.</p>
-
-<p>Unfortunately, no similar technique is available for the error log,
-so you must choose between mixing all virtual hosts in the same error
-log and using one error log per virtual host.</p>
-
-<hr>
-
-<h2><a name="other">Other Log Files</a></h2>
-
-<table border=1><tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_cgi.html">mod_cgi</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/core.html#pidfile">PidFile</a><br>
-<a href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a></br>
-<a href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a></br>
-<a href="mod/mod_cgi.html#scriptlog">ScriptLog</a><br>
-<a href="mod/mod_cgi.html#scriptloglength">ScriptLogLength</a><br>
-<a href="mod/mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</a>
-
-</td></tr></table>
-
-<h3><a name="pidfile">PID File</a></h3>
-
-<p>On startup, Apache httpd saves the process id of the parent httpd
-process to the file <code>logs/httpd.pid</code>. This filename can be
-changed with the <A HREF="mod/core.html#pidfile">PidFile</A>
-directive. The process-id is for use by the administrator in
-restarting and terminating the daemon by sending signals
-to the parent process; on Windows, use the -k command line
-option instead. For more information see the <A
-HREF="stopping.html">Stopping and Restarting</A> page.
-
-<h3><a name="scriptlog">Script Log</a></h3>
-
-<p>In order to aid in debugging, the
-<a href="mod/mod_cgi.html#scriptlog">ScriptLog</a>
-directive allows you to record the input to and output from
-CGI scripts. This should only be used in testing - not for
-live servers. More information is available in the
-<a href="mod/mod_cgi.html">mod_cgi documentation</a>.
-
-<h3><a name="rewritelog">Rewrite Log</a></h3>
-
-<p>When using the powerful and complex features of <a
-href="mod/mod_rewrite.html">mod_rewrite</a>, it is almost always
-necessary to use the <a
-href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a> to help in
-debugging. This log file produces a detailed analysis of how the
-rewriting engine transforms requests. The level of detail is
-controlled by the <a
-href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a>
-directive.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Log Files - Apache HTTP Server</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Log Files</h1>
+
+ <p>In order to effectively manage a web server, it is necessary
+ to get feedback about the activity and performance of the
+ server as well as any problems that may be occuring. The Apache
+ HTTP Server provides very comprehensive and flexible logging
+ capabilities. This document describes how to configure its
+ logging capabilities, and how to understand what the logs
+ contain.</p>
+
+ <ul>
+ <li><a href="#security">Security Warning</a></li>
+
+ <li><a href="#errorlog">Error Log</a></li>
+
+ <li>
+ <a href="#accesslog">Access Log</a>
+
+ <ul>
+ <li><a href="#common">Common Log Format</a></li>
+
+ <li><a href="#combined">Combined Log Format</a></li>
+
+ <li><a href="#multiple">Multiple Access Logs</a></li>
+
+ <li><a href="#conditional">Conditional Logging</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#rotation">Log Rotation</a></li>
+
+ <li><a href="#piped">Piped Logs</a></li>
+
+ <li><a href="#virtualhosts">VirtualHosts</a></li>
+
+ <li>
+ <a href="#other">Other Log Files</a>
+
+ <ul>
+ <li><a href="#pidfile">PID File</a></li>
+
+ <li><a href="#scriptlog">Script Log</a></li>
+
+ <li><a href="#rewritelog">Rewrite Log</a></li>
+ </ul>
+ </li>
+ </ul>
+ <hr />
+
+ <h2><a id="security" name="security">Security Warning</a></h2>
+
+ <p>Anyone who can write to the directory where Apache is
+ writing a log file can almost certainly gain access to the uid
+ that the server is started as, which is normally root. Do
+ <em>NOT</em> give people write access to the directory the logs
+ are stored in without being aware of the consequences; see the
+ <a href="misc/security_tips.html">security tips</a> document
+ for details.</p>
+
+ <p>In addition, log files may contain information supplied
+ directly by the client, without escaping. Therefore, it is
+ possible for malicious clients to insert control-characters in
+ the log files, so care must be taken in dealing with raw
+ logs.</p>
+ <hr />
+
+ <h2><a id="errorlog" name="errorlog">Error Log</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/core.html#errorlog">ErrorLog</a><br />
+ <a href="mod/core.html#loglevel">LogLevel</a> </td>
+ </tr>
+ </table>
+
+ <p>The server error log, whose name and location is set by the
+ <a href="mod/core.html#errorlog">ErrorLog</a> directive, is the
+ most important log file. This is the place where Apache httpd
+ will send diagnostic information and record any errors that it
+ encounters in processing requests. It is the first place to
+ look when a problem occurs with starting the server or with the
+ operation of the server, since it will often contain details of
+ what went wrong and how to fix it.</p>
+
+ <p>The error log is usually written to a file (typically
+ <code>error_log</code> on unix systems and
+ <code>error.log</code> on Windows and OS/2). On unix systems it
+ is also possible to have the server send errors to
+ <code>syslog</code> or <a href="#pipe">pipe them to a
+ program</a>.</p>
+
+ <p>The format of the error log is relatively free-form and
+ descriptive. But there is certain information that is contained
+ in most error log entries. For example, here is a typical
+ message.</p>
+
+ <blockquote>
+ <code>[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
+ client denied by server configuration:
+ /export/home/live/ap/htdocs/test</code>
+ </blockquote>
+
+ <p>The first item in the log entry is the date and time of the
+ message. The second entry lists the severity of the error being
+ reported. The <a href="mod/core.html#loglevel">LogLevel</a>
+ directive is used to control the types of errors that are sent
+ to the error log by restricting the severity level. The third
+ entry gives the IP address of the client that generated the
+ error. Beyond that is the message itself, which in this case
+ indicates that the server has been configured to deny the
+ client access. The server reports the file-system path (as
+ opposed to the web path) of the requested document.</p>
+
+ <p>A very wide variety of different messages can appear in the
+ error log. Most look similar to the example above. The error
+ log will also contain debugging output from CGI scripts. Any
+ information written to <code>stderr</code> by a CGI script will
+ be copied directly to the error log.</p>
+
+ <p>It is not possible to customize the error log by adding or
+ removing information. However, error log entries dealing with
+ particular requests have corresponding entries in the <a
+ href="accesslog">access log</a>. For example, the above example
+ entry corresponds to an access log entry with status code 403.
+ Since it is possible to customize the access log, you can
+ obtain more information about error conditions using that log
+ file.</p>
+
+ <p>During testing, it is often useful to continuously monitor
+ the error log for any problems. On unix systems, you can
+ accomplish this using:</p>
+
+ <blockquote>
+ <code>tail -f error_log</code>
+ </blockquote>
+ <hr />
+
+ <h2><a id="accesslog" name="accesslog">Access Log</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_log_config.html">mod_log_config</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a><br />
+ <a
+ href="mod/mod_log_config.html#logformat">LogFormat</a><br />
+ <a href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>
+ </td>
+ </tr>
+ </table>
+
+ <p>The server access log records all requests processed by the
+ server. The location and content of the access log are
+ controlled by the <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a>
+ directive. The <a
+ href="mod/mod_log_config.html#logformat">LogFormat</a>
+ directive can be used to simplify the selection of the contents
+ of the logs. This section describes how to configure the server
+ to record information in the access log.</p>
+
+ <p>Of course, storing the information in the access log is only
+ the start of log management. The next step is to analyze this
+ information to produce useful statistics. Log analysis in
+ general is beyond the scope of this document, and not really
+ part of the job of the web server itself. For more information
+ about this topic, and for applications which perform log
+ analysis, check the <a
+ href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/">
+ Open Directory</a> or <a
+ href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">
+ Yahoo</a>.</p>
+
+ <p>Various versions of Apache httpd have used other modules and
+ directives to control access logging, including
+ mod_log_referer, mod_log_agent, and the
+ <code>TransferLog</code> directive. The <code>CustomLog</code>
+ directive now subsumes the functionality of all the older
+ directives.</p>
+
+ <p>The format of the access log is highly configurable. The
+ format is specified using a <a
+ href="mod/mod_log_config.html#format">format string</a> that
+ looks much like a C-style printf(1) format string. Some
+ examples are presented in the next sections. For a complete
+ list of the possible contents of the format string, see the <a
+ href="mod/mod_log_config.html">mod_log_config
+ documentation</a>.</p>
+
+ <h3><a id="common" name="common">Common Log Format</a></h3>
+
+ <p>A typical configuration for the access log might look as
+ follows.</p>
+
+ <blockquote>
+ <code>LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common</code>
+ </blockquote>
+
+ <p>This defines the <em>nickname</em> <code>common</code> and
+ associates it with a particular log format string. The format
+ string consists of percent directives, each of which tell the
+ server to log a particular piece of information. Literal
+ characters may also be placed in the format string and will be
+ copied directly into the log output. The quote character
+ (<code>"</code>) must be escaped by placing a back-slash before
+ it to prevent it from being interpreted as the end of the
+ format string. The format string may also contain the special
+ control characters "<code>\n</code>" for new-line and
+ "<code>\t</code>" for tab.</p>
+
+ <p>The <code>CustomLog</code> directive sets up a new log file
+ using the defined <em>nickname</em>. The filename for the
+ access log is relative to the <a
+ href="mod/core.html#serverroot">ServerRoot</a> unless it begins
+ with a slash.</p>
+
+ <p>The above configuration will write log entries in a format
+ known as the Common Log Format (CLF). This standard format can
+ be produced by many different web servers and read by many log
+ analysis programs. The log file entries produced in CLF will
+ look something like this:</p>
+
+ <blockquote>
+ <code>127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326</code>
+ </blockquote>
+
+ <p>Each part of this log entry is described below.</p>
+
+ <dl>
+ <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
+
+ <dd>This is the IP address of the client (remote host) which
+ made the request to the server. If <a
+ href="mod/core.html#hostnamelookups">HostNameLookups</a> is
+ set to <code>On</code>, then the server will try to determine
+ the hostname and log it in place of the IP address. However,
+ this configuration is not recommended since it can
+ significantly slow the server. Instead, it is best to use a
+ log post-processor such as <a
+ href="programs/logresolve.html">logresolve</a> to determine
+ the hostnames. The IP address reported here is not
+ necessarily the address of the machine at which the user is
+ sitting. If a proxy server exists between the user and the
+ server, this address will be the address of the proxy, rather
+ than the originating machine.</dd>
+
+ <dt><code>-</code> (<code>%l</code>)</dt>
+
+ <dd>The "hyphen" in the output indicates that the requested
+ piece of information is not available. In this case, the
+ information that is not available is the RFC 1413 identity of
+ the client determined by <code>identd</code> on the clients
+ machine. This information is highly unreliable and should
+ almost never be used except on tightly controlled internal
+ networks. Apache httpd will not even attempt to determine
+ this information unless <a
+ href="mod/core.html#identitycheck">IdentityCheck</a> is set
+ to <code>On</code>.</dd>
+
+ <dt><code>frank</code> (<code>%u</code>)</dt>
+
+ <dd>This is the userid of the person requesting the document
+ as determined by HTTP authentication. The same value is
+ typically provided to CGI scripts in the
+ <code>REMOTE_USER</code> environment variable. If the status
+ code for the request (see below) is 401, then this value
+ should not be trusted because the user is not yet
+ authenticated. If the document is not password protected,
+ this entry will be "<code>-</code>" just like the previous
+ one.</dd>
+
+ <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
+ (<code>%t</code>)</dt>
+
+ <dd>
+ The time that the server finished processing the request.
+ The format is:
+
+ <blockquote>
+ <code>[day/month/year:hour:minute:second zone]<br />
+ day = 2*digit<br />
+ month = 3*letter<br />
+ year = 4*digit<br />
+ hour = 2*digit<br />
+ minute = 2*digit<br />
+ second = 2*digit<br />
+ zone = (`+' | `-') 4*digit</code>
+ </blockquote>
+ It is possible to have the time displayed in another format
+ by specifying <code>%{format}t</code> in the log format
+ string, where <code>format</code> is as in
+ <code>strftime(3)</code> from the C standard library.
+ </dd>
+
+ <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
+ (<code>\"%r\"</code>)</dt>
+
+ <dd>The request line from the client is given in double
+ quotes. The request line contains a great deal of useful
+ information. First, the method used by the client is
+ <code>GET</code>. Second, the client requested the resource
+ <code>/apache_pb.gif</code>, and third, the client used the
+ protocol <code>HTTP/1.0</code>. It is also possible to log
+ one or more parts of the request line independently. For
+ example, the format string "<code>%m %U%q %H</code>" will log
+ the method, path, query-string, and protocol, resulting in
+ exactly the same output as "<code>%r</code>".</dd>
+
+ <dt><code>200</code> (<code>%>s</code>)</dt>
+
+ <dd>This is the status code that the server sends back to the
+ client. This information is very valuable, because it reveals
+ whether the request resulted in a successful response (codes
+ beginning in 2), a redirection (codes beginning in 3), an
+ error caused by the client (codes beginning in 4), or an
+ error in the server (codes beginning in 5). The full list of
+ possible status codes can be found in the <a
+ href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">HTTP
+ specification</a> (RFC2616 section 10).</dd>
+
+ <dt><code>2326</code> (<code>%b</code>)</dt>
+
+ <dd>The last entry indicates the size of the object returned
+ to the client, not including the response headers. If no
+ content was returned to the client, this value will be
+ "<code>-</code>". To log "<code>0</code>" for no content, use
+ <code>%B</code> instead.</dd>
+ </dl>
+
+ <h4><a id="combined" name="combined">Combined Log
+ Format</a></h4>
+
+ <p>Another commonly used format string is called the Combined
+ Log Format. It can be used as follows.</p>
+
+ <blockquote>
+ <code>LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\"" combined<br />
+ CustomLog log/acces_log combined</code>
+ </blockquote>
+
+ <p>This format is exactly the same as the Common Log Format,
+ with the addition of two more fields. Each of the additional
+ fields uses the percent-directive
+ <code>%{<em>header</em>}i</code>, where <em>header</em> can be
+ any HTTP request header. The access log under this format will
+ look like:</p>
+
+ <blockquote>
+ <code>127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ "http://www.example.com/start.html" "Mozilla/4.08 [en]
+ (Win98; I ;Nav)"</code>
+ </blockquote>
+
+ <p>The additional fields are:</p>
+
+ <dl>
+ <dt><code>"http://www.example.com/start.html"</code>
+ (<code>\"%{Referer}i\"</code>)</dt>
+
+ <dd>The "Referer" (sic) HTTP request header. This gives the
+ site that the client reports having been referred from. (This
+ should be the page that links to or includes
+ <code>/apache_pb.gif</code>).</dd>
+
+ <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
+ (<code>\"%{User-agent}i\"</code>)</dt>
+
+ <dd>The User-Agent HTTP request header. This is the
+ identifying information that the client browser reports about
+ itself.</dd>
+ </dl>
+
+ <h3><a id="multiple" name="multiple">Multiple Access
+ Logs</a></h3>
+
+ <p>Multiple access logs can be created simply by specifying
+ multiple <code>CustomLog</code> directives in the configuration
+ file. For example, the following directives will create three
+ access logs. The first contains the basic CLF information,
+ while the second and third contain referer and browser
+ information. The last two <code>CustomLog</code> lines show how
+ to mimic the effects of the <code>ReferLog</code> and
+ <code>AgentLog</code> directives.</p>
+
+ <blockquote>
+ <code>LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common<br />
+ CustomLog logs/referer_log "%{Referer}i -> %U"<br />
+ CustomLog logs/agent_log "%{User-agent}i"</code>
+ </blockquote>
+
+ <p>This example also shows that it is not necessary to define a
+ nickname with the <code>LogFormat</code> directive. Instead,
+ the log format can be specified directly in the
+ <code>CustomLog</code> directive.</p>
+
+ <h3><a id="conditional" name="conditional">Conditional
+ Logging</a></h3>
+
+ <p>There are times when it is convenient to exclude certain
+ entries from the access logs based on characteristics of the
+ client request. This is easily accomplished with the help of <a
+ href="env.html">environment variables</a>. First, an
+ environment variable must be set to indicate that the request
+ meets certain conditions. This is usually accomplished with <a
+ href="mod/mod_setenvif.html#setenvif">SetEnvIf</a>. Then the
+ <code>env=</code> clause of the <code>CustomLog</code>
+ directive is used to include or exclude requests where the
+ environment variable is set. Some examples:</p>
+
+ <blockquote>
+ <code># Mark requests from the loop-back interface<br />
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
+ # Mark requests for the robots.txt file<br />
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
+ # Log what remains<br />
+ CustomLog logs/access_log common env=!dontlog</code>
+ </blockquote>
+
+ <p>As another example, consider logging requests from
+ english-speakers to one log file, and non-english speakers to a
+ different log file.</p>
+
+ <blockquote>
+ <code>SetEnvIf Accept-Language "en" english<br />
+ CustomLog logs/english_log common env=english<br />
+ CustomLog logs/non_english_log common env=!english</code>
+ </blockquote>
+
+ <p>Although we have just shown that conditional logging is very
+ powerful and flexibly, it is not the only way to control the
+ contents of the logs. Log files are more useful when they
+ contain a complete record of server activity. It is often
+ easier to simply post-process the log files to remove requests
+ that you do not want to consider.</p>
+ <hr />
+
+ <h2><a id="rotation" name="rotation">Log Rotation</a></h2>
+
+ <p>On even a moderately busy server, the quantity of
+ information stored in the log files is very large. The access
+ log file typically grows 1 MB or more per 10,000 requests. It
+ will consequently be necessary to periodically rotate the log
+ files by moving or deleting the existing logs. This cannot be
+ done while the server is running, because Apache will continue
+ writing to the old log file as long as it holds the file open.
+ Instead, the server must be <a
+ href="stopping.html">restarted</a> after the log files are
+ moved or deleted so that it will open new log files.</p>
+
+ <p>By using a <em>graceful</em> restart, the server can be
+ instructed to open new log files without losing any existing or
+ pending connections from clients. However, in order to
+ accomplish this, the server must continue to write to the old
+ log files while it finishes serving old requests. It is
+ therefore necessary to wait for some time after the restart
+ before doing any processing on the log files. A typical
+ scenario that simply rotates the logs and compresses the old
+ logs to save space is:</p>
+
+ <blockquote>
+ <code>mv access_log access_log.old<br />
+ mv error_log error_log.old<br />
+ apachectl graceful<br />
+ sleep 600<br />
+ gzip access_log.old error_log.old</code>
+ </blockquote>
+
+ <p>Another way to perform log rotation is using <a
+ href="#piped">piped logs</a> as discussed in the next
+ section.</p>
+ <hr />
+
+ <h2><a id="piped" name="piped">Piped Logs</a></h2>
+
+ <p>Apache httpd is capable of writing error and access log
+ files through a pipe to another process, rather than directly
+ to a file. This capability dramatically increases the
+ flexibility of logging, without adding code to the main server.
+ In order to write logs to a pipe, simply replace the filename
+ with the pipe character "<code>|</code>", followed by the name
+ of the executable which should accept log entries on its
+ standard input. Apache will start the piped-log process when
+ the server starts, and will restart it if it crashes while the
+ server is running. (This last feature is why we can refer to
+ this technique as "reliable piped logging".)</p>
+
+ <p>Piped log processes are spawned by the parent Apache httpd
+ process, and inherit the userid of that process. This means
+ that piped log programs usually run as root. It is therefore
+ very important to keep the programs simple and secure.</p>
+
+ <p>Some simple examples using piped logs:</p>
+
+ <blockquote>
+ <code># compressed logs<br />
+ CustomLog "|/usr/bin/gzip -c >>
+ /var/log/access_log.gz" common<br />
+ # almost-real-time name resolution<br />
+ CustomLog "|/usr/local/apache/bin/logresolve >>
+ /var/log/access_log" common</code>
+ </blockquote>
+
+ <p>Notice that quotes are used to enclose the entire command
+ that will be called for the pipe. Although these examples are
+ for the access log, the same technique can be used for the
+ error log.</p>
+
+ <p>One important use of piped logs is to allow log rotation
+ without having to restart the server. The Apache HTTP Server
+ includes a simple program called <a
+ href="programs/rotatelogs.html">rotatelogs</a> for this
+ purpose. For example, to rotate the logs every 24 hours, you
+ can use:</p>
+
+ <blockquote>
+ <code>CustomLog "|/usr/local/apache/bin/rotatelogs
+ /var/log/access_log 86400" common</code>
+ </blockquote>
+
+ <p>A similar, but much more flexible log rotation program
+ called <a
+ href="http://www.ford-mason.co.uk/resources/cronolog/">cronolog</a>
+ is available at an external site.</p>
+
+ <p>As with conditional logging, piped logs are a very powerful
+ tool, but they should not be used where a simpler solution like
+ off-line post-processing is available.</p>
+ <hr />
+
+ <h2><a id="virtualhosts" name="virtualhosts">Virtual
+ Hosts</a></h2>
+
+ <p>When running a server with many <a href="vhosts/">virtual
+ hosts</a>, there are several options for dealing with log
+ files. First, it is possible to use logs exactly as in a
+ single-host server. Simply by placing the logging directives
+ outside the <code><VirtualHost></code> sections in the
+ main server context, it is possible to log all requests in the
+ same access log and error log. This technique does not allow
+ for easy collection of statistics on individual virtual
+ hosts.</p>
+
+ <p>If <code>CustomLog</code> or <code>ErrorLog</code>
+ directives are placed inside a <code><VirtualHost></code>
+ section, all requests or errors for that virtual host will be
+ logged only to the specified file. Any virtual host which does
+ not have logging directives will still have its requests sent
+ to the main server logs. This technique is very useful for a
+ small number of virtual hosts, but if the number of hosts is
+ very large, it can be complicated to manage. In addition, it
+ can often create problems with <a
+ href="vhosts/fd-limits.html">insufficient file
+ descriptors</a>.</p>
+
+ <p>For the access log, there is a very good compromise. By
+ adding information on the virtual host to the log format
+ string, it is possible to log all hosts to the same log, and
+ later split the log into individual files. For example,
+ consider the following directives.</p>
+
+ <blockquote>
+ <code>LogFormat "%v %l %u %t \"%r\" %>s %b"
+ comonvhost<br />
+ CustomLog logs/access_log comonvhost</code>
+ </blockquote>
+
+ <p>The <code>%v</code> is used to log the name of the virtual
+ host that is serving the request. Then a program like <a
+ href="programs/other.html">split-logfile</a> can be used to
+ post-process the access log in order to split it into one file
+ per virtual host.</p>
+
+ <p>Unfortunately, no similar technique is available for the
+ error log, so you must choose between mixing all virtual hosts
+ in the same error log and using one error log per virtual
+ host.</p>
+ <hr />
+
+ <h2><a id="other" name="other">Other Log Files</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_cgi.html">mod_cgi</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a> </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/core.html#pidfile">PidFile</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a><br />
+ <a href="mod/mod_cgi.html#scriptlog">ScriptLog</a><br />
+ <a
+ href="mod/mod_cgi.html#scriptloglength">ScriptLogLength</a><br />
+ <a
+ href="mod/mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</a>
+ </td>
+ </tr>
+ </table>
+
+ <h3><a id="pidfile" name="pidfile">PID File</a></h3>
+
+ <p>On startup, Apache httpd saves the process id of the parent
+ httpd process to the file <code>logs/httpd.pid</code>. This
+ filename can be changed with the <a
+ href="mod/core.html#pidfile">PidFile</a> directive. The
+ process-id is for use by the administrator in restarting and
+ terminating the daemon by sending signals to the parent
+ process; on Windows, use the -k command line option instead.
+ For more information see the <a href="stopping.html">Stopping
+ and Restarting</a> page.</p>
+
+ <h3><a id="scriptlog" name="scriptlog">Script Log</a></h3>
+
+ <p>In order to aid in debugging, the <a
+ href="mod/mod_cgi.html#scriptlog">ScriptLog</a> directive
+ allows you to record the input to and output from CGI scripts.
+ This should only be used in testing - not for live servers.
+ More information is available in the <a
+ href="mod/mod_cgi.html">mod_cgi documentation</a>.</p>
+
+ <h3><a id="rewritelog" name="rewritelog">Rewrite Log</a></h3>
+
+ <p>When using the powerful and complex features of <a
+ href="mod/mod_rewrite.html">mod_rewrite</a>, it is almost
+ always necessary to use the <a
+ href="mod/mod_rewrite.html#RewriteLog">RewriteLog</a> to help
+ in debugging. This log file produces a detailed analysis of how
+ the rewriting engine transforms requests. The level of detail
+ is controlled by the <a
+ href="mod/mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</a>
+ directive.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Multi-Processing Modules (MPMs)</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-
-<!--#include virtual="header.html" -->
-
-<h1 align="center">Apache Multi-Processing Modules</h1>
-
-<p>The Apache HTTP Server is designed to be a powerful and flexible
-web server that can work on a very wide variety of platforms in a
-range of different environments. Different platforms and different
-environments often require different features, or may have different
-ways of implementing the same feature most efficiently. Apache has
-always accommodated a wide variety of environments through its modular
-design. This design allows the webmaster to choose which features
-will be included in the server by selecting which modules to load
-either at compile-time or at run-time.</p>
-
-<p>Apache 2.0 extends this modular design to the most basic functions
-of a web server. The server ships with a selection of
-Multi-Processing Modules (MPMs) which are responsible for binding to
-network ports on the machine, accepting requests, and dispatching
-children to handle the requests.</p>
-
-<p>Extending the modular design to this level of the server
-allows two important benefits:
-<ul>
-<li>Apache can more cleanly and efficiently support a wide variety of
-operating systems. In particular, the Windows version of Apache is
-now much more efficient, since <a
-href="mod/mpm_winnt.html">mpm_winnt</a> can use native networking
-features in place of the POSIX layer used in Apache 1.3. This benefit
-also extends to other operating systems that implement specialized
-MPMs.</li>
-<li>The server can be better customized for the needs of the
-particular site. For example, sites that need a great deal of
-scalability can choose to use a threaded MPM like <a
-href="mod/threaded.html">threaded</a>, while sites requiring
-stability or compatibility with older software can use a <a
-href="mod/prefork.html">preforking MPM</a>. In addition, special
-features like serving different hosts under different userids
-(<a href="mod/perchild.html">perchild</a>) can be provided.</li>
-</ul>
-
-<p>At the user level, MPMs appear much like other Apache modules.
-The main difference is that one and only one MPM must be loaded
-into the server at any time. The list of available MPMs
-appears on the <a href="mod/">module index page</a>.</p>
-
-<h2 align="center">Choosing an MPM</h2>
-
-<p>MPMs must be chosen during configuration, and compiled into the server.
-Compilers are capable of optimizing a lot of functions if threads are used,
-but only if they know that threads are being used. Because some MPMs use
-threads on Unix and others don't, Apache will always perform better if the
-MPM is chosen at configuration time and built into Apache.</p>
-
-<p>To actually choose the desired MPM, use the argument --with-mpm=
-<EM>NAME</EM> with the ./configure script. <EM>NAME</EM> is the name of
-the desired MPM.</p>
-
-<p>Once the server has been compiled, it is possible to determine which
-MPM was chosen by using <code>./httpd -l</code>. This command will list
-every module that is compiled into the server, including the MPM.</p>
-
-<h2 align="center">MPM Defaults</h2>
-
-<ul>
- <li> BeOS: mpmt_beos</li>
- <li> OS/2: mpmt_os2</li>
- <li> Unix: prefork </li>
- <li> Windows: winnt</li>
-</ul>
-
-<!--#include virtual="footer.html" -->
-
-</body>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache Multi-Processing Modules (MPMs)</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Apache Multi-Processing Modules</h1>
+
+ <p>The Apache HTTP Server is designed to be a powerful and
+ flexible web server that can work on a very wide variety of
+ platforms in a range of different environments. Different
+ platforms and different environments often require different
+ features, or may have different ways of implementing the same
+ feature most efficiently. Apache has always accommodated a wide
+ variety of environments through its modular design. This design
+ allows the webmaster to choose which features will be included
+ in the server by selecting which modules to load either at
+ compile-time or at run-time.</p>
+
+ <p>Apache 2.0 extends this modular design to the most basic
+ functions of a web server. The server ships with a selection of
+ Multi-Processing Modules (MPMs) which are responsible for
+ binding to network ports on the machine, accepting requests,
+ and dispatching children to handle the requests.</p>
+
+ <p>Extending the modular design to this level of the server
+ allows two important benefits:</p>
+
+ <ul>
+ <li>Apache can more cleanly and efficiently support a wide
+ variety of operating systems. In particular, the Windows
+ version of Apache is now much more efficient, since <a
+ href="mod/mpm_winnt.html">mpm_winnt</a> can use native
+ networking features in place of the POSIX layer used in
+ Apache 1.3. This benefit also extends to other operating
+ systems that implement specialized MPMs.</li>
+
+ <li>The server can be better customized for the needs of the
+ particular site. For example, sites that need a great deal of
+ scalability can choose to use a threaded MPM like <a
+ href="mod/threaded.html">threaded</a>, while sites requiring
+ stability or compatibility with older software can use a <a
+ href="mod/prefork.html">preforking MPM</a>. In addition,
+ special features like serving different hosts under different
+ userids (<a href="mod/perchild.html">perchild</a>) can be
+ provided.</li>
+ </ul>
+
+ <p>At the user level, MPMs appear much like other Apache
+ modules. The main difference is that one and only one MPM must
+ be loaded into the server at any time. The list of available
+ MPMs appears on the <a href="mod/">module index page</a>.</p>
+
+ <h2 align="center">Choosing an MPM</h2>
+
+ <p>MPMs must be chosen during configuration, and compiled into
+ the server. Compilers are capable of optimizing a lot of
+ functions if threads are used, but only if they know that
+ threads are being used. Because some MPMs use threads on Unix
+ and others don't, Apache will always perform better if the MPM
+ is chosen at configuration time and built into Apache.</p>
+
+ <p>To actually choose the desired MPM, use the argument
+ --with-mpm= <em>NAME</em> with the ./configure script.
+ <em>NAME</em> is the name of the desired MPM.</p>
+
+ <p>Once the server has been compiled, it is possible to
+ determine which MPM was chosen by using <code>./httpd
+ -l</code>. This command will list every module that is compiled
+ into the server, including the MPM.</p>
+
+ <h2 align="center">MPM Defaults</h2>
+
+ <ul>
+ <li>BeOS: mpmt_beos</li>
+
+ <li>OS/2: mpmt_os2</li>
+
+ <li>Unix: prefork</li>
+
+ <li>Windows: winnt</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Multi-Processing Modules (MPMs)</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-
-<!--#include virtual="header.html" -->
-
-<h1 align="center">Apache Multi-Processing Modules</h1>
-
-<p>The Apache HTTP Server is designed to be a powerful and flexible
-web server that can work on a very wide variety of platforms in a
-range of different environments. Different platforms and different
-environments often require different features, or may have different
-ways of implementing the same feature most efficiently. Apache has
-always accommodated a wide variety of environments through its modular
-design. This design allows the webmaster to choose which features
-will be included in the server by selecting which modules to load
-either at compile-time or at run-time.</p>
-
-<p>Apache 2.0 extends this modular design to the most basic functions
-of a web server. The server ships with a selection of
-Multi-Processing Modules (MPMs) which are responsible for binding to
-network ports on the machine, accepting requests, and dispatching
-children to handle the requests.</p>
-
-<p>Extending the modular design to this level of the server
-allows two important benefits:
-<ul>
-<li>Apache can more cleanly and efficiently support a wide variety of
-operating systems. In particular, the Windows version of Apache is
-now much more efficient, since <a
-href="mod/mpm_winnt.html">mpm_winnt</a> can use native networking
-features in place of the POSIX layer used in Apache 1.3. This benefit
-also extends to other operating systems that implement specialized
-MPMs.</li>
-<li>The server can be better customized for the needs of the
-particular site. For example, sites that need a great deal of
-scalability can choose to use a threaded MPM like <a
-href="mod/threaded.html">threaded</a>, while sites requiring
-stability or compatibility with older software can use a <a
-href="mod/prefork.html">preforking MPM</a>. In addition, special
-features like serving different hosts under different userids
-(<a href="mod/perchild.html">perchild</a>) can be provided.</li>
-</ul>
-
-<p>At the user level, MPMs appear much like other Apache modules.
-The main difference is that one and only one MPM must be loaded
-into the server at any time. The list of available MPMs
-appears on the <a href="mod/">module index page</a>.</p>
-
-<h2 align="center">Choosing an MPM</h2>
-
-<p>MPMs must be chosen during configuration, and compiled into the server.
-Compilers are capable of optimizing a lot of functions if threads are used,
-but only if they know that threads are being used. Because some MPMs use
-threads on Unix and others don't, Apache will always perform better if the
-MPM is chosen at configuration time and built into Apache.</p>
-
-<p>To actually choose the desired MPM, use the argument --with-mpm=
-<EM>NAME</EM> with the ./configure script. <EM>NAME</EM> is the name of
-the desired MPM.</p>
-
-<p>Once the server has been compiled, it is possible to determine which
-MPM was chosen by using <code>./httpd -l</code>. This command will list
-every module that is compiled into the server, including the MPM.</p>
-
-<h2 align="center">MPM Defaults</h2>
-
-<ul>
- <li> BeOS: mpmt_beos</li>
- <li> OS/2: mpmt_os2</li>
- <li> Unix: prefork </li>
- <li> Windows: winnt</li>
-</ul>
-
-<!--#include virtual="footer.html" -->
-
-</body>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache Multi-Processing Modules (MPMs)</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Apache Multi-Processing Modules</h1>
+
+ <p>The Apache HTTP Server is designed to be a powerful and
+ flexible web server that can work on a very wide variety of
+ platforms in a range of different environments. Different
+ platforms and different environments often require different
+ features, or may have different ways of implementing the same
+ feature most efficiently. Apache has always accommodated a wide
+ variety of environments through its modular design. This design
+ allows the webmaster to choose which features will be included
+ in the server by selecting which modules to load either at
+ compile-time or at run-time.</p>
+
+ <p>Apache 2.0 extends this modular design to the most basic
+ functions of a web server. The server ships with a selection of
+ Multi-Processing Modules (MPMs) which are responsible for
+ binding to network ports on the machine, accepting requests,
+ and dispatching children to handle the requests.</p>
+
+ <p>Extending the modular design to this level of the server
+ allows two important benefits:</p>
+
+ <ul>
+ <li>Apache can more cleanly and efficiently support a wide
+ variety of operating systems. In particular, the Windows
+ version of Apache is now much more efficient, since <a
+ href="mod/mpm_winnt.html">mpm_winnt</a> can use native
+ networking features in place of the POSIX layer used in
+ Apache 1.3. This benefit also extends to other operating
+ systems that implement specialized MPMs.</li>
+
+ <li>The server can be better customized for the needs of the
+ particular site. For example, sites that need a great deal of
+ scalability can choose to use a threaded MPM like <a
+ href="mod/threaded.html">threaded</a>, while sites requiring
+ stability or compatibility with older software can use a <a
+ href="mod/prefork.html">preforking MPM</a>. In addition,
+ special features like serving different hosts under different
+ userids (<a href="mod/perchild.html">perchild</a>) can be
+ provided.</li>
+ </ul>
+
+ <p>At the user level, MPMs appear much like other Apache
+ modules. The main difference is that one and only one MPM must
+ be loaded into the server at any time. The list of available
+ MPMs appears on the <a href="mod/">module index page</a>.</p>
+
+ <h2 align="center">Choosing an MPM</h2>
+
+ <p>MPMs must be chosen during configuration, and compiled into
+ the server. Compilers are capable of optimizing a lot of
+ functions if threads are used, but only if they know that
+ threads are being used. Because some MPMs use threads on Unix
+ and others don't, Apache will always perform better if the MPM
+ is chosen at configuration time and built into Apache.</p>
+
+ <p>To actually choose the desired MPM, use the argument
+ --with-mpm= <em>NAME</em> with the ./configure script.
+ <em>NAME</em> is the name of the desired MPM.</p>
+
+ <p>Once the server has been compiled, it is possible to
+ determine which MPM was chosen by using <code>./httpd
+ -l</code>. This command will list every module that is compiled
+ into the server, including the MPM.</p>
+
+ <h2 align="center">MPM Defaults</h2>
+
+ <ul>
+ <li>BeOS: mpmt_beos</li>
+
+ <li>OS/2: mpmt_os2</li>
+
+ <li>Unix: prefork</li>
+
+ <li>Windows: winnt</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>New features with Apache 2.0</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF"
- VLINK="#000080" ALINK="#FF0000">
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Overview of New Features in Apache 2.0</H1>
-
-<P>Enhancements: <A HREF="#core">Core</A> | <a href="#module">Module</a>
-
-<P><HR>
-
-<H2><A NAME="core">Core Enhancements:</A></H2>
-
-<DL>
-<DT><STRONG>Unix Threading</STRONG>
-<DD>On Unix systems with POSIX threads support, Apache can now run in a
- hybrid multiprocess, multithreaded mode. This should improve
- scalability.
-
-<DT><STRONG>New Build System</STRONG>
-<DD>The build system has been rewritten from scratch to be based on
- autoconf and libtool. This makes Apache's configuration system more
- similar to that of other packages.
-
-<DT><STRONG>Multiprotocol Support</STRONG>
-<DD>Apache now has some of the infrastructure in place to support serving
- multiple protocols. mod_echo has been written as an example.
-
-<DT><STRONG>Better support for non-Unix platforms</STRONG> <DD>Apache
- 2.0 is faster and more stable on non-Unix platforms such as BeOS,
- OS/2, and Windows. With the introduction of platform-specific <a
- href="mpm.html">multi-processing modules</a> (MPMs) and the Apache
- Portable Runtime (APR), these platforms are now implemented in their
- native API, avoiding the often buggy and poorly performing
- POSIX-emulation layers.
-
-<DT><STRONG>New Apache API</STRONG>
-<DD>The API for modules has changed significantly for 2.0. Many of the
- module-ordering problems from 1.3 should be gone. 2.0 does much of
- this automatically, and module ordering is now done per-hook to
- allow more flexibility. Also, new calls have been added that provide
- additional module capabilities without patching the core Apache server.
-
-<DT><STRONG>IPv6 Support</STRONG></DT>
-<DD>On systems where IPv6 is supported by the underlying Apache
- Portable Runtime library, Apache gets IPv6 listening sockets by
- default. Additionally, the Listen, NameVirtualHost, and
- <VirtualHost> directives support IPv6 numeric address
- strings (e.g., "Listen [fe80::1]:8080").</DD>
-
-<DT><STRONG>Filtering</STRONG></DT>
-<DD>Apache modules may now be written as filters which act on the
- stream of content as it is delivered to or from the server. This
- allows, for example, the output of CGI scripts to be parsed for
- Server Side Include directive by mod_include.</DD>
-
-</DL>
-
-<P><HR>
-
-<H2><A NAME="module">Module Enhancements:</A></H2>
-
-<dl>
-
-<dt><strong>mod_auth_db</strong>
-<dd>Now supports Berkely DB 3.0
-
-<dt><strong>mod_auth_digest</strong>
-<dd>Includes additional support for session caching across processes
-using shared memory.
-
-<dt><strong>mod_charset_lite</strong> <dd>New module in Apache 2.0.
-This experimental module allows for character set translation
-or recoding.
-
-<dt><strong>mod_dav</strong>
-<dd>New module in Apache 2.0. This module implements the
-HTTP Distributed Authoring and Versioning (DAV) specification for
-posting and maintaining web content.
-
-<dt><strong>mod_file_cache</strong>
-<dd>New module in Apache 2.0. This module includes the functionality
-of mod_mmap_static in Apache 1.3, plus adds further caching abilities.
-
-<dt><strong>mod_headers</strong>
-<dd>This module is much more flexible in Apache 2.0. It can now
-modify request headers used by mod_proxy, and it can conditionally set
-response headers.
-
-</dl>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>New features with Apache 2.0</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Overview of New Features in Apache 2.0</h1>
+
+ <p>Enhancements: <a href="#core">Core</a> | <a
+ href="#module">Module</a></p>
+ <hr />
+
+ <h2><a id="core" name="core">Core Enhancements:</a></h2>
+
+ <dl>
+ <dt><strong>Unix Threading</strong></dt>
+
+ <dd>On Unix systems with POSIX threads support, Apache can
+ now run in a hybrid multiprocess, multithreaded mode. This
+ should improve scalability.</dd>
+
+ <dt><strong>New Build System</strong></dt>
+
+ <dd>The build system has been rewritten from scratch to be
+ based on autoconf and libtool. This makes Apache's
+ configuration system more similar to that of other
+ packages.</dd>
+
+ <dt><strong>Multiprotocol Support</strong></dt>
+
+ <dd>Apache now has some of the infrastructure in place to
+ support serving multiple protocols. mod_echo has been written
+ as an example.</dd>
+
+ <dt><strong>Better support for non-Unix
+ platforms</strong></dt>
+
+ <dd>Apache 2.0 is faster and more stable on non-Unix
+ platforms such as BeOS, OS/2, and Windows. With the
+ introduction of platform-specific <a
+ href="mpm.html">multi-processing modules</a> (MPMs) and the
+ Apache Portable Runtime (APR), these platforms are now
+ implemented in their native API, avoiding the often buggy and
+ poorly performing POSIX-emulation layers.</dd>
+
+ <dt><strong>New Apache API</strong></dt>
+
+ <dd>The API for modules has changed significantly for 2.0.
+ Many of the module-ordering problems from 1.3 should be gone.
+ 2.0 does much of this automatically, and module ordering is
+ now done per-hook to allow more flexibility. Also, new calls
+ have been added that provide additional module capabilities
+ without patching the core Apache server.</dd>
+
+ <dt><strong>IPv6 Support</strong></dt>
+
+ <dd>On systems where IPv6 is supported by the underlying
+ Apache Portable Runtime library, Apache gets IPv6 listening
+ sockets by default. Additionally, the Listen,
+ NameVirtualHost, and <VirtualHost> directives support
+ IPv6 numeric address strings (e.g., "Listen
+ [fe80::1]:8080").</dd>
+
+ <dt><strong>Filtering</strong></dt>
+
+ <dd>Apache modules may now be written as filters which act on
+ the stream of content as it is delivered to or from the
+ server. This allows, for example, the output of CGI scripts
+ to be parsed for Server Side Include directive by
+ mod_include.</dd>
+ </dl>
+ <hr />
+
+ <h2><a id="module" name="module">Module Enhancements:</a></h2>
+
+ <dl>
+ <dt><strong>mod_auth_db</strong></dt>
+
+ <dd>Now supports Berkely DB 3.0</dd>
+
+ <dt><strong>mod_auth_digest</strong></dt>
+
+ <dd>Includes additional support for session caching across
+ processes using shared memory.</dd>
+
+ <dt><strong>mod_charset_lite</strong></dt>
+
+ <dd>New module in Apache 2.0. This experimental module allows
+ for character set translation or recoding.</dd>
+
+ <dt><strong>mod_dav</strong></dt>
+
+ <dd>New module in Apache 2.0. This module implements the HTTP
+ Distributed Authoring and Versioning (DAV) specification for
+ posting and maintaining web content.</dd>
+
+ <dt><strong>mod_file_cache</strong></dt>
+
+ <dd>New module in Apache 2.0. This module includes the
+ functionality of mod_mmap_static in Apache 1.3, plus adds
+ further caching abilities.</dd>
+
+ <dt><strong>mod_headers</strong></dt>
+
+ <dd>This module is much more flexible in Apache 2.0. It can
+ now modify request headers used by mod_proxy, and it can
+ conditionally set response headers.</dd>
+ </dl>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<TITLE>Nouvelles fonctionnalités d'Apache 2.0</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited),
-red (active) -->
-<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF"
- VLINK="#000080" ALINK="#FF0000">
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Aperçu des nouvelles fonctionnalités
-d'Apache 2.0</H1>
-
-<P>Améliorations : <A HREF="#core">Noyau</A>
-| <a href="#module">Module</a>
-
-<P><HR>
-
-<H2><A NAME="core">Améliorations du noyau :</A></H2>
-
-<DL>
-<DT><STRONG>Threads sur Unix</STRONG>
-<DD>Sur les systèmes Unix, Apache peut s'exécuter selon
-un modèle hybride multi-processus et multi-threads,
-en employant les threads selon la norme POSIX. Ceci devrait améliorer
-les performances.
-
-<DT><STRONG>Nouveau système de construction</STRONG>
-<DD>Le système de construction a été entièrement
-réécrit et repose sur autoconf et libtool. Cela rend le
-système de configuration plus semblable aux autres paquetages.
-
-<DT><STRONG>Support multiprotocole</STRONG>
-<DD>Apache possède maintenant une infrastructure afin de servir de multiples
-protocoles. mod_echo a été écrit comme exemple de ces
-nouvelles fonctions.
-
-<DT><STRONG>Meilleur support des plates-formes autres qu'Unix</STRONG>
-<DD>Apache 2.0 est plus rapide et plus stable sur les plates-formes non Unix
-telles que BeOS, OS/2, et Windows. Avec l'introduction des
-<a href="mpm.html">modules multi traitements</a> (MPMs) spécifiques aux
-plates-formes et l'exécuteur portable Apache (APR), le code pour ces
-plates-formes est réalisé en employant leurs API natives,
-permettant ainsi d'éviter les couches d'émulation POSIX
-souvent boguées et peu performantes.
-
-<DT><STRONG>Nouvelle API Apache</STRONG>
-<DD>L'API pour les modules de la version 2.0 a changé de manière
-importante. Beaucoup de problèmes d'ordonnancement des modules existants
-dans la version 1.3 devraient disparaître. La version 2.0 gère ceci de
-manière automatique, et l'ordonnancement des modules s'effectue selon
-une fonction d'accrochage afin de permettre une plus grande flexibilité.
-
-</DL>
-
-<P><HR>
-<H2><A NAME="module">Améliorations concernant les modules :</A></H2>
-
-<dl>
-
-<dt><strong>mod_auth_db</strong>
-<dd>Il accepte maintenant les bases Berkeley DB 3.0.
-
-<dt><strong>mod_auth_digest</strong>
-<dd>Il inclut une nouvelle gestion des sessions en utilisant un cache commun
-aux processus grâce à une mémoire partagée.
-
-<dt><strong>mod_charset_lite</strong> <dd>Nouveau module dans Apache 2.0.
-Ce module expérimental permet la traduction des pages de caractères
-ou leur recodage.
-
-<dt><strong>mod_dav</strong>
-<dd>Nouveau module dans Apache 2.0. Ce module met en oeuvre la spécification
-"HTTP Distributed Authoring and Versioning (DAV)" permettant de distribuer et
-maintenir le contenu d'un site web.
-
-<dt><strong>mod_file_cache</strong>
-<dd>Nouveau module dans Apache 2.0. Ce module inclut les fonctionnalités
-du module mod_mmap_static existant dans la version d'Apache 1.3, en ajoutant
-davantage de possibilités de cache.
-
-</dl>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+ <meta http-equiv="Content-Type"
+ content="text/html; charset=iso-8859-1" />
+
+ <title>Nouvelles fonctionnalités d'Apache 2.0</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited),
+ red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Aperçu des nouvelles
+ fonctionnalités d'Apache 2.0</h1>
+
+ <p>Améliorations : <a href="#core">Noyau</a> | <a
+ href="#module">Module</a></p>
+ <hr />
+
+ <h2><a id="core" name="core">Améliorations du noyau
+ :</a></h2>
+
+ <dl>
+ <dt><strong>Threads sur Unix</strong></dt>
+
+ <dd>Sur les systèmes Unix, Apache peut
+ s'exécuter selon un modèle hybride
+ multi-processus et multi-threads, en employant les threads
+ selon la norme POSIX. Ceci devrait améliorer les
+ performances.</dd>
+
+ <dt><strong>Nouveau système de
+ construction</strong></dt>
+
+ <dd>Le système de construction a été
+ entièrement réécrit et repose sur
+ autoconf et libtool. Cela rend le système de
+ configuration plus semblable aux autres paquetages.</dd>
+
+ <dt><strong>Support multiprotocole</strong></dt>
+
+ <dd>Apache possède maintenant une infrastructure afin
+ de servir de multiples protocoles. mod_echo a
+ été écrit comme exemple de ces nouvelles
+ fonctions.</dd>
+
+ <dt><strong>Meilleur support des plates-formes autres
+ qu'Unix</strong></dt>
+
+ <dd>Apache 2.0 est plus rapide et plus stable sur les
+ plates-formes non Unix telles que BeOS, OS/2, et Windows.
+ Avec l'introduction des <a href="mpm.html">modules multi
+ traitements</a> (MPMs) spécifiques aux plates-formes
+ et l'exécuteur portable Apache (APR), le code pour ces
+ plates-formes est réalisé en employant leurs
+ API natives, permettant ainsi d'éviter les couches
+ d'émulation POSIX souvent boguées et peu
+ performantes.</dd>
+
+ <dt><strong>Nouvelle API Apache</strong></dt>
+
+ <dd>L'API pour les modules de la version 2.0 a changé
+ de manière importante. Beaucoup de problèmes
+ d'ordonnancement des modules existants dans la version 1.3
+ devraient disparaître. La version 2.0 gère ceci
+ de manière automatique, et l'ordonnancement des
+ modules s'effectue selon une fonction d'accrochage afin de
+ permettre une plus grande flexibilité.</dd>
+ </dl>
+ <hr />
+
+ <h2><a id="module" name="module">Améliorations
+ concernant les modules :</a></h2>
+
+ <dl>
+ <dt><strong>mod_auth_db</strong></dt>
+
+ <dd>Il accepte maintenant les bases Berkeley DB 3.0.</dd>
+
+ <dt><strong>mod_auth_digest</strong></dt>
+
+ <dd>Il inclut une nouvelle gestion des sessions en utilisant
+ un cache commun aux processus grâce à une
+ mémoire partagée.</dd>
+
+ <dt><strong>mod_charset_lite</strong></dt>
+
+ <dd>Nouveau module dans Apache 2.0. Ce module
+ expérimental permet la traduction des pages de
+ caractères ou leur recodage.</dd>
+
+ <dt><strong>mod_dav</strong></dt>
+
+ <dd>Nouveau module dans Apache 2.0. Ce module met en oeuvre
+ la spécification "HTTP Distributed Authoring and
+ Versioning (DAV)" permettant de distribuer et maintenir le
+ contenu d'un site web.</dd>
+
+ <dt><strong>mod_file_cache</strong></dt>
+
+ <dd>Nouveau module dans Apache 2.0. Ce module inclut les
+ fonctionnalités du module mod_mmap_static existant
+ dans la version d'Apache 1.3, en ajoutant davantage de
+ possibilités de cache.</dd>
+ </dl>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>How Directory, Location and Files sections work</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">How Directory, Location and Files sections work</H1>
-
-<p>The sections <A
-HREF="mod/core.html#directory"><CODE><Directory></CODE></A>, <A
-HREF="mod/core.html#location"><CODE><Location></CODE></A> and <A
-HREF="mod/core.html#files"><CODE><Files></CODE></A> can contain
-directives which only apply to specified directories, URLs or files
-respectively. Also htaccess files can be used inside a directory to
-apply directives to that directory. This document explains how these
-different sections differ and how they relate to each other when
-Apache decides which directives apply for a particular directory or
-request URL.</p>
-
-<H2>Directives allowed in the sections</H2>
-
-<p>Everything that is syntactically allowed in
-<CODE><Directory></CODE> is also allowed in
-<CODE><Location></CODE> (except a sub-<CODE><Files></CODE>
-section). Semantically, however some things, most
-notably <CODE>AllowOverride</CODE> and the two options
-<CODE>FollowSymLinks</CODE> and <CODE>SymLinksIfOwnerMatch</CODE>,
-make no sense in <CODE><Location></CODE>,
-<CODE><LocationMatch></CODE> or <CODE><DirectoryMatch></CODE>.
-The same for <CODE><Files></CODE> -- syntactically everything
-is fine, but semantically some things are different.</p>
-
-<H2>How the sections are merged</H2>
-
-<p>The order of merging is:</p>
-
-<OL>
-
-<LI>
-
- <CODE><Directory></CODE> (except regular expressions) and
- .htaccess done simultaneously (with .htaccess, if allowed, overriding
- <CODE><Directory></CODE>)
-
-</LI>
-
-<LI>
- <CODE><DirectoryMatch></CODE>, and
- <CODE><Directory></CODE> with regular expressions
-
-</LI>
-
- <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done
- simultaneously
- </LI>
-
- <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done
- simultaneously
- </LI>
-
-</OL>
-
-<p>Apart from <CODE><Directory></CODE>, each group is processed in
-the order that they appear in the configuration
-files. <CODE><Directory></CODE> (group 1 above) is processed in
-the order shortest directory component to longest. If multiple
-<CODE><Directory></CODE> sections apply to the same directory
-they they are processed in the configuration file order. The
-configuration files are read in the order httpd.conf, srm.conf and
-access.conf. Configurations included via the <CODE>Include</CODE>
-directive will be treated as if they were inside the including file
-at the location of the <CODE>Include</CODE> directive.</p>
-
-<p>Sections inside <CODE><VirtualHost></CODE> sections are applied
-<EM>after</EM> the corresponding sections outside the virtual host
-definition. This allows virtual hosts to override the main server
-configuration.</p>
-
-<p>Later sections override earlier ones.</p>
-
-<H2>Notes about using sections</H2>
-
-<p>The general guidelines are:</p>
-
-<UL>
-<LI>
- If you are attempting to match objects at the filesystem level
- then you must use <CODE><Directory></CODE> and/or
- <CODE><Files></CODE>.
-</LI>
-
-<LI>
- If you are attempting to match objects at the URL level then you
- must use <CODE><Location></CODE>
-</LI>
-</UL>
-
-<p>But a notable exception is:</p>
-
-<UL>
-<LI>
- proxy control is done via <CODE><Directory></CODE>. This is
- a legacy mistake because the proxy existed prior to
- <CODE><Location></CODE>. A future version of the config
- language should probably switch this to
- <CODE><Location></CODE>.
-</LI>
-</UL>
-
-<p>Note about .htaccess parsing:</p>
-
-<UL>
-<LI>
- Modifying .htaccess parsing during Location doesn't do
- anything because .htaccess parsing has already occurred.
-</UL>
-
-<p><CODE><Location></CODE> and symbolic links:</p>
-
-<UL>
-<LI>
- It is not possible to use "<CODE>Options FollowSymLinks</CODE>"
- or "<CODE>Options SymLinksIfOwnerMatch</CODE>" inside a
- <CODE><Location></CODE>, <CODE><LocationMatch></CODE>
- or <CODE><DirectoryMatch></CODE> section
- (the options are simply ignored).
- Using the options in question is only possible inside a
- <CODE><Directory></CODE> section (or a <CODE>.htaccess</CODE> file).
-</UL>
-
-<p><CODE><Files></CODE> and <CODE>Options</CODE>:</p>
-
-<UL>
-<LI>
- Apache won't check for it, but using an <CODE>Options</CODE>
- directive inside a <CODE><Files></CODE> section has no effect.
-</UL>
-
-<p>Another note:</p>
-
-<UL>
-<LI>
- There is actually a
- <CODE><Location></CODE>/<CODE><LocationMatch></CODE>
- sequence performed just before the name translation phase (where
- <CODE>Aliases</CODE> and <CODE>DocumentRoots</CODE> are used to
- map URLs to filenames). The results of this sequence are
- completely thrown away after the translation has completed.
-</LI>
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>How Directory, Location and Files sections work</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">How Directory, Location and Files sections
+ work</h1>
+
+ <p>The sections <a
+ href="mod/core.html#directory"><code><Directory></code></a>,
+ <a
+ href="mod/core.html#location"><code><Location></code></a>
+ and <a
+ href="mod/core.html#files"><code><Files></code></a> can
+ contain directives which only apply to specified directories,
+ URLs or files respectively. Also htaccess files can be used
+ inside a directory to apply directives to that directory. This
+ document explains how these different sections differ and how
+ they relate to each other when Apache decides which directives
+ apply for a particular directory or request URL.</p>
+
+ <h2>Directives allowed in the sections</h2>
+
+ <p>Everything that is syntactically allowed in
+ <code><Directory></code> is also allowed in
+ <code><Location></code> (except a
+ sub-<code><Files></code> section). Semantically, however
+ some things, most notably <code>AllowOverride</code> and the
+ two options <code>FollowSymLinks</code> and
+ <code>SymLinksIfOwnerMatch</code>, make no sense in
+ <code><Location></code>,
+ <code><LocationMatch></code> or
+ <code><DirectoryMatch></code>. The same for
+ <code><Files></code> -- syntactically everything is fine,
+ but semantically some things are different.</p>
+
+ <h2>How the sections are merged</h2>
+
+ <p>The order of merging is:</p>
+
+ <ol>
+ <li><code><Directory></code> (except regular
+ expressions) and .htaccess done simultaneously (with
+ .htaccess, if allowed, overriding
+ <code><Directory></code>)</li>
+
+ <li><code><DirectoryMatch></code>, and
+ <code><Directory></code> with regular expressions</li>
+
+ <li><code><Files></code> and
+ <code><FilesMatch></code> done simultaneously</li>
+
+ <li><code><Location></code> and
+ <code><LocationMatch></code> done simultaneously</li>
+ </ol>
+
+ <p>Apart from <code><Directory></code>, each group is
+ processed in the order that they appear in the configuration
+ files. <code><Directory></code> (group 1 above) is
+ processed in the order shortest directory component to longest.
+ If multiple <code><Directory></code> sections apply to
+ the same directory they they are processed in the configuration
+ file order. The configuration files are read in the order
+ httpd.conf, srm.conf and access.conf. Configurations included
+ via the <code>Include</code> directive will be treated as if
+ they were inside the including file at the location of the
+ <code>Include</code> directive.</p>
+
+ <p>Sections inside <code><VirtualHost></code> sections
+ are applied <em>after</em> the corresponding sections outside
+ the virtual host definition. This allows virtual hosts to
+ override the main server configuration.</p>
+
+ <p>Later sections override earlier ones.</p>
+
+ <h2>Notes about using sections</h2>
+
+ <p>The general guidelines are:</p>
+
+ <ul>
+ <li>If you are attempting to match objects at the filesystem
+ level then you must use <code><Directory></code> and/or
+ <code><Files></code>.</li>
+
+ <li>If you are attempting to match objects at the URL level
+ then you must use <code><Location></code></li>
+ </ul>
+
+ <p>But a notable exception is:</p>
+
+ <ul>
+ <li>proxy control is done via <code><Directory></code>.
+ This is a legacy mistake because the proxy existed prior to
+ <code><Location></code>. A future version of the config
+ language should probably switch this to
+ <code><Location></code>.</li>
+ </ul>
+
+ <p>Note about .htaccess parsing:</p>
+
+ <ul>
+ <li>Modifying .htaccess parsing during Location doesn't do
+ anything because .htaccess parsing has already occurred.</li>
+ </ul>
+
+ <p><code><Location></code> and symbolic links:</p>
+
+ <ul>
+ <li>It is not possible to use "<code>Options
+ FollowSymLinks</code>" or "<code>Options
+ SymLinksIfOwnerMatch</code>" inside a
+ <code><Location></code>,
+ <code><LocationMatch></code> or
+ <code><DirectoryMatch></code> section (the options are
+ simply ignored). Using the options in question is only
+ possible inside a <code><Directory></code> section (or
+ a <code>.htaccess</code> file).</li>
+ </ul>
+
+ <p><code><Files></code> and <code>Options</code>:</p>
+
+ <ul>
+ <li>Apache won't check for it, but using an
+ <code>Options</code> directive inside a
+ <code><Files></code> section has no effect.</li>
+ </ul>
+
+ <p>Another note:</p>
+
+ <ul>
+ <li>There is actually a
+ <code><Location></code>/<code><LocationMatch></code>
+ sequence performed just before the name translation phase
+ (where <code>Aliases</code> and <code>DocumentRoots</code>
+ are used to map URLs to filenames). The results of this
+ sequence are completely thrown away after the translation has
+ completed.</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>How Directory, Location and Files sections work</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">How Directory, Location and Files sections work</H1>
-
-<p>The sections <A
-HREF="mod/core.html#directory"><CODE><Directory></CODE></A>, <A
-HREF="mod/core.html#location"><CODE><Location></CODE></A> and <A
-HREF="mod/core.html#files"><CODE><Files></CODE></A> can contain
-directives which only apply to specified directories, URLs or files
-respectively. Also htaccess files can be used inside a directory to
-apply directives to that directory. This document explains how these
-different sections differ and how they relate to each other when
-Apache decides which directives apply for a particular directory or
-request URL.</p>
-
-<H2>Directives allowed in the sections</H2>
-
-<p>Everything that is syntactically allowed in
-<CODE><Directory></CODE> is also allowed in
-<CODE><Location></CODE> (except a sub-<CODE><Files></CODE>
-section). Semantically, however some things, most
-notably <CODE>AllowOverride</CODE> and the two options
-<CODE>FollowSymLinks</CODE> and <CODE>SymLinksIfOwnerMatch</CODE>,
-make no sense in <CODE><Location></CODE>,
-<CODE><LocationMatch></CODE> or <CODE><DirectoryMatch></CODE>.
-The same for <CODE><Files></CODE> -- syntactically everything
-is fine, but semantically some things are different.</p>
-
-<H2>How the sections are merged</H2>
-
-<p>The order of merging is:</p>
-
-<OL>
-
-<LI>
-
- <CODE><Directory></CODE> (except regular expressions) and
- .htaccess done simultaneously (with .htaccess, if allowed, overriding
- <CODE><Directory></CODE>)
-
-</LI>
-
-<LI>
- <CODE><DirectoryMatch></CODE>, and
- <CODE><Directory></CODE> with regular expressions
-
-</LI>
-
- <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done
- simultaneously
- </LI>
-
- <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done
- simultaneously
- </LI>
-
-</OL>
-
-<p>Apart from <CODE><Directory></CODE>, each group is processed in
-the order that they appear in the configuration
-files. <CODE><Directory></CODE> (group 1 above) is processed in
-the order shortest directory component to longest. If multiple
-<CODE><Directory></CODE> sections apply to the same directory
-they they are processed in the configuration file order. The
-configuration files are read in the order httpd.conf, srm.conf and
-access.conf. Configurations included via the <CODE>Include</CODE>
-directive will be treated as if they were inside the including file
-at the location of the <CODE>Include</CODE> directive.</p>
-
-<p>Sections inside <CODE><VirtualHost></CODE> sections are applied
-<EM>after</EM> the corresponding sections outside the virtual host
-definition. This allows virtual hosts to override the main server
-configuration.</p>
-
-<p>Later sections override earlier ones.</p>
-
-<H2>Notes about using sections</H2>
-
-<p>The general guidelines are:</p>
-
-<UL>
-<LI>
- If you are attempting to match objects at the filesystem level
- then you must use <CODE><Directory></CODE> and/or
- <CODE><Files></CODE>.
-</LI>
-
-<LI>
- If you are attempting to match objects at the URL level then you
- must use <CODE><Location></CODE>
-</LI>
-</UL>
-
-<p>But a notable exception is:</p>
-
-<UL>
-<LI>
- proxy control is done via <CODE><Directory></CODE>. This is
- a legacy mistake because the proxy existed prior to
- <CODE><Location></CODE>. A future version of the config
- language should probably switch this to
- <CODE><Location></CODE>.
-</LI>
-</UL>
-
-<p>Note about .htaccess parsing:</p>
-
-<UL>
-<LI>
- Modifying .htaccess parsing during Location doesn't do
- anything because .htaccess parsing has already occurred.
-</UL>
-
-<p><CODE><Location></CODE> and symbolic links:</p>
-
-<UL>
-<LI>
- It is not possible to use "<CODE>Options FollowSymLinks</CODE>"
- or "<CODE>Options SymLinksIfOwnerMatch</CODE>" inside a
- <CODE><Location></CODE>, <CODE><LocationMatch></CODE>
- or <CODE><DirectoryMatch></CODE> section
- (the options are simply ignored).
- Using the options in question is only possible inside a
- <CODE><Directory></CODE> section (or a <CODE>.htaccess</CODE> file).
-</UL>
-
-<p><CODE><Files></CODE> and <CODE>Options</CODE>:</p>
-
-<UL>
-<LI>
- Apache won't check for it, but using an <CODE>Options</CODE>
- directive inside a <CODE><Files></CODE> section has no effect.
-</UL>
-
-<p>Another note:</p>
-
-<UL>
-<LI>
- There is actually a
- <CODE><Location></CODE>/<CODE><LocationMatch></CODE>
- sequence performed just before the name translation phase (where
- <CODE>Aliases</CODE> and <CODE>DocumentRoots</CODE> are used to
- map URLs to filenames). The results of this sequence are
- completely thrown away after the translation has completed.
-</LI>
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>How Directory, Location and Files sections work</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">How Directory, Location and Files sections
+ work</h1>
+
+ <p>The sections <a
+ href="mod/core.html#directory"><code><Directory></code></a>,
+ <a
+ href="mod/core.html#location"><code><Location></code></a>
+ and <a
+ href="mod/core.html#files"><code><Files></code></a> can
+ contain directives which only apply to specified directories,
+ URLs or files respectively. Also htaccess files can be used
+ inside a directory to apply directives to that directory. This
+ document explains how these different sections differ and how
+ they relate to each other when Apache decides which directives
+ apply for a particular directory or request URL.</p>
+
+ <h2>Directives allowed in the sections</h2>
+
+ <p>Everything that is syntactically allowed in
+ <code><Directory></code> is also allowed in
+ <code><Location></code> (except a
+ sub-<code><Files></code> section). Semantically, however
+ some things, most notably <code>AllowOverride</code> and the
+ two options <code>FollowSymLinks</code> and
+ <code>SymLinksIfOwnerMatch</code>, make no sense in
+ <code><Location></code>,
+ <code><LocationMatch></code> or
+ <code><DirectoryMatch></code>. The same for
+ <code><Files></code> -- syntactically everything is fine,
+ but semantically some things are different.</p>
+
+ <h2>How the sections are merged</h2>
+
+ <p>The order of merging is:</p>
+
+ <ol>
+ <li><code><Directory></code> (except regular
+ expressions) and .htaccess done simultaneously (with
+ .htaccess, if allowed, overriding
+ <code><Directory></code>)</li>
+
+ <li><code><DirectoryMatch></code>, and
+ <code><Directory></code> with regular expressions</li>
+
+ <li><code><Files></code> and
+ <code><FilesMatch></code> done simultaneously</li>
+
+ <li><code><Location></code> and
+ <code><LocationMatch></code> done simultaneously</li>
+ </ol>
+
+ <p>Apart from <code><Directory></code>, each group is
+ processed in the order that they appear in the configuration
+ files. <code><Directory></code> (group 1 above) is
+ processed in the order shortest directory component to longest.
+ If multiple <code><Directory></code> sections apply to
+ the same directory they they are processed in the configuration
+ file order. The configuration files are read in the order
+ httpd.conf, srm.conf and access.conf. Configurations included
+ via the <code>Include</code> directive will be treated as if
+ they were inside the including file at the location of the
+ <code>Include</code> directive.</p>
+
+ <p>Sections inside <code><VirtualHost></code> sections
+ are applied <em>after</em> the corresponding sections outside
+ the virtual host definition. This allows virtual hosts to
+ override the main server configuration.</p>
+
+ <p>Later sections override earlier ones.</p>
+
+ <h2>Notes about using sections</h2>
+
+ <p>The general guidelines are:</p>
+
+ <ul>
+ <li>If you are attempting to match objects at the filesystem
+ level then you must use <code><Directory></code> and/or
+ <code><Files></code>.</li>
+
+ <li>If you are attempting to match objects at the URL level
+ then you must use <code><Location></code></li>
+ </ul>
+
+ <p>But a notable exception is:</p>
+
+ <ul>
+ <li>proxy control is done via <code><Directory></code>.
+ This is a legacy mistake because the proxy existed prior to
+ <code><Location></code>. A future version of the config
+ language should probably switch this to
+ <code><Location></code>.</li>
+ </ul>
+
+ <p>Note about .htaccess parsing:</p>
+
+ <ul>
+ <li>Modifying .htaccess parsing during Location doesn't do
+ anything because .htaccess parsing has already occurred.</li>
+ </ul>
+
+ <p><code><Location></code> and symbolic links:</p>
+
+ <ul>
+ <li>It is not possible to use "<code>Options
+ FollowSymLinks</code>" or "<code>Options
+ SymLinksIfOwnerMatch</code>" inside a
+ <code><Location></code>,
+ <code><LocationMatch></code> or
+ <code><DirectoryMatch></code> section (the options are
+ simply ignored). Using the options in question is only
+ possible inside a <code><Directory></code> section (or
+ a <code>.htaccess</code> file).</li>
+ </ul>
+
+ <p><code><Files></code> and <code>Options</code>:</p>
+
+ <ul>
+ <li>Apache won't check for it, but using an
+ <code>Options</code> directive inside a
+ <code><Files></code> section has no effect.</li>
+ </ul>
+
+ <p>Another note:</p>
+
+ <ul>
+ <li>There is actually a
+ <code><Location></code>/<code><LocationMatch></code>
+ sequence performed just before the name translation phase
+ (where <code>Aliases</code> and <code>DocumentRoots</code>
+ are used to map URLs to filenames). The results of this
+ sequence are completely thrown away after the translation has
+ completed.</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Server-Wide Configuration</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Server-Wide Configuration</h1>
-
-<p>This document explains some of the directives provided by the
-<a href="mod/core.html">core</A> server which are used to configure
-the basic operations of the server.</p>
-
-<ul>
-<li><a href="#identification">Server Identification</a></li>
-<li><a href="#locations">File Locations</a></li>
-<li><a href="#resource">Limiting Resource Usage</a></li>
-</ul>
-
-<hr>
-
-<h2><a name="identification">Server Identification</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/core.html#servername">ServerName</A><br>
-<A HREF="mod/core.html#serveradmin">ServerAdmin</A><br>
-<A HREF="mod/core.html#serversignature">ServerSignature</A><br>
-<A HREF="mod/core.html#servertokens">ServerTokens</A><br>
-<A HREF="mod/core.html#usecanonicalname">UseCanonicalName</A><br>
-</td></tr></table>
-
-<p>The <code>ServerAdmin</code> and <code>ServerTokens</code>
-directives control what information about the server will be presented
-in server-generated documents such as error messages.
-The <code>ServerTokens</code> directive sets the value of the
-Server HTTP response header field.</p>
-
-<p>The <code>ServerName</code> and <code>UseCanonicalName</code>
-directives are used by the server to determine how to construct
-self-referential URLs. For example, when a client requests a
-directory, but does not include the trailing slash in the directory
-name, Apache must redirect the client to the full name including the
-trailing slash so that the client will correctly resolve relative
-references in the document.</p>
-
-<hr>
-
-<h2><a name="locations">File Locations</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/core.html#coredumpdirectory">CoreDumpDirectory</a><br>
-<a href="mod/core.html#documentroot">DocumentRoot</a><br>
-<a href="mod/core.html#errorlog">ErrorLog</a><br>
-<a href="mod/core.html#lockfile">Lockfile</a><br>
-<a href="mod/core.html#pidfile">PidFile</a><br>
-<a href="mod/core.html#scoreboardfile">ScoreBoardFile</a><br>
-<a href="mod/core.html#serverroot">ServerRoot</a><br>
-</td></tr></table>
-
-<p>These directives control the locations of the various files that
-Apache needs for proper operation. When the pathname used does not
-begin with a slash "/", the files are located relative to the
-<code>ServerRoot</code>. Be careful about locating files in paths
-which are writable by non-root users. See the <a
-href="misc/security_tips.html">security tips</a> documentation for
-more details.</p>
-
-<hr>
-<h2><a name="resource">Limiting Resource Usage</a></h2>
-<table border="1">
-<tr><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<a href="mod/core.html#limitrequestbody">LimitRequestBody</a><br>
-<a href="mod/core.html#limitrequestfields">LimitRequestFields</a><br>
-<a href="mod/core.html#limitrequestfieldsize">LimitRequestFieldsize</a><br>
-<a href="mod/core.html#limitrequestline">LimitRequestLine</a><br>
-<a href="mod/core.html#rlimitcpu">RLimitCPU</a><br>
-<a href="mod/core.html#rlimitmem">RLimitMEM</a><br>
-<a href="mod/core.html#rlimitnproc">RLimitNPROC</a><br>
-<a href="mod/core.html#threadstacksize">ThreadStackSize</a><br>
-</td></tr></table>
-
-<p>The <code>LimitRequest</code>* directives are used to place limits
-on the amount of resources Apache will use in reading requests
-from clients. By limiting these values, some kinds of denial
-of service attacks can be mitigated.</p>
-
-<p>The <code>RLimit</code>* directives are used to limit the amount
-of resources which can be used by processes forked off from
-the Apache children. In particular, this will control
-resources used by CGI scripts and SSI exec commands.</p>
-
-<p>The <code>ThreadStackSize</code> directive is used only
-on Netware to control the stack size.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Server-Wide Configuration</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Server-Wide Configuration</h1>
+
+ <p>This document explains some of the directives provided by
+ the <a href="mod/core.html">core</a> server which are used to
+ configure the basic operations of the server.</p>
+
+ <ul>
+ <li><a href="#identification">Server Identification</a></li>
+
+ <li><a href="#locations">File Locations</a></li>
+
+ <li><a href="#resource">Limiting Resource Usage</a></li>
+ </ul>
+ <hr />
+
+ <h2><a id="identification" name="identification">Server
+ Identification</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/core.html#servername">ServerName</a><br />
+ <a href="mod/core.html#serveradmin">ServerAdmin</a><br />
+ <a
+ href="mod/core.html#serversignature">ServerSignature</a><br />
+ <a
+ href="mod/core.html#servertokens">ServerTokens</a><br />
+ <a
+ href="mod/core.html#usecanonicalname">UseCanonicalName</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>The <code>ServerAdmin</code> and <code>ServerTokens</code>
+ directives control what information about the server will be
+ presented in server-generated documents such as error messages.
+ The <code>ServerTokens</code> directive sets the value of the
+ Server HTTP response header field.</p>
+
+ <p>The <code>ServerName</code> and
+ <code>UseCanonicalName</code> directives are used by the server
+ to determine how to construct self-referential URLs. For
+ example, when a client requests a directory, but does not
+ include the trailing slash in the directory name, Apache must
+ redirect the client to the full name including the trailing
+ slash so that the client will correctly resolve relative
+ references in the document.</p>
+ <hr />
+
+ <h2><a id="locations" name="locations">File Locations</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/core.html#coredumpdirectory">CoreDumpDirectory</a><br />
+ <a
+ href="mod/core.html#documentroot">DocumentRoot</a><br />
+ <a href="mod/core.html#errorlog">ErrorLog</a><br />
+ <a href="mod/core.html#lockfile">Lockfile</a><br />
+ <a href="mod/core.html#pidfile">PidFile</a><br />
+ <a
+ href="mod/core.html#scoreboardfile">ScoreBoardFile</a><br />
+ <a href="mod/core.html#serverroot">ServerRoot</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>These directives control the locations of the various files
+ that Apache needs for proper operation. When the pathname used
+ does not begin with a slash "/", the files are located relative
+ to the <code>ServerRoot</code>. Be careful about locating files
+ in paths which are writable by non-root users. See the <a
+ href="misc/security_tips.html">security tips</a> documentation
+ for more details.</p>
+ <hr />
+
+ <h2><a id="resource" name="resource">Limiting Resource
+ Usage</a></h2>
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a
+ href="mod/core.html#limitrequestbody">LimitRequestBody</a><br />
+ <a
+ href="mod/core.html#limitrequestfields">LimitRequestFields</a><br />
+ <a
+ href="mod/core.html#limitrequestfieldsize">LimitRequestFieldsize</a><br />
+ <a
+ href="mod/core.html#limitrequestline">LimitRequestLine</a><br />
+ <a href="mod/core.html#rlimitcpu">RLimitCPU</a><br />
+ <a href="mod/core.html#rlimitmem">RLimitMEM</a><br />
+ <a href="mod/core.html#rlimitnproc">RLimitNPROC</a><br />
+ <a
+ href="mod/core.html#threadstacksize">ThreadStackSize</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <p>The <code>LimitRequest</code>* directives are used to place
+ limits on the amount of resources Apache will use in reading
+ requests from clients. By limiting these values, some kinds of
+ denial of service attacks can be mitigated.</p>
+
+ <p>The <code>RLimit</code>* directives are used to limit the
+ amount of resources which can be used by processes forked off
+ from the Apache children. In particular, this will control
+ resources used by CGI scripts and SSI exec commands.</p>
+
+ <p>The <code>ThreadStackSize</code> directive is used only on
+ Netware to control the stack size.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Server-Wide Configuration</title>
-</head>
-<!-- English revision: 1.6 -->
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000FF"
- vlink="#000080"
- alink="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">\e$B%5!<%PA4BN$N@_Dj\e(B</h1>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
-<p>
\e$B$3$N%I%-%e%a%s%H$G$O
\e(B<a href="mod/core.html">
\e$B%3%"
\e(B</a>
\e$B%5!<%P$N
\e(B
-\e$B%G%#%l%/%F%#%V$NCf$G!"4pK\F0:n$r@_Dj$9$k$?$a$N$b$N$r@bL@$7$^$9!#\e(B</p>
+ <title>Server-Wide Configuration</title>
+ </head>
+ <!-- English revision: 1.6 -->
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<ul>
-<li><a href="#identification">\e$B%5!<%P\e(B ID</a></li>
-<li><a href="#locations">\e$B%U%!%$%k$N0LCV\e(B</a></li>
-<li><a href="#resource">\e$B%j%=!<%9$N@)8B\e(B</a></li>
-</ul>
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
-<hr>
-
-<h2><a name="identification">\e$B%5!<%P\e(B ID</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-
-<a href="mod/core.html#servername">ServerName</a><br>
-<a href="mod/core.html#serveradmin">ServerAdmin</a><br>
-<a href="mod/core.html#serversignature">ServerSignature</a><br>
-<a href="mod/core.html#servertokens">ServerTokens</a><br>
-<a href="mod/core.html#usecanonicalname">UseCanonicalName</a><br>
-</td></tr></table>
-
-<p><code>ServerAdmin</code> \e$B%G%#%l%/%F%#%V$H\e(B <code>ServerTokens</code>
-\e$B%G%#%l%/%F%#%V$O!"%(%i!<%a%C%;!<%8$J$I$N%5!<%P$,:n$k%I%-%e%a%s%H$K!"\e(B
-\e$B$I$N$h$&$J%5!<%P$N>pJs$rI=<($9$k$+$r@)8f$7$^$9!#\e(B<code>ServerTokens</code>
-\e$B%G%#%l%/%F%#%V$O!"\e(BServer HTTP \e$B%l%9%]%s%9%X%C%@%U%#!<%k%I$NCM$r\e(B
-\e$B@_Dj$7$^$9!#\e(B</p>
-
-<p><code>ServerName</code> \e$B%G%#%l%/%F%#%V$H\e(B <code>UseCanonicalName</code>
-\e$B%G%#%l%/%F%#%V$O!"%5!<%P$,<+J,<+?H$r;2>H$9$k\e(B URL \e$B$r:n$k$H$-$K\e(B
-\e$B;H$o$l$^$9!#$?$H$($P!"%/%i%$%"%s%H$,%G%#%l%/%H%j$rMW5a$7$F!"\e(B
-\e$B$=$N%G%#%l%/%H%jL>$N:G8e$K%9%i%C%7%e$,IU$$$F$$$J$$$h$&$J>l9g$K$O!"\e(B
-\e$B%I%-%e%a%s%H$NAjBPE*$J;2>H$r@5$7$/2r7h$G$-$k$h$&$K$9$k$?$a$K!"\e(B
-Apache \e$B$O:G8e$N%9%i%C%7%e$r4^$s$@40A4$J%Q%9$K%/%i%$%"%s%H$r\e(B
-\e$B%j%@%$%l%/%H$5$;$kI,MW$,$"$j$^$9!#\e(B</p>
-
-<hr>
-
-<h2><a name="locations">\e$B%U%!%$%k$N0LCV\e(B</a></h2>
-
-<table border="1">
-<tr><td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-
-<a href="mod/core.html#coredumpdirectory">CoreDumpDirectory</a><br>
-<a href="mod/core.html#documentroot">DocumentRoot</a><br>
-<a href="mod/core.html#errorlog">ErrorLog</a><br>
-<a href="mod/core.html#lockfile">Lockfile</a><br>
-<a href="mod/core.html#pidfile">PidFile</a><br>
-<a href="mod/core.html#scoreboardfile">ScoreBoardFile</a><br>
-<a href="mod/core.html#serverroot">ServerRoot</a><br>
-</td></tr></table>
-
-<p>\e$B$3$l$i$N%G%#%l%/%F%#%V$O\e(B Apache \e$B$,E,@Z$JF0:n$r$9$k$?$a$KI,MW$J\e(B
-\e$B3F<o%U%!%$%k$N0LCV$r@)8f$7$^$9!#%Q%9$,%9%i%C%7%e\e(B "/" \e$B$G;O$^$C$F$$$J$$\e(B
-\e$B$H$-$O!"%U%!%$%k$O\e(B <code>ServerRoot</code> \e$B$+$i$NAjBP%Q%9$H$7$F\e(B
-\e$BC5$5$l$^$9!#\e(Broot \e$B0J30$N%f!<%6$,=q$-9~$_2DG=$J%Q%9$K%U%!%$%k$r\e(B
-
\e$BCV$/>l9g$OCm0U$,I,MW$G$9!#>\:Y$O
\e(B<a
-href="misc/security_tips.html">\e$B!V%;%-%e%j%F%#>pJs!W\e(B</a>\e$B$r\e(B
-\e$B;2>H$7$F$/$@$5$$!#\e(B</p>
-
-<hr>
-<h2><a name="resource">\e$B%j%=!<%9$N@)8B\e(B</a></h2>
-<table border="1">
-<tr><td valign="top">
-<strong>\e$B4XO"%G%#%l%/%F%#%V\e(B</strong><br><br>
-
-<a href="mod/core.html#limitrequestbody">LimitRequestBody</a><br>
-<a href="mod/core.html#limitrequestfields">LimitRequestFields</a><br>
-<a href="mod/core.html#limitrequestfieldsize">LimitRequestFieldsize</a><br>
-<a href="mod/core.html#limitrequestline">LimitRequestLine</a><br>
-<a href="mod/core.html#rlimitcpu">RLimitCPU</a><br>
-<a href="mod/core.html#rlimitmem">RLimitMEM</a><br>
-<a href="mod/core.html#rlimitnproc">RLimitNPROC</a><br>
-<a href="mod/core.html#threadstacksize">ThreadStackSize</a><br>
-</td></tr></table>
-
-<p><code>LimitRequest</code>* \e$B%G%#%l%/%F%#%V$O\e(B Apache \e$B$,\e(B
-\e$B%/%i%$%"%s%H$+$i$N%j%/%(%9%HFI$_9~$_$G;H$&%j%=!<%9$r@)8B$9$k$?$a$K\e(B
-\e$B;H$o$l$^$9!#$3$l$i$NCM$r@)8B$9$k$3$H$G!"$$$/$D$+$N%5!<%S%95qH]967b$O\e(B
-\e$B1F6A$rOB$i$2$k$3$H$,$G$-$^$9!#\e(B</p>
-
-<p><code>RLimit</code>* \e$B%G%#%l%/%F%#%V$O!"\e(BApache \e$B$N;R%W%m%;%9$+$i\e(B
-fork \e$B$5$l$?%W%m%;%9$,;HMQ$9$k%j%=!<%9$r@)8B$9$k$?$a$K\e(B
-\e$B;H$o$l$^$9!#FC$K!"$3$l$O\e(B CGI \e$B%9%/%j%W%H$H\e(B SSI exec \e$B%3%^%s%I$G\e(B
-\e$B;H$o$l$k%j%=!<%9$r@)8f$7$^$9!#\e(B</p>
-
-<p><code>ThreadStackSize</code> \e$B$O\e(B Netware \e$B$G$N$_!"%9%?%C%/$NBg$-$5$r\e(B
-\e$B@)8f$9$k$?$a$K;H$o$l$^$9!#\e(B</p>
-
-<!--#include virtual="footer.html" -->
-</body>
+ <h1 align="center">$B%5!</h1>
+ </body>
</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Stopping and Restarting the Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Stopping and Restarting the Server</H1>
-
-<P>This document covers stopping and restarting Apache on Unix-like
-systems. Windows users should see <A
-HREF="platform/windows.html#signal">Signalling Apache when
-running</A>.</P>
-
-<P>You will notice many <CODE>httpd</CODE> executables running on your system,
-but you should not send signals to any of them except the parent, whose
-pid is in the <A HREF="mod/core.html#pidfile">PidFile</A>. That is to
-say you shouldn't ever need to send signals to any process except the
-parent. There are three signals that you can send the parent:
-<CODE>TERM</CODE>, <CODE>HUP</CODE>, and <CODE>USR1</CODE>, which will
-be described in a moment.
-
-<P>To send a signal to the parent you should issue a command such as:
-<BLOCKQUOTE><PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Stopping and Restarting the Server</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Stopping and Restarting the Server</h1>
+
+ <p>This document covers stopping and restarting Apache on
+ Unix-like systems. Windows users should see <a
+ href="platform/windows.html#signal">Signalling Apache when
+ running</a>.</p>
+
+ <p>You will notice many <code>httpd</code> executables running
+ on your system, but you should not send signals to any of them
+ except the parent, whose pid is in the <a
+ href="mod/core.html#pidfile">PidFile</a>. That is to say you
+ shouldn't ever need to send signals to any process except the
+ parent. There are three signals that you can send the parent:
+ <code>TERM</code>, <code>HUP</code>, and <code>USR1</code>,
+ which will be described in a moment.</p>
+
+ <p>To send a signal to the parent you should issue a command
+ such as:</p>
+
+ <blockquote>
+<pre>
kill -TERM `cat /usr/local/apache/logs/httpd.pid`
-</PRE></BLOCKQUOTE>
+</pre>
+ </blockquote>
+ You can read about its progress by issuing:
-You can read about its progress by issuing:
-
-<BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
tail -f /usr/local/apache/logs/error_log
-</PRE></BLOCKQUOTE>
-
-Modify those examples to match your
-<A HREF="mod/core.html#serverroot">ServerRoot</A> and
-<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-
-<p>A shell script called <a
-href="programs/apachectl.html">apachectl</a> is provided which
-automates the processing of signalling Apache. For details about this
-script, see the documentation on <a href="invoking.html">starting
-Apache</a>.</p>
-
-<H3>Stop Now</h3>
-
-<p><strong>Signal:</strong> TERM<br>
-<code>apachectl stop</code></p>
-
-<P>Sending the <CODE>TERM</CODE> signal to the parent causes it to
-immediately attempt to kill off all of its children. It may take it
-several seconds to complete killing off its children. Then the
-parent itself exits. Any requests in progress are terminated, and no
-further requests are served.
-
-<H3>Graceful Restart</H3>
-
-<p><strong>Signal:</strong> USR1<br>
-<code>apachectl graceful</code></p>
-
-<P>The <CODE>USR1</CODE> signal causes the parent process to <EM>advise</EM>
-the children to exit after their current request (or to exit immediately
-if they're not serving anything). The parent re-reads its configuration
-files and re-opens its log files. As each child dies off the parent
-replaces it with a child from the new <EM>generation</EM> of the
-configuration, which begins serving new requests immediately.</p>
-
-<I>On certain platforms that do not allow USR1 to be used for a graceful
-restart, an alternative signal may be used (such as WINCH). apachectl
-graceful will send the right signal for your platform.</I>
-
-<P>This code is designed to always respect the <A
-HREF="mod/mpm_common.html#maxclients">MaxClients</A>, <A
-HREF="mod/prefork.html#minspareservers">MinSpareServers</A>, and <A
-HREF="mod/prefork.html#maxspareservers">MaxSpareServers</A>
-settings. Furthermore, it respects <A
-HREF="mod/mpm_common.html#startservers">StartServers</A> in the
-following manner: if after one second at least StartServers new
-children have not been created, then create enough to pick up the
-slack. This is to say that the code tries to maintain both the number
-of children appropriate for the current load on the server, and
-respect your wishes with the StartServers parameter.</p>
-
-<P>Users of the
-<A HREF="mod/mod_status.html">status module</A>
-will notice that the server statistics
-are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The
-code
-was written to both minimize the time in which the server is unable to serve
-new requests (they will be queued up by the operating system, so they're
-not lost in any event) and to respect your tuning parameters. In order
-to do this it has to keep the <EM>scoreboard</EM> used to keep track
-of all children across generations.
-
-<P>The status module will also use a <CODE>G</CODE> to indicate those
-children which are still serving requests started before the graceful
-restart was given.
-
-<P>At present there is no way for a log rotation script using
-<CODE>USR1</CODE> to know for certain that all children writing the
-pre-restart log have finished. We suggest that you use a suitable delay
-after sending the <CODE>USR1</CODE> signal before you do anything with the
-old log. For example if most of your hits take less than 10 minutes to
-complete for users on low bandwidth links then you could wait 15 minutes
-before doing anything with the old log.
-
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it
-when you issue a restart then your parent will not restart, it will
-exit with an error. In the case of graceful restarts it will also
-leave children running when it exits. (These are the children which
-are "gracefully exiting" by handling their last request.) This will
-cause problems if you attempt to restart the server -- it will not be
-able to bind to its listening ports. Before doing a restart, you can
-check the syntax of the configuration files with the <CODE>-t</CODE>
-command line argument (see <A
-HREF="programs/httpd.html">httpd</A>). This still will not guarantee
-that the server will restart correctly. To check the semantics of the
-configuration files as well as the syntax, you can try starting httpd
-as a non-root user. If there are no errors it will attempt to open
-its sockets and logs and fail because it's not root (or because the
-currently running httpd already has those ports bound). If it fails
-for any other reason then it's probably a config file error and the
-error should be fixed before issuing the graceful restart.
-
-
-<H3>Restart Now</H3>
-
-<p><strong>Signal:</strong> HUP<br>
-<code>apachectl restart</code></p>
-
-<P>Sending the <CODE>HUP</CODE> signal to the parent causes it to kill off
-its children like in <CODE>TERM</CODE> but the parent doesn't exit. It
-re-reads its configuration files, and re-opens any log files.
-Then it spawns a new set of children and continues
-serving hits.
-
-<P>Users of the
-<A HREF="mod/mod_status.html">status module</A>
-will notice that the server statistics are
-set to zero when a <CODE>HUP</CODE> is sent.
-
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it when
-you issue a
-restart then your parent will not restart, it will exit with an error.
-See below for a method of avoiding this.
-
-
-<H3>Appendix: signals and race conditions</H3>
-
-<P>Prior to Apache 1.2b9 there were several <EM>race conditions</EM>
-involving the restart and die signals (a simple description of race
-condition is: a time-sensitive problem, as in if something happens at just
-the wrong time it won't behave as expected). For those architectures that
-have the "right" feature set we have eliminated as many as we can.
-But it should be noted that there still do exist race conditions on
-certain architectures.
-
-<P>Architectures that use an on disk
-<A HREF="mod/core.html#scoreboardfile">ScoreBoardFile</A>
-have the potential to corrupt their scoreboards. This can result in
-the "bind: Address already in use" (after <CODE>HUP</CODE>) or
-"long lost child came home!" (after <CODE>USR1</CODE>). The former is
-a fatal error, while the latter just causes the server to lose a scoreboard
-slot. So it might be advisable to use graceful restarts, with
-an occasional hard restart. These problems are very difficult to work
-around, but fortunately most architectures do not require a scoreboard file.
-See the <a HREF=
-"mod/core.html#scoreboardfile">ScoreBoardFile</a> documentation for a
-architecture uses it.
-
-<P><CODE>NEXT</CODE> and <CODE>MACHTEN</CODE> (68k only) have small race
-conditions
-which can cause a restart/die signal to be lost, but should not cause the
-server to do anything otherwise problematic.
-<!-- they don't have sigaction, or we're not using it -djg -->
-
-<P>All architectures have a small race condition in each child involving
-the second and subsequent requests on a persistent HTTP connection
-(KeepAlive). It may exit after reading the request line but before
-reading any of the request headers. There is a fix that was discovered
-too late to make 1.2. In theory this isn't an issue because the KeepAlive
-client has to expect these events because of network latencies and
-server timeouts. In practice it doesn't seem to affect anything either
--- in a test case the server was restarted twenty times per second and
-clients successfully browsed the site without getting broken images or
-empty documents.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ </blockquote>
+ Modify those examples to match your <a
+ href="mod/core.html#serverroot">ServerRoot</a> and <a
+ href="mod/core.html#pidfile">PidFile</a> settings.
+
+ <p>A shell script called <a
+ href="programs/apachectl.html">apachectl</a> is provided which
+ automates the processing of signalling Apache. For details
+ about this script, see the documentation on <a
+ href="invoking.html">starting Apache</a>.</p>
+
+ <h3>Stop Now</h3>
+
+ <p><strong>Signal:</strong> TERM<br />
+ <code>apachectl stop</code></p>
+
+ <p>Sending the <code>TERM</code> signal to the parent causes it
+ to immediately attempt to kill off all of its children. It may
+ take it several seconds to complete killing off its children.
+ Then the parent itself exits. Any requests in progress are
+ terminated, and no further requests are served.</p>
+
+ <h3>Graceful Restart</h3>
+
+ <p><strong>Signal:</strong> USR1<br />
+ <code>apachectl graceful</code></p>
+
+ <p>The <code>USR1</code> signal causes the parent process to
+ <em>advise</em> the children to exit after their current
+ request (or to exit immediately if they're not serving
+ anything). The parent re-reads its configuration files and
+ re-opens its log files. As each child dies off the parent
+ replaces it with a child from the new <em>generation</em> of
+ the configuration, which begins serving new requests
+ immediately.</p>
+ <i>On certain platforms that do not allow USR1 to be used for a
+ graceful restart, an alternative signal may be used (such as
+ WINCH). apachectl graceful will send the right signal for your
+ platform.</i>
+
+ <p>This code is designed to always respect the <a
+ href="mod/mpm_common.html#maxclients">MaxClients</a>, <a
+ href="mod/prefork.html#minspareservers">MinSpareServers</a>,
+ and <a
+ href="mod/prefork.html#maxspareservers">MaxSpareServers</a>
+ settings. Furthermore, it respects <a
+ href="mod/mpm_common.html#startservers">StartServers</a> in the
+ following manner: if after one second at least StartServers new
+ children have not been created, then create enough to pick up
+ the slack. This is to say that the code tries to maintain both
+ the number of children appropriate for the current load on the
+ server, and respect your wishes with the StartServers
+ parameter.</p>
+
+ <p>Users of the <a href="mod/mod_status.html">status module</a>
+ will notice that the server statistics are <strong>not</strong>
+ set to zero when a <code>USR1</code> is sent. The code was
+ written to both minimize the time in which the server is unable
+ to serve new requests (they will be queued up by the operating
+ system, so they're not lost in any event) and to respect your
+ tuning parameters. In order to do this it has to keep the
+ <em>scoreboard</em> used to keep track of all children across
+ generations.</p>
+
+ <p>The status module will also use a <code>G</code> to indicate
+ those children which are still serving requests started before
+ the graceful restart was given.</p>
+
+ <p>At present there is no way for a log rotation script using
+ <code>USR1</code> to know for certain that all children writing
+ the pre-restart log have finished. We suggest that you use a
+ suitable delay after sending the <code>USR1</code> signal
+ before you do anything with the old log. For example if most of
+ your hits take less than 10 minutes to complete for users on
+ low bandwidth links then you could wait 15 minutes before doing
+ anything with the old log.</p>
+
+ <p><strong>Note:</strong> If your configuration file has errors
+ in it when you issue a restart then your parent will not
+ restart, it will exit with an error. In the case of graceful
+ restarts it will also leave children running when it exits.
+ (These are the children which are "gracefully exiting" by
+ handling their last request.) This will cause problems if you
+ attempt to restart the server -- it will not be able to bind to
+ its listening ports. Before doing a restart, you can check the
+ syntax of the configuration files with the <code>-t</code>
+ command line argument (see <a
+ href="programs/httpd.html">httpd</a>). This still will not
+ guarantee that the server will restart correctly. To check the
+ semantics of the configuration files as well as the syntax, you
+ can try starting httpd as a non-root user. If there are no
+ errors it will attempt to open its sockets and logs and fail
+ because it's not root (or because the currently running httpd
+ already has those ports bound). If it fails for any other
+ reason then it's probably a config file error and the error
+ should be fixed before issuing the graceful restart.</p>
+
+ <h3>Restart Now</h3>
+
+ <p><strong>Signal:</strong> HUP<br />
+ <code>apachectl restart</code></p>
+
+ <p>Sending the <code>HUP</code> signal to the parent causes it
+ to kill off its children like in <code>TERM</code> but the
+ parent doesn't exit. It re-reads its configuration files, and
+ re-opens any log files. Then it spawns a new set of children
+ and continues serving hits.</p>
+
+ <p>Users of the <a href="mod/mod_status.html">status module</a>
+ will notice that the server statistics are set to zero when a
+ <code>HUP</code> is sent.</p>
+
+ <p><strong>Note:</strong> If your configuration file has errors
+ in it when you issue a restart then your parent will not
+ restart, it will exit with an error. See below for a method of
+ avoiding this.</p>
+
+ <h3>Appendix: signals and race conditions</h3>
+
+ <p>Prior to Apache 1.2b9 there were several <em>race
+ conditions</em> involving the restart and die signals (a simple
+ description of race condition is: a time-sensitive problem, as
+ in if something happens at just the wrong time it won't behave
+ as expected). For those architectures that have the "right"
+ feature set we have eliminated as many as we can. But it should
+ be noted that there still do exist race conditions on certain
+ architectures.</p>
+
+ <p>Architectures that use an on disk <a
+ href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the
+ potential to corrupt their scoreboards. This can result in the
+ "bind: Address already in use" (after <code>HUP</code>) or
+ "long lost child came home!" (after <code>USR1</code>). The
+ former is a fatal error, while the latter just causes the
+ server to lose a scoreboard slot. So it might be advisable to
+ use graceful restarts, with an occasional hard restart. These
+ problems are very difficult to work around, but fortunately
+ most architectures do not require a scoreboard file. See the <a
+ href="mod/core.html#scoreboardfile">ScoreBoardFile</a>
+ documentation for a architecture uses it.</p>
+
+ <p><code>NEXT</code> and <code>MACHTEN</code> (68k only) have
+ small race conditions which can cause a restart/die signal to
+ be lost, but should not cause the server to do anything
+ otherwise problematic.
+ <!-- they don't have sigaction, or we're not using it -djg -->
+ </p>
+
+ <p>All architectures have a small race condition in each child
+ involving the second and subsequent requests on a persistent
+ HTTP connection (KeepAlive). It may exit after reading the
+ request line but before reading any of the request headers.
+ There is a fix that was discovered too late to make 1.2. In
+ theory this isn't an issue because the KeepAlive client has to
+ expect these events because of network latencies and server
+ timeouts. In practice it doesn't seem to affect anything either
+ -- in a test case the server was restarted twenty times per
+ second and clients successfully browsed the site without
+ getting broken images or empty documents.
+ <!--#include virtual="footer.html" -->
+ </p>
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Stopping and Restarting the Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Stopping and Restarting the Server</H1>
-
-<P>This document covers stopping and restarting Apache on Unix-like
-systems. Windows users should see <A
-HREF="platform/windows.html#signal">Signalling Apache when
-running</A>.</P>
-
-<P>You will notice many <CODE>httpd</CODE> executables running on your system,
-but you should not send signals to any of them except the parent, whose
-pid is in the <A HREF="mod/core.html#pidfile">PidFile</A>. That is to
-say you shouldn't ever need to send signals to any process except the
-parent. There are three signals that you can send the parent:
-<CODE>TERM</CODE>, <CODE>HUP</CODE>, and <CODE>USR1</CODE>, which will
-be described in a moment.
-
-<P>To send a signal to the parent you should issue a command such as:
-<BLOCKQUOTE><PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Stopping and Restarting the Server</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Stopping and Restarting the Server</h1>
+
+ <p>This document covers stopping and restarting Apache on
+ Unix-like systems. Windows users should see <a
+ href="platform/windows.html#signal">Signalling Apache when
+ running</a>.</p>
+
+ <p>You will notice many <code>httpd</code> executables running
+ on your system, but you should not send signals to any of them
+ except the parent, whose pid is in the <a
+ href="mod/core.html#pidfile">PidFile</a>. That is to say you
+ shouldn't ever need to send signals to any process except the
+ parent. There are three signals that you can send the parent:
+ <code>TERM</code>, <code>HUP</code>, and <code>USR1</code>,
+ which will be described in a moment.</p>
+
+ <p>To send a signal to the parent you should issue a command
+ such as:</p>
+
+ <blockquote>
+<pre>
kill -TERM `cat /usr/local/apache/logs/httpd.pid`
-</PRE></BLOCKQUOTE>
+</pre>
+ </blockquote>
+ You can read about its progress by issuing:
-You can read about its progress by issuing:
-
-<BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
tail -f /usr/local/apache/logs/error_log
-</PRE></BLOCKQUOTE>
-
-Modify those examples to match your
-<A HREF="mod/core.html#serverroot">ServerRoot</A> and
-<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-
-<p>A shell script called <a
-href="programs/apachectl.html">apachectl</a> is provided which
-automates the processing of signalling Apache. For details about this
-script, see the documentation on <a href="invoking.html">starting
-Apache</a>.</p>
-
-<H3>Stop Now</h3>
-
-<p><strong>Signal:</strong> TERM<br>
-<code>apachectl stop</code></p>
-
-<P>Sending the <CODE>TERM</CODE> signal to the parent causes it to
-immediately attempt to kill off all of its children. It may take it
-several seconds to complete killing off its children. Then the
-parent itself exits. Any requests in progress are terminated, and no
-further requests are served.
-
-<H3>Graceful Restart</H3>
-
-<p><strong>Signal:</strong> USR1<br>
-<code>apachectl graceful</code></p>
-
-<P>The <CODE>USR1</CODE> signal causes the parent process to <EM>advise</EM>
-the children to exit after their current request (or to exit immediately
-if they're not serving anything). The parent re-reads its configuration
-files and re-opens its log files. As each child dies off the parent
-replaces it with a child from the new <EM>generation</EM> of the
-configuration, which begins serving new requests immediately.</p>
-
-<I>On certain platforms that do not allow USR1 to be used for a graceful
-restart, an alternative signal may be used (such as WINCH). apachectl
-graceful will send the right signal for your platform.</I>
-
-<P>This code is designed to always respect the <A
-HREF="mod/mpm_common.html#maxclients">MaxClients</A>, <A
-HREF="mod/prefork.html#minspareservers">MinSpareServers</A>, and <A
-HREF="mod/prefork.html#maxspareservers">MaxSpareServers</A>
-settings. Furthermore, it respects <A
-HREF="mod/mpm_common.html#startservers">StartServers</A> in the
-following manner: if after one second at least StartServers new
-children have not been created, then create enough to pick up the
-slack. This is to say that the code tries to maintain both the number
-of children appropriate for the current load on the server, and
-respect your wishes with the StartServers parameter.</p>
-
-<P>Users of the
-<A HREF="mod/mod_status.html">status module</A>
-will notice that the server statistics
-are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The
-code
-was written to both minimize the time in which the server is unable to serve
-new requests (they will be queued up by the operating system, so they're
-not lost in any event) and to respect your tuning parameters. In order
-to do this it has to keep the <EM>scoreboard</EM> used to keep track
-of all children across generations.
-
-<P>The status module will also use a <CODE>G</CODE> to indicate those
-children which are still serving requests started before the graceful
-restart was given.
-
-<P>At present there is no way for a log rotation script using
-<CODE>USR1</CODE> to know for certain that all children writing the
-pre-restart log have finished. We suggest that you use a suitable delay
-after sending the <CODE>USR1</CODE> signal before you do anything with the
-old log. For example if most of your hits take less than 10 minutes to
-complete for users on low bandwidth links then you could wait 15 minutes
-before doing anything with the old log.
-
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it
-when you issue a restart then your parent will not restart, it will
-exit with an error. In the case of graceful restarts it will also
-leave children running when it exits. (These are the children which
-are "gracefully exiting" by handling their last request.) This will
-cause problems if you attempt to restart the server -- it will not be
-able to bind to its listening ports. Before doing a restart, you can
-check the syntax of the configuration files with the <CODE>-t</CODE>
-command line argument (see <A
-HREF="programs/httpd.html">httpd</A>). This still will not guarantee
-that the server will restart correctly. To check the semantics of the
-configuration files as well as the syntax, you can try starting httpd
-as a non-root user. If there are no errors it will attempt to open
-its sockets and logs and fail because it's not root (or because the
-currently running httpd already has those ports bound). If it fails
-for any other reason then it's probably a config file error and the
-error should be fixed before issuing the graceful restart.
-
-
-<H3>Restart Now</H3>
-
-<p><strong>Signal:</strong> HUP<br>
-<code>apachectl restart</code></p>
-
-<P>Sending the <CODE>HUP</CODE> signal to the parent causes it to kill off
-its children like in <CODE>TERM</CODE> but the parent doesn't exit. It
-re-reads its configuration files, and re-opens any log files.
-Then it spawns a new set of children and continues
-serving hits.
-
-<P>Users of the
-<A HREF="mod/mod_status.html">status module</A>
-will notice that the server statistics are
-set to zero when a <CODE>HUP</CODE> is sent.
-
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it when
-you issue a
-restart then your parent will not restart, it will exit with an error.
-See below for a method of avoiding this.
-
-
-<H3>Appendix: signals and race conditions</H3>
-
-<P>Prior to Apache 1.2b9 there were several <EM>race conditions</EM>
-involving the restart and die signals (a simple description of race
-condition is: a time-sensitive problem, as in if something happens at just
-the wrong time it won't behave as expected). For those architectures that
-have the "right" feature set we have eliminated as many as we can.
-But it should be noted that there still do exist race conditions on
-certain architectures.
-
-<P>Architectures that use an on disk
-<A HREF="mod/core.html#scoreboardfile">ScoreBoardFile</A>
-have the potential to corrupt their scoreboards. This can result in
-the "bind: Address already in use" (after <CODE>HUP</CODE>) or
-"long lost child came home!" (after <CODE>USR1</CODE>). The former is
-a fatal error, while the latter just causes the server to lose a scoreboard
-slot. So it might be advisable to use graceful restarts, with
-an occasional hard restart. These problems are very difficult to work
-around, but fortunately most architectures do not require a scoreboard file.
-See the <a HREF=
-"mod/core.html#scoreboardfile">ScoreBoardFile</a> documentation for a
-architecture uses it.
-
-<P><CODE>NEXT</CODE> and <CODE>MACHTEN</CODE> (68k only) have small race
-conditions
-which can cause a restart/die signal to be lost, but should not cause the
-server to do anything otherwise problematic.
-<!-- they don't have sigaction, or we're not using it -djg -->
-
-<P>All architectures have a small race condition in each child involving
-the second and subsequent requests on a persistent HTTP connection
-(KeepAlive). It may exit after reading the request line but before
-reading any of the request headers. There is a fix that was discovered
-too late to make 1.2. In theory this isn't an issue because the KeepAlive
-client has to expect these events because of network latencies and
-server timeouts. In practice it doesn't seem to affect anything either
--- in a test case the server was restarted twenty times per second and
-clients successfully browsed the site without getting broken images or
-empty documents.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ </blockquote>
+ Modify those examples to match your <a
+ href="mod/core.html#serverroot">ServerRoot</a> and <a
+ href="mod/core.html#pidfile">PidFile</a> settings.
+
+ <p>A shell script called <a
+ href="programs/apachectl.html">apachectl</a> is provided which
+ automates the processing of signalling Apache. For details
+ about this script, see the documentation on <a
+ href="invoking.html">starting Apache</a>.</p>
+
+ <h3>Stop Now</h3>
+
+ <p><strong>Signal:</strong> TERM<br />
+ <code>apachectl stop</code></p>
+
+ <p>Sending the <code>TERM</code> signal to the parent causes it
+ to immediately attempt to kill off all of its children. It may
+ take it several seconds to complete killing off its children.
+ Then the parent itself exits. Any requests in progress are
+ terminated, and no further requests are served.</p>
+
+ <h3>Graceful Restart</h3>
+
+ <p><strong>Signal:</strong> USR1<br />
+ <code>apachectl graceful</code></p>
+
+ <p>The <code>USR1</code> signal causes the parent process to
+ <em>advise</em> the children to exit after their current
+ request (or to exit immediately if they're not serving
+ anything). The parent re-reads its configuration files and
+ re-opens its log files. As each child dies off the parent
+ replaces it with a child from the new <em>generation</em> of
+ the configuration, which begins serving new requests
+ immediately.</p>
+ <i>On certain platforms that do not allow USR1 to be used for a
+ graceful restart, an alternative signal may be used (such as
+ WINCH). apachectl graceful will send the right signal for your
+ platform.</i>
+
+ <p>This code is designed to always respect the <a
+ href="mod/mpm_common.html#maxclients">MaxClients</a>, <a
+ href="mod/prefork.html#minspareservers">MinSpareServers</a>,
+ and <a
+ href="mod/prefork.html#maxspareservers">MaxSpareServers</a>
+ settings. Furthermore, it respects <a
+ href="mod/mpm_common.html#startservers">StartServers</a> in the
+ following manner: if after one second at least StartServers new
+ children have not been created, then create enough to pick up
+ the slack. This is to say that the code tries to maintain both
+ the number of children appropriate for the current load on the
+ server, and respect your wishes with the StartServers
+ parameter.</p>
+
+ <p>Users of the <a href="mod/mod_status.html">status module</a>
+ will notice that the server statistics are <strong>not</strong>
+ set to zero when a <code>USR1</code> is sent. The code was
+ written to both minimize the time in which the server is unable
+ to serve new requests (they will be queued up by the operating
+ system, so they're not lost in any event) and to respect your
+ tuning parameters. In order to do this it has to keep the
+ <em>scoreboard</em> used to keep track of all children across
+ generations.</p>
+
+ <p>The status module will also use a <code>G</code> to indicate
+ those children which are still serving requests started before
+ the graceful restart was given.</p>
+
+ <p>At present there is no way for a log rotation script using
+ <code>USR1</code> to know for certain that all children writing
+ the pre-restart log have finished. We suggest that you use a
+ suitable delay after sending the <code>USR1</code> signal
+ before you do anything with the old log. For example if most of
+ your hits take less than 10 minutes to complete for users on
+ low bandwidth links then you could wait 15 minutes before doing
+ anything with the old log.</p>
+
+ <p><strong>Note:</strong> If your configuration file has errors
+ in it when you issue a restart then your parent will not
+ restart, it will exit with an error. In the case of graceful
+ restarts it will also leave children running when it exits.
+ (These are the children which are "gracefully exiting" by
+ handling their last request.) This will cause problems if you
+ attempt to restart the server -- it will not be able to bind to
+ its listening ports. Before doing a restart, you can check the
+ syntax of the configuration files with the <code>-t</code>
+ command line argument (see <a
+ href="programs/httpd.html">httpd</a>). This still will not
+ guarantee that the server will restart correctly. To check the
+ semantics of the configuration files as well as the syntax, you
+ can try starting httpd as a non-root user. If there are no
+ errors it will attempt to open its sockets and logs and fail
+ because it's not root (or because the currently running httpd
+ already has those ports bound). If it fails for any other
+ reason then it's probably a config file error and the error
+ should be fixed before issuing the graceful restart.</p>
+
+ <h3>Restart Now</h3>
+
+ <p><strong>Signal:</strong> HUP<br />
+ <code>apachectl restart</code></p>
+
+ <p>Sending the <code>HUP</code> signal to the parent causes it
+ to kill off its children like in <code>TERM</code> but the
+ parent doesn't exit. It re-reads its configuration files, and
+ re-opens any log files. Then it spawns a new set of children
+ and continues serving hits.</p>
+
+ <p>Users of the <a href="mod/mod_status.html">status module</a>
+ will notice that the server statistics are set to zero when a
+ <code>HUP</code> is sent.</p>
+
+ <p><strong>Note:</strong> If your configuration file has errors
+ in it when you issue a restart then your parent will not
+ restart, it will exit with an error. See below for a method of
+ avoiding this.</p>
+
+ <h3>Appendix: signals and race conditions</h3>
+
+ <p>Prior to Apache 1.2b9 there were several <em>race
+ conditions</em> involving the restart and die signals (a simple
+ description of race condition is: a time-sensitive problem, as
+ in if something happens at just the wrong time it won't behave
+ as expected). For those architectures that have the "right"
+ feature set we have eliminated as many as we can. But it should
+ be noted that there still do exist race conditions on certain
+ architectures.</p>
+
+ <p>Architectures that use an on disk <a
+ href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the
+ potential to corrupt their scoreboards. This can result in the
+ "bind: Address already in use" (after <code>HUP</code>) or
+ "long lost child came home!" (after <code>USR1</code>). The
+ former is a fatal error, while the latter just causes the
+ server to lose a scoreboard slot. So it might be advisable to
+ use graceful restarts, with an occasional hard restart. These
+ problems are very difficult to work around, but fortunately
+ most architectures do not require a scoreboard file. See the <a
+ href="mod/core.html#scoreboardfile">ScoreBoardFile</a>
+ documentation for a architecture uses it.</p>
+
+ <p><code>NEXT</code> and <code>MACHTEN</code> (68k only) have
+ small race conditions which can cause a restart/die signal to
+ be lost, but should not cause the server to do anything
+ otherwise problematic.
+ <!-- they don't have sigaction, or we're not using it -djg -->
+ </p>
+
+ <p>All architectures have a small race condition in each child
+ involving the second and subsequent requests on a persistent
+ HTTP connection (KeepAlive). It may exit after reading the
+ request line but before reading any of the request headers.
+ There is a fix that was discovered too late to make 1.2. In
+ theory this isn't an issue because the KeepAlive client has to
+ expect these events because of network latencies and server
+ timeouts. In practice it doesn't seem to affect anything either
+ -- in a test case the server was restarted twenty times per
+ second and clients successfully browsed the site without
+ getting broken images or empty documents.
+ <!--#include virtual="footer.html" -->
+ </p>
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache suEXEC Support</TITLE>
-</HEAD>
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">Apache suEXEC Support</H1>
-
-<P ALIGN="LEFT">
-<OL>
- <LI><BIG><STRONG>CONTENTS</STRONG></BIG></LI>
- <LI><A HREF="#what">What is suEXEC?</A></LI>
- <LI><A HREF="#before">Before we begin.</A></LI>
- <LI><A HREF="#model">suEXEC Security Model.</A></LI>
- <LI><A HREF="#install">Configuring & Installing suEXEC</A></LI>
- <LI><A HREF="#enable">Enabling & Disabling suEXEC</A></LI>
- <LI><A HREF="#usage">Using suEXEC</A></LI>
- <LI><A HREF="#debug">Debugging suEXEC</A></LI>
- <LI><A HREF="#jabberwock">Beware the Jabberwock: Warnings &
- Examples</A></LI>
-</OL>
-</P>
-
-<H3><A NAME="what">What is suEXEC?</A></H3>
-<P ALIGN="LEFT">
-The <STRONG>suEXEC</STRONG> feature -- introduced in Apache 1.2 -- provides
-Apache users the ability to run <STRONG>CGI</STRONG> and <STRONG>SSI</STRONG>
-programs under user IDs different from the user ID of the calling web-server.
-Normally, when a CGI or SSI program executes, it runs as the same user who is
-running the web server.
-</P>
-
-<P ALIGN="LEFT">
-Used properly, this feature can reduce considerably the security risks involved
-with allowing users to develop and run private CGI or SSI programs. However,
-if suEXEC is improperly configured, it can cause any number of problems and
-possibly create new holes in your computer's security. If you aren't familiar
-with managing setuid root programs and the security issues they present, we
-highly recommend that you not consider using suEXEC.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="before">Before we begin.</A></H3>
-<P ALIGN="LEFT">
-Before jumping head-first into this document, you should be aware of the
-assumptions made on the part of the Apache Group and this document.
-</P>
-
-<P ALIGN="LEFT">
-First, it is assumed that you are using a UNIX derivate operating system that
-is capable of <STRONG>setuid</STRONG> and <STRONG>setgid</STRONG> operations.
-All command examples are given in this regard. Other platforms, if they are
-capable of supporting suEXEC, may differ in their configuration.
-</P>
-
-<P ALIGN="LEFT">
-Second, it is assumed you are familiar with some basic concepts of your
-computer's security and its administration. This involves an understanding
-of <STRONG>setuid/setgid</STRONG> operations and the various effects they
-may have on your system and its level of security.
-</P>
-
-<P ALIGN="LEFT">
-Third, it is assumed that you are using an <STRONG>unmodified</STRONG>
-version of suEXEC code. All code for suEXEC has been carefully scrutinized and
-tested by the developers as well as numerous beta testers. Every precaution
-has been taken to ensure a simple yet solidly safe base of code. Altering this
-code can cause unexpected problems and new security risks. It is
-<STRONG>highly</STRONG> recommended you not alter the suEXEC code unless you
-are well versed in the particulars of security programming and are willing to
-share your work with the Apache Group for consideration.
-</P>
-
-<P ALIGN="LEFT">
-Fourth, and last, it has been the decision of the Apache Group to
-<STRONG>NOT</STRONG> make suEXEC part of the default installation of Apache.
-To this end, suEXEC configuration requires of the administrator careful
-attention to details. After due consideration has been given to the various
-settings for suEXEC, the administrator may install suEXEC through normal
-installation methods. The values for these settings need to be carefully
-determined and specified by the administrator to properly maintain system
-security during the use of suEXEC functionality. It is through this detailed
-process that the Apache Group hopes to limit suEXEC installation only to those
-who are careful and determined enough to use it.
-</P>
-
-<P ALIGN="LEFT">
-Still with us? Yes? Good. Let's move on!
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="model">suEXEC Security Model</A></H3>
-<P ALIGN="LEFT">
-Before we begin configuring and installing suEXEC, we will first discuss
-the security model you are about to implement. By doing so, you may
-better understand what exactly is going on inside suEXEC and what precautions
-are taken to ensure your system's security.
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>suEXEC</STRONG> is based on a setuid "wrapper" program that is
-called by the main Apache web server. This wrapper is called when an HTTP
-request is made for a CGI or SSI program that the administrator has designated
-to run as a userid other than that of the main server. When such a request
-is made, Apache provides the suEXEC wrapper with the program's name and the
-user and group IDs under which the program is to execute.
-</P>
-
-<P ALIGN="LEFT">
-The wrapper then employs the following process to determine success or
-failure -- if any one of these conditions fail, the program logs the failure
-and exits with an error, otherwise it will continue:
-<OL>
- <LI><STRONG>Was the wrapper called with the proper number of
- arguments?</STRONG>
- <BLOCKQUOTE>
- The wrapper will only execute if it is given the proper number of arguments.
- The proper argument format is known to the Apache web server. If the
- wrapper
- is not receiving the proper number of arguments, it is either being hacked,
- or
- there is something wrong with the suEXEC portion of your Apache binary.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the user executing this wrapper a valid user of this
- system?</STRONG>
- <BLOCKQUOTE>
- This is to ensure that the user executing the wrapper is truly a user of the
- system.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
- <BLOCKQUOTE>
- Is this user the user allowed to run this wrapper? Only one user (the
- Apache user) is allowed to execute this program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program have an unsafe hierarchical
- reference?</STRONG>
- <BLOCKQUOTE>
- Does the target program contain a leading '/' or have a '..' backreference?
- These are not allowed; the target program must reside within the Apache
- webspace.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target user exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target group exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID
- number?</STRONG>
- <BLOCKQUOTE>
- The minimum user ID number is specified during configuration. This allows
- you
- to set the lowest possible userid that will be allowed to execute CGI/SSI
- programs. This is useful to block out "system" accounts.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI
- programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID
- number?</STRONG>
- <BLOCKQUOTE>
- The minimum group ID number is specified during configuration. This allows
- you
- to set the lowest possible groupid that will be allowed to execute CGI/SSI
- programs. This is useful to block out "system" groups.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can the wrapper successfully become the target user and
- group?</STRONG>
- <BLOCKQUOTE>
- Here is where the program becomes the target user and group via setuid and
- setgid
- calls. The group access list is also initialized with all of the groups
- of which
- the user is a member.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exist, it can't very well contain files.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
- <BLOCKQUOTE>
- If the request is for a regular portion of the server, is the requested
- directory
- within the server's document root? If the request is for a UserDir, is
- the requested
- directory within the user's document root?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to open up the directory to others; only the owner user
- may be able
- to alter this directories contents.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exists, it can't very well be executed.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone
- else?</STRONG>
- <BLOCKQUOTE>
- We don't want to give anyone other than the owner the ability to
- change the program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
- <BLOCKQUOTE>
- We do not want to execute programs that will then change our UID/GID again.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user/group the same as the program's
- user/group?</STRONG>
- <BLOCKQUOTE>
- Is the user the owner of the file?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully clean the process environment to
- ensure safe operations?</STRONG>
- <BLOCKQUOTE>
- suEXEC cleans the process' environment by establishing a safe
- execution PATH (defined
- during configuration), as well as only passing through those
- variables whose names
- are listed in the safe environment list (also created during
- configuration).
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully become the target program and
- execute?</STRONG>
- <BLOCKQUOTE>
- Here is where suEXEC ends and the target program begins.
- </BLOCKQUOTE>
- </LI>
-</OL>
-</P>
-
-<P ALIGN="LEFT">
-This is the standard operation of the the suEXEC wrapper's security model.
-It is somewhat stringent and can impose new limitations and guidelines for
-CGI/SSI design, but it was developed carefully step-by-step with security
-in mind.
-</P>
-
-<P ALIGN="LEFT">
-For more information as to how this security model can limit your possibilities
-in regards to server configuration, as well as what security risks can be
-avoided with a proper suEXEC setup, see the
-<A HREF="#jabberwock">"Beware the Jabberwock"</A>
-section of this document.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="install">Configuring & Installing suEXEC</A></H3>
-<P ALIGN="LEFT">
-Here's where we begin the fun. If you use Apache 1.2 or prefer to configure
-Apache 1.3 with the "<CODE>src/Configure</CODE>" script you have to edit
-the suEXEC header file and install the binary in its proper location
-manually. The following sections describe the configuration and installation
-for Apache 1.3 with the AutoConf-style interface (APACI).
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>APACI's suEXEC configuration options</STRONG><BR>
-<DL>
-<DT><CODE>--enable-suexec</CODE>
-<DD>This option enables the suEXEC feature which is never installed or
- activated by default. At least one --suexec-xxxxx option has to be
- provided together with the --enable-suexec option to let APACI
- accept your request for using the suEXEC feature.
-<DT><CODE>--suexec-caller=<EM>UID</EM></CODE>
-<DD>The <A HREF="mod/core.html#user">username</A> under which
- Apache normally runs.
- This is the only user allowed to execute this program.
-<DT><CODE>--suexec-docroot=<EM>DIR</EM></CODE>
-<DD>Define as the DocumentRoot set for Apache.
- This will be the only hierarchy (aside from UserDirs)
- that can be used for suEXEC behavior.
- The default directory is the --datadir value with
- the suffix "/htdocs", <EM>e.g.</EM> if you configure with
- "<CODE>--datadir=/home/apache</CODE>" the directory
- "/home/apache/htdocs" is used as document root for
- the suEXEC wrapper.
-<DT><CODE>--suexec-logfile=<EM>FILE</EM></CODE>
-<DD>This defines the filename to which all suEXEC transactions and
- errors are logged (useful for auditing and debugging purposes).
- By default the logfile is named "suexec_log" and located in your
- standard logfile directory (--logfiledir).
-<DT><CODE>--suexec-userdir=<EM>DIR</EM></CODE>
-<DD>Define to be the subdirectory under users'
- home directories where suEXEC access should
- be allowed. All executables under this directory
- will be executable by suEXEC as the user so
- they should be "safe" programs. If you are
- using a "simple" UserDir directive (ie. one
- without a "*" in it) this should be set to
- the same value. suEXEC will not work properly
- in cases where the UserDir directive points to
- a location that is not the same as the user's
- home directory as referenced in the passwd file.
- Default value is "public_html".
- <BR>
- If you have virtual hosts with a different
- UserDir for each, you will need to define them to
- all reside in one parent directory; then name that
- parent directory here. <STRONG>If this is not defined
- properly, "~userdir" cgi requests will not work!</STRONG>
-<DT><CODE>--suexec-uidmin=<EM>UID</EM></CODE>
-<DD>Define this as the lowest UID allowed to be a target user
- for suEXEC. For most systems, 500 or 100 is common.
- Default value is 100.
-<DT><CODE>--suexec-gidmin=<EM>GID</EM></CODE>
-<DD>Define this as the lowest GID allowed to be a target group
- for suEXEC. For most systems, 100 is common and therefore
- used as default value.
-<DT><CODE>--suexec-safepath=<EM>PATH</EM></CODE>
-<DD>Define a safe PATH environment to pass to CGI executables.
- Default value is "/usr/local/bin:/usr/bin:/bin".
-</DL>
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>Checking your suEXEC setup</STRONG><BR>
-Before you compile and install the suEXEC wrapper you can check
-the configuration with the --layout option.
-<BR>
-Example output:
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache suEXEC Support</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Apache suEXEC Support</h1>
+
+ <ol>
+ <li><big><strong>CONTENTS</strong></big></li>
+
+ <li><a href="#what">What is suEXEC?</a></li>
+
+ <li><a href="#before">Before we begin.</a></li>
+
+ <li><a href="#model">suEXEC Security Model.</a></li>
+
+ <li><a href="#install">Configuring & Installing
+ suEXEC</a></li>
+
+ <li><a href="#enable">Enabling & Disabling
+ suEXEC</a></li>
+
+ <li><a href="#usage">Using suEXEC</a></li>
+
+ <li><a href="#debug">Debugging suEXEC</a></li>
+
+ <li><a href="#jabberwock">Beware the Jabberwock: Warnings
+ & Examples</a></li>
+ </ol>
+ <br />
+ <br />
+
+
+ <h3><a id="what" name="what">What is suEXEC?</a></h3>
+
+ <p align="LEFT">The <strong>suEXEC</strong> feature --
+ introduced in Apache 1.2 -- provides Apache users the ability
+ to run <strong>CGI</strong> and <strong>SSI</strong> programs
+ under user IDs different from the user ID of the calling
+ web-server. Normally, when a CGI or SSI program executes, it
+ runs as the same user who is running the web server.</p>
+
+ <p align="LEFT">Used properly, this feature can reduce
+ considerably the security risks involved with allowing users to
+ develop and run private CGI or SSI programs. However, if suEXEC
+ is improperly configured, it can cause any number of problems
+ and possibly create new holes in your computer's security. If
+ you aren't familiar with managing setuid root programs and the
+ security issues they present, we highly recommend that you not
+ consider using suEXEC.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="before" name="before">Before we begin.</a></h3>
+
+ <p align="LEFT">Before jumping head-first into this document,
+ you should be aware of the assumptions made on the part of the
+ Apache Group and this document.</p>
+
+ <p align="LEFT">First, it is assumed that you are using a UNIX
+ derivate operating system that is capable of
+ <strong>setuid</strong> and <strong>setgid</strong> operations.
+ All command examples are given in this regard. Other platforms,
+ if they are capable of supporting suEXEC, may differ in their
+ configuration.</p>
+
+ <p align="LEFT">Second, it is assumed you are familiar with
+ some basic concepts of your computer's security and its
+ administration. This involves an understanding of
+ <strong>setuid/setgid</strong> operations and the various
+ effects they may have on your system and its level of
+ security.</p>
+
+ <p align="LEFT">Third, it is assumed that you are using an
+ <strong>unmodified</strong> version of suEXEC code. All code
+ for suEXEC has been carefully scrutinized and tested by the
+ developers as well as numerous beta testers. Every precaution
+ has been taken to ensure a simple yet solidly safe base of
+ code. Altering this code can cause unexpected problems and new
+ security risks. It is <strong>highly</strong> recommended you
+ not alter the suEXEC code unless you are well versed in the
+ particulars of security programming and are willing to share
+ your work with the Apache Group for consideration.</p>
+
+ <p align="LEFT">Fourth, and last, it has been the decision of
+ the Apache Group to <strong>NOT</strong> make suEXEC part of
+ the default installation of Apache. To this end, suEXEC
+ configuration requires of the administrator careful attention
+ to details. After due consideration has been given to the
+ various settings for suEXEC, the administrator may install
+ suEXEC through normal installation methods. The values for
+ these settings need to be carefully determined and specified by
+ the administrator to properly maintain system security during
+ the use of suEXEC functionality. It is through this detailed
+ process that the Apache Group hopes to limit suEXEC
+ installation only to those who are careful and determined
+ enough to use it.</p>
+
+ <p align="LEFT">Still with us? Yes? Good. Let's move on!</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="model" name="model">suEXEC Security Model</a></h3>
+
+ <p align="LEFT">Before we begin configuring and installing
+ suEXEC, we will first discuss the security model you are about
+ to implement. By doing so, you may better understand what
+ exactly is going on inside suEXEC and what precautions are
+ taken to ensure your system's security.</p>
+
+ <p align="LEFT"><strong>suEXEC</strong> is based on a setuid
+ "wrapper" program that is called by the main Apache web server.
+ This wrapper is called when an HTTP request is made for a CGI
+ or SSI program that the administrator has designated to run as
+ a userid other than that of the main server. When such a
+ request is made, Apache provides the suEXEC wrapper with the
+ program's name and the user and group IDs under which the
+ program is to execute.</p>
+
+ <p align="LEFT">The wrapper then employs the following process
+ to determine success or failure -- if any one of these
+ conditions fail, the program logs the failure and exits with an
+ error, otherwise it will continue:</p>
+
+ <ol>
+ <li>
+ <strong>Was the wrapper called with the proper number of
+ arguments?</strong>
+
+ <blockquote>
+ The wrapper will only execute if it is given the proper
+ number of arguments. The proper argument format is known
+ to the Apache web server. If the wrapper is not receiving
+ the proper number of arguments, it is either being
+ hacked, or there is something wrong with the suEXEC
+ portion of your Apache binary.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the user executing this wrapper a valid user of
+ this system?</strong>
+
+ <blockquote>
+ This is to ensure that the user executing the wrapper is
+ truly a user of the system.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is this valid user allowed to run the
+ wrapper?</strong>
+
+ <blockquote>
+ Is this user the user allowed to run this wrapper? Only
+ one user (the Apache user) is allowed to execute this
+ program.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Does the target program have an unsafe hierarchical
+ reference?</strong>
+
+ <blockquote>
+ Does the target program contain a leading '/' or have a
+ '..' backreference? These are not allowed; the target
+ program must reside within the Apache webspace.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target user name valid?</strong>
+
+ <blockquote>
+ Does the target user exist?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target group name valid?</strong>
+
+ <blockquote>
+ Does the target group exist?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target user <em>NOT</em> superuser?</strong>
+
+
+ <blockquote>
+ Presently, suEXEC does not allow 'root' to execute
+ CGI/SSI programs.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target userid <em>ABOVE</em> the minimum ID
+ number?</strong>
+
+ <blockquote>
+ The minimum user ID number is specified during
+ configuration. This allows you to set the lowest possible
+ userid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" accounts.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target group <em>NOT</em> the superuser
+ group?</strong>
+
+ <blockquote>
+ Presently, suEXEC does not allow the 'root' group to
+ execute CGI/SSI programs.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target groupid <em>ABOVE</em> the minimum ID
+ number?</strong>
+
+ <blockquote>
+ The minimum group ID number is specified during
+ configuration. This allows you to set the lowest possible
+ groupid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" groups.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Can the wrapper successfully become the target user
+ and group?</strong>
+
+ <blockquote>
+ Here is where the program becomes the target user and
+ group via setuid and setgid calls. The group access list
+ is also initialized with all of the groups of which the
+ user is a member.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Does the directory in which the program resides
+ exist?</strong>
+
+ <blockquote>
+ If it doesn't exist, it can't very well contain files.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the directory within the Apache
+ webspace?</strong>
+
+ <blockquote>
+ If the request is for a regular portion of the server, is
+ the requested directory within the server's document
+ root? If the request is for a UserDir, is the requested
+ directory within the user's document root?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the directory <em>NOT</em> writable by anyone
+ else?</strong>
+
+ <blockquote>
+ We don't want to open up the directory to others; only
+ the owner user may be able to alter this directories
+ contents.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Does the target program exist?</strong>
+
+ <blockquote>
+ If it doesn't exists, it can't very well be executed.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target program <em>NOT</em> writable by
+ anyone else?</strong>
+
+ <blockquote>
+ We don't want to give anyone other than the owner the
+ ability to change the program.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target program <em>NOT</em> setuid or
+ setgid?</strong>
+
+ <blockquote>
+ We do not want to execute programs that will then change
+ our UID/GID again.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target user/group the same as the program's
+ user/group?</strong>
+
+ <blockquote>
+ Is the user the owner of the file?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Can we successfully clean the process environment
+ to ensure safe operations?</strong>
+
+ <blockquote>
+ suEXEC cleans the process' environment by establishing a
+ safe execution PATH (defined during configuration), as
+ well as only passing through those variables whose names
+ are listed in the safe environment list (also created
+ during configuration).
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Can we successfully become the target program and
+ execute?</strong>
+
+ <blockquote>
+ Here is where suEXEC ends and the target program begins.
+ </blockquote>
+ </li>
+ </ol>
+ <br />
+ <br />
+
+
+ <p align="LEFT">This is the standard operation of the the
+ suEXEC wrapper's security model. It is somewhat stringent and
+ can impose new limitations and guidelines for CGI/SSI design,
+ but it was developed carefully step-by-step with security in
+ mind.</p>
+
+ <p align="LEFT">For more information as to how this security
+ model can limit your possibilities in regards to server
+ configuration, as well as what security risks can be avoided
+ with a proper suEXEC setup, see the <a
+ href="#jabberwock">"Beware the Jabberwock"</a> section of this
+ document.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="install" name="install">Configuring & Installing
+ suEXEC</a></h3>
+
+ <p align="LEFT">Here's where we begin the fun. If you use
+ Apache 1.2 or prefer to configure Apache 1.3 with the
+ "<code>src/Configure</code>" script you have to edit the suEXEC
+ header file and install the binary in its proper location
+ manually. The following sections describe the configuration and
+ installation for Apache 1.3 with the AutoConf-style interface
+ (APACI).</p>
+
+ <p align="LEFT"><strong>APACI's suEXEC configuration
+ options</strong><br />
+ </p>
+
+ <dl>
+ <dt><code>--enable-suexec</code></dt>
+
+ <dd>This option enables the suEXEC feature which is never
+ installed or activated by default. At least one
+ --suexec-xxxxx option has to be provided together with the
+ --enable-suexec option to let APACI accept your request for
+ using the suEXEC feature.</dd>
+
+ <dt><code>--suexec-caller=<em>UID</em></code></dt>
+
+ <dd>The <a href="mod/core.html#user">username</a> under which
+ Apache normally runs. This is the only user allowed to
+ execute this program.</dd>
+
+ <dt><code>--suexec-docroot=<em>DIR</em></code></dt>
+
+ <dd>Define as the DocumentRoot set for Apache. This will be
+ the only hierarchy (aside from UserDirs) that can be used for
+ suEXEC behavior. The default directory is the --datadir value
+ with the suffix "/htdocs", <em>e.g.</em> if you configure
+ with "<code>--datadir=/home/apache</code>" the directory
+ "/home/apache/htdocs" is used as document root for the suEXEC
+ wrapper.</dd>
+
+ <dt><code>--suexec-logfile=<em>FILE</em></code></dt>
+
+ <dd>This defines the filename to which all suEXEC
+ transactions and errors are logged (useful for auditing and
+ debugging purposes). By default the logfile is named
+ "suexec_log" and located in your standard logfile directory
+ (--logfiledir).</dd>
+
+ <dt><code>--suexec-userdir=<em>DIR</em></code></dt>
+
+ <dd>Define to be the subdirectory under users' home
+ directories where suEXEC access should be allowed. All
+ executables under this directory will be executable by suEXEC
+ as the user so they should be "safe" programs. If you are
+ using a "simple" UserDir directive (ie. one without a "*" in
+ it) this should be set to the same value. suEXEC will not
+ work properly in cases where the UserDir directive points to
+ a location that is not the same as the user's home directory
+ as referenced in the passwd file. Default value is
+ "public_html".<br />
+ If you have virtual hosts with a different UserDir for each,
+ you will need to define them to all reside in one parent
+ directory; then name that parent directory here. <strong>If
+ this is not defined properly, "~userdir" cgi requests will
+ not work!</strong></dd>
+
+ <dt><code>--suexec-uidmin=<em>UID</em></code></dt>
+
+ <dd>Define this as the lowest UID allowed to be a target user
+ for suEXEC. For most systems, 500 or 100 is common. Default
+ value is 100.</dd>
+
+ <dt><code>--suexec-gidmin=<em>GID</em></code></dt>
+
+ <dd>Define this as the lowest GID allowed to be a target
+ group for suEXEC. For most systems, 100 is common and
+ therefore used as default value.</dd>
+
+ <dt><code>--suexec-safepath=<em>PATH</em></code></dt>
+
+ <dd>Define a safe PATH environment to pass to CGI
+ executables. Default value is
+ "/usr/local/bin:/usr/bin:/bin".</dd>
+ </dl>
+ <br />
+ <br />
+
+
+ <p align="LEFT"><strong>Checking your suEXEC
+ setup</strong><br />
+ Before you compile and install the suEXEC wrapper you can
+ check the configuration with the --layout option.<br />
+ Example output:</p>
+<pre>
suEXEC setup:
suexec binary: /usr/local/apache/sbin/suexec
document root: /usr/local/apache/share/htdocs
caller ID: www
minimum user ID: 100
minimum group ID: 100
-</PRE>
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>Compiling and installing the suEXEC wrapper</STRONG><BR>
-If you have enabled the suEXEC feature with the --enable-suexec option
-the suexec binary (together with Apache itself) is automatically built
-if you execute the command "make".
-<BR>
-After all components have been built you can execute the command
-"make install" to install them.
-The binary image "suexec" is installed in the directory defined by
-the --sbindir option. Default location is "/usr/local/apache/sbin/suexec".
-<BR>
-Please note that you need <STRONG><EM>root privileges</EM></STRONG> for
-the installation step. In order for the wrapper to set the user ID, it
-must be installed as owner <CODE><EM>root</EM></CODE> and must have the
-setuserid execution bit set for file modes.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="enable">Enabling & Disabling suEXEC</A></H3>
-<P ALIGN="LEFT">
-Upon startup of Apache, it looks for the file "suexec" in the "sbin"
-directory (default is "/usr/local/apache/sbin/suexec").
-If Apache finds a properly configured suEXEC wrapper, it will print
-the following message to the error log:
-<PRE>
- [notice] suEXEC mechanism enabled (wrapper: <EM>/path/to/suexec</EM>)
-</PRE>
-If you don't see this message at server startup, the server is most
-likely not finding the wrapper program where it expects it, or the
-executable is not installed <EM>setuid root</EM>.
-<BR>
-If you want to enable the suEXEC mechanism for the first time
-and an Apache server is already running you must kill and restart Apache.
-Restarting it with a simple HUP or USR1 signal will not be enough.
-<BR>
-If you want to disable suEXEC you should kill and restart Apache after
-you have removed the "suexec" file.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="usage">Using suEXEC</A></H3>
-<P ALIGN="LEFT">
-<STRONG>Virtual Hosts:</STRONG><BR>
-One way to use the suEXEC wrapper is through the
-<A HREF="mod/core.html#user">User</A> and
-<A HREF="mod/core.html#group">Group</A> directives in
-<A HREF="mod/core.html#virtualhost">VirtualHost</A>
-definitions. By setting these directives to values different from the
-main server user ID, all requests for CGI resources will be executed as
-the <EM>User</EM> and <EM>Group</EM> defined for that
-<CODE><VirtualHost></CODE>. If only one or
-neither of these directives are specified for a
-<CODE><VirtualHost></CODE> then the main
-server userid is assumed.
-<P>
-<STRONG>User directories:</STRONG><BR>
-The suEXEC wrapper can also be used to execute CGI programs as
-the user to which the request is being directed. This is accomplished by
-using the "<STRONG><CODE>~</CODE></STRONG>" character prefixing the user
-ID for whom execution is desired.
-The only requirement needed for this feature to work is for CGI
-execution to be enabled for the user and that the script must meet the
-scrutiny of the <A HREF="#model">security checks</A> above.
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="debug">Debugging suEXEC</A></H3>
-<P ALIGN="LEFT">
-The suEXEC wrapper will write log information to the file defined
-with the --suexec-logfile option as indicated above. If you feel you have
-configured and installed the wrapper properly, have a look at this log
-and the error_log for the server to see where you may have gone astray.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3>
-<A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A>
-</H3>
-<P ALIGN="LEFT">
-<STRONG>NOTE!</STRONG> This section may not be complete. For the latest
-revision of this section of the documentation, see the Apache Group's
-<A HREF="http://www.apache.org/docs/suexec.html">Online Documentation</A>
-version.
-</P>
-
-<P ALIGN="LEFT">
-There are a few points of interest regarding the wrapper that can cause
-limitations on server setup. Please review these before submitting any
-"bugs" regarding suEXEC.
-<UL>
- <LI><STRONG>suEXEC Points Of Interest</STRONG></LI>
- <LI>Hierarchy limitations
- <BLOCKQUOTE>
- For security and efficiency reasons, all suexec requests must
- remain within either a top-level document root for virtual
- host requests, or one top-level personal document root for
- userdir requests. For example, if you have four VirtualHosts
- configured, you would need to structure all of your VHosts'
- document roots off of one main Apache document hierarchy to
- take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
- </BLOCKQUOTE>
- </LI>
- <LI>suEXEC's PATH environment variable
- <BLOCKQUOTE>
- This can be a dangerous thing to change. Make certain every
- path you include in this define is a <STRONG>trusted</STRONG>
- directory. You don't want to open people up to having someone
- from across the world running a trojan horse on them.
- </BLOCKQUOTE>
- </LI>
- <LI>Altering the suEXEC code
- <BLOCKQUOTE>
- Again, this can cause <STRONG>Big Trouble</STRONG> if you try
- this without knowing what you are doing. Stay away from it
- if at all possible.
- </BLOCKQUOTE>
- </LI>
-</UL>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ <br />
+ <br />
+
+
+ <p align="LEFT"><strong>Compiling and installing the suEXEC
+ wrapper</strong><br />
+ If you have enabled the suEXEC feature with the
+ --enable-suexec option the suexec binary (together with Apache
+ itself) is automatically built if you execute the command
+ "make".<br />
+ After all components have been built you can execute the
+ command "make install" to install them. The binary image
+ "suexec" is installed in the directory defined by the --sbindir
+ option. Default location is
+ "/usr/local/apache/sbin/suexec".<br />
+ Please note that you need <strong><em>root
+ privileges</em></strong> for the installation step. In order
+ for the wrapper to set the user ID, it must be installed as
+ owner <code><em>root</em></code> and must have the setuserid
+ execution bit set for file modes.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="enable" name="enable">Enabling & Disabling
+ suEXEC</a></h3>
+
+ <p align="LEFT">Upon startup of Apache, it looks for the file
+ "suexec" in the "sbin" directory (default is
+ "/usr/local/apache/sbin/suexec"). If Apache finds a properly
+ configured suEXEC wrapper, it will print the following message
+ to the error log:</p>
+<pre>
+ [notice] suEXEC mechanism enabled (wrapper: <em>/path/to/suexec</em>)
+</pre>
+ If you don't see this message at server startup, the server is
+ most likely not finding the wrapper program where it expects
+ it, or the executable is not installed <em>setuid root</em>.
+ <br />
+ If you want to enable the suEXEC mechanism for the first time
+ and an Apache server is already running you must kill and
+ restart Apache. Restarting it with a simple HUP or USR1 signal
+ will not be enough. <br />
+ If you want to disable suEXEC you should kill and restart
+ Apache after you have removed the "suexec" file. <br />
+ <br />
+
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="usage" name="usage">Using suEXEC</a></h3>
+
+ <p align="LEFT"><strong>Virtual Hosts:</strong><br />
+ One way to use the suEXEC wrapper is through the <a
+ href="mod/core.html#user">User</a> and <a
+ href="mod/core.html#group">Group</a> directives in <a
+ href="mod/core.html#virtualhost">VirtualHost</a> definitions.
+ By setting these directives to values different from the main
+ server user ID, all requests for CGI resources will be executed
+ as the <em>User</em> and <em>Group</em> defined for that
+ <code><VirtualHost></code>. If only one or neither of
+ these directives are specified for a
+ <code><VirtualHost></code> then the main server userid is
+ assumed.</p>
+
+ <p><strong>User directories:</strong><br />
+ The suEXEC wrapper can also be used to execute CGI programs as
+ the user to which the request is being directed. This is
+ accomplished by using the "<strong><code>~</code></strong>"
+ character prefixing the user ID for whom execution is desired.
+ The only requirement needed for this feature to work is for CGI
+ execution to be enabled for the user and that the script must
+ meet the scrutiny of the <a href="#model">security checks</a>
+ above.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="debug" name="debug">Debugging suEXEC</a></h3>
+
+ <p align="LEFT">The suEXEC wrapper will write log information
+ to the file defined with the --suexec-logfile option as
+ indicated above. If you feel you have configured and installed
+ the wrapper properly, have a look at this log and the error_log
+ for the server to see where you may have gone astray.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="jabberwock" name="jabberwock">Beware the Jabberwock:
+ Warnings & Examples</a></h3>
+
+ <p align="LEFT"><strong>NOTE!</strong> This section may not be
+ complete. For the latest revision of this section of the
+ documentation, see the Apache Group's <a
+ href="http://www.apache.org/docs/suexec.html">Online
+ Documentation</a> version.</p>
+
+ <p align="LEFT">There are a few points of interest regarding
+ the wrapper that can cause limitations on server setup. Please
+ review these before submitting any "bugs" regarding suEXEC.</p>
+
+ <ul>
+ <li><strong>suEXEC Points Of Interest</strong></li>
+
+ <li>
+ Hierarchy limitations
+
+ <blockquote>
+ For security and efficiency reasons, all suexec requests
+ must remain within either a top-level document root for
+ virtual host requests, or one top-level personal document
+ root for userdir requests. For example, if you have four
+ VirtualHosts configured, you would need to structure all
+ of your VHosts' document roots off of one main Apache
+ document hierarchy to take advantage of suEXEC for
+ VirtualHosts. (Example forthcoming.)
+ </blockquote>
+ </li>
+
+ <li>
+ suEXEC's PATH environment variable
+
+ <blockquote>
+ This can be a dangerous thing to change. Make certain
+ every path you include in this define is a
+ <strong>trusted</strong> directory. You don't want to
+ open people up to having someone from across the world
+ running a trojan horse on them.
+ </blockquote>
+ </li>
+
+ <li>
+ Altering the suEXEC code
+
+ <blockquote>
+ Again, this can cause <strong>Big Trouble</strong> if you
+ try this without knowing what you are doing. Stay away
+ from it if at all possible.
+ </blockquote>
+ </li>
+ </ul>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache suEXEC Support</TITLE>
-</HEAD>
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">Apache suEXEC Support</H1>
-
-<P ALIGN="LEFT">
-<OL>
- <LI><BIG><STRONG>CONTENTS</STRONG></BIG></LI>
- <LI><A HREF="#what">What is suEXEC?</A></LI>
- <LI><A HREF="#before">Before we begin.</A></LI>
- <LI><A HREF="#model">suEXEC Security Model.</A></LI>
- <LI><A HREF="#install">Configuring & Installing suEXEC</A></LI>
- <LI><A HREF="#enable">Enabling & Disabling suEXEC</A></LI>
- <LI><A HREF="#usage">Using suEXEC</A></LI>
- <LI><A HREF="#debug">Debugging suEXEC</A></LI>
- <LI><A HREF="#jabberwock">Beware the Jabberwock: Warnings &
- Examples</A></LI>
-</OL>
-</P>
-
-<H3><A NAME="what">What is suEXEC?</A></H3>
-<P ALIGN="LEFT">
-The <STRONG>suEXEC</STRONG> feature -- introduced in Apache 1.2 -- provides
-Apache users the ability to run <STRONG>CGI</STRONG> and <STRONG>SSI</STRONG>
-programs under user IDs different from the user ID of the calling web-server.
-Normally, when a CGI or SSI program executes, it runs as the same user who is
-running the web server.
-</P>
-
-<P ALIGN="LEFT">
-Used properly, this feature can reduce considerably the security risks involved
-with allowing users to develop and run private CGI or SSI programs. However,
-if suEXEC is improperly configured, it can cause any number of problems and
-possibly create new holes in your computer's security. If you aren't familiar
-with managing setuid root programs and the security issues they present, we
-highly recommend that you not consider using suEXEC.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="before">Before we begin.</A></H3>
-<P ALIGN="LEFT">
-Before jumping head-first into this document, you should be aware of the
-assumptions made on the part of the Apache Group and this document.
-</P>
-
-<P ALIGN="LEFT">
-First, it is assumed that you are using a UNIX derivate operating system that
-is capable of <STRONG>setuid</STRONG> and <STRONG>setgid</STRONG> operations.
-All command examples are given in this regard. Other platforms, if they are
-capable of supporting suEXEC, may differ in their configuration.
-</P>
-
-<P ALIGN="LEFT">
-Second, it is assumed you are familiar with some basic concepts of your
-computer's security and its administration. This involves an understanding
-of <STRONG>setuid/setgid</STRONG> operations and the various effects they
-may have on your system and its level of security.
-</P>
-
-<P ALIGN="LEFT">
-Third, it is assumed that you are using an <STRONG>unmodified</STRONG>
-version of suEXEC code. All code for suEXEC has been carefully scrutinized and
-tested by the developers as well as numerous beta testers. Every precaution
-has been taken to ensure a simple yet solidly safe base of code. Altering this
-code can cause unexpected problems and new security risks. It is
-<STRONG>highly</STRONG> recommended you not alter the suEXEC code unless you
-are well versed in the particulars of security programming and are willing to
-share your work with the Apache Group for consideration.
-</P>
-
-<P ALIGN="LEFT">
-Fourth, and last, it has been the decision of the Apache Group to
-<STRONG>NOT</STRONG> make suEXEC part of the default installation of Apache.
-To this end, suEXEC configuration requires of the administrator careful
-attention to details. After due consideration has been given to the various
-settings for suEXEC, the administrator may install suEXEC through normal
-installation methods. The values for these settings need to be carefully
-determined and specified by the administrator to properly maintain system
-security during the use of suEXEC functionality. It is through this detailed
-process that the Apache Group hopes to limit suEXEC installation only to those
-who are careful and determined enough to use it.
-</P>
-
-<P ALIGN="LEFT">
-Still with us? Yes? Good. Let's move on!
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="model">suEXEC Security Model</A></H3>
-<P ALIGN="LEFT">
-Before we begin configuring and installing suEXEC, we will first discuss
-the security model you are about to implement. By doing so, you may
-better understand what exactly is going on inside suEXEC and what precautions
-are taken to ensure your system's security.
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>suEXEC</STRONG> is based on a setuid "wrapper" program that is
-called by the main Apache web server. This wrapper is called when an HTTP
-request is made for a CGI or SSI program that the administrator has designated
-to run as a userid other than that of the main server. When such a request
-is made, Apache provides the suEXEC wrapper with the program's name and the
-user and group IDs under which the program is to execute.
-</P>
-
-<P ALIGN="LEFT">
-The wrapper then employs the following process to determine success or
-failure -- if any one of these conditions fail, the program logs the failure
-and exits with an error, otherwise it will continue:
-<OL>
- <LI><STRONG>Was the wrapper called with the proper number of
- arguments?</STRONG>
- <BLOCKQUOTE>
- The wrapper will only execute if it is given the proper number of arguments.
- The proper argument format is known to the Apache web server. If the
- wrapper
- is not receiving the proper number of arguments, it is either being hacked,
- or
- there is something wrong with the suEXEC portion of your Apache binary.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the user executing this wrapper a valid user of this
- system?</STRONG>
- <BLOCKQUOTE>
- This is to ensure that the user executing the wrapper is truly a user of the
- system.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
- <BLOCKQUOTE>
- Is this user the user allowed to run this wrapper? Only one user (the
- Apache user) is allowed to execute this program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program have an unsafe hierarchical
- reference?</STRONG>
- <BLOCKQUOTE>
- Does the target program contain a leading '/' or have a '..' backreference?
- These are not allowed; the target program must reside within the Apache
- webspace.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target user exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target group exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID
- number?</STRONG>
- <BLOCKQUOTE>
- The minimum user ID number is specified during configuration. This allows
- you
- to set the lowest possible userid that will be allowed to execute CGI/SSI
- programs. This is useful to block out "system" accounts.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI
- programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID
- number?</STRONG>
- <BLOCKQUOTE>
- The minimum group ID number is specified during configuration. This allows
- you
- to set the lowest possible groupid that will be allowed to execute CGI/SSI
- programs. This is useful to block out "system" groups.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can the wrapper successfully become the target user and
- group?</STRONG>
- <BLOCKQUOTE>
- Here is where the program becomes the target user and group via setuid and
- setgid
- calls. The group access list is also initialized with all of the groups
- of which
- the user is a member.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exist, it can't very well contain files.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
- <BLOCKQUOTE>
- If the request is for a regular portion of the server, is the requested
- directory
- within the server's document root? If the request is for a UserDir, is
- the requested
- directory within the user's document root?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to open up the directory to others; only the owner user
- may be able
- to alter this directories contents.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exists, it can't very well be executed.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone
- else?</STRONG>
- <BLOCKQUOTE>
- We don't want to give anyone other than the owner the ability to
- change the program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
- <BLOCKQUOTE>
- We do not want to execute programs that will then change our UID/GID again.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user/group the same as the program's
- user/group?</STRONG>
- <BLOCKQUOTE>
- Is the user the owner of the file?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully clean the process environment to
- ensure safe operations?</STRONG>
- <BLOCKQUOTE>
- suEXEC cleans the process' environment by establishing a safe
- execution PATH (defined
- during configuration), as well as only passing through those
- variables whose names
- are listed in the safe environment list (also created during
- configuration).
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully become the target program and
- execute?</STRONG>
- <BLOCKQUOTE>
- Here is where suEXEC ends and the target program begins.
- </BLOCKQUOTE>
- </LI>
-</OL>
-</P>
-
-<P ALIGN="LEFT">
-This is the standard operation of the the suEXEC wrapper's security model.
-It is somewhat stringent and can impose new limitations and guidelines for
-CGI/SSI design, but it was developed carefully step-by-step with security
-in mind.
-</P>
-
-<P ALIGN="LEFT">
-For more information as to how this security model can limit your possibilities
-in regards to server configuration, as well as what security risks can be
-avoided with a proper suEXEC setup, see the
-<A HREF="#jabberwock">"Beware the Jabberwock"</A>
-section of this document.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="install">Configuring & Installing suEXEC</A></H3>
-<P ALIGN="LEFT">
-Here's where we begin the fun. If you use Apache 1.2 or prefer to configure
-Apache 1.3 with the "<CODE>src/Configure</CODE>" script you have to edit
-the suEXEC header file and install the binary in its proper location
-manually. The following sections describe the configuration and installation
-for Apache 1.3 with the AutoConf-style interface (APACI).
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>APACI's suEXEC configuration options</STRONG><BR>
-<DL>
-<DT><CODE>--enable-suexec</CODE>
-<DD>This option enables the suEXEC feature which is never installed or
- activated by default. At least one --suexec-xxxxx option has to be
- provided together with the --enable-suexec option to let APACI
- accept your request for using the suEXEC feature.
-<DT><CODE>--suexec-caller=<EM>UID</EM></CODE>
-<DD>The <A HREF="mod/core.html#user">username</A> under which
- Apache normally runs.
- This is the only user allowed to execute this program.
-<DT><CODE>--suexec-docroot=<EM>DIR</EM></CODE>
-<DD>Define as the DocumentRoot set for Apache.
- This will be the only hierarchy (aside from UserDirs)
- that can be used for suEXEC behavior.
- The default directory is the --datadir value with
- the suffix "/htdocs", <EM>e.g.</EM> if you configure with
- "<CODE>--datadir=/home/apache</CODE>" the directory
- "/home/apache/htdocs" is used as document root for
- the suEXEC wrapper.
-<DT><CODE>--suexec-logfile=<EM>FILE</EM></CODE>
-<DD>This defines the filename to which all suEXEC transactions and
- errors are logged (useful for auditing and debugging purposes).
- By default the logfile is named "suexec_log" and located in your
- standard logfile directory (--logfiledir).
-<DT><CODE>--suexec-userdir=<EM>DIR</EM></CODE>
-<DD>Define to be the subdirectory under users'
- home directories where suEXEC access should
- be allowed. All executables under this directory
- will be executable by suEXEC as the user so
- they should be "safe" programs. If you are
- using a "simple" UserDir directive (ie. one
- without a "*" in it) this should be set to
- the same value. suEXEC will not work properly
- in cases where the UserDir directive points to
- a location that is not the same as the user's
- home directory as referenced in the passwd file.
- Default value is "public_html".
- <BR>
- If you have virtual hosts with a different
- UserDir for each, you will need to define them to
- all reside in one parent directory; then name that
- parent directory here. <STRONG>If this is not defined
- properly, "~userdir" cgi requests will not work!</STRONG>
-<DT><CODE>--suexec-uidmin=<EM>UID</EM></CODE>
-<DD>Define this as the lowest UID allowed to be a target user
- for suEXEC. For most systems, 500 or 100 is common.
- Default value is 100.
-<DT><CODE>--suexec-gidmin=<EM>GID</EM></CODE>
-<DD>Define this as the lowest GID allowed to be a target group
- for suEXEC. For most systems, 100 is common and therefore
- used as default value.
-<DT><CODE>--suexec-safepath=<EM>PATH</EM></CODE>
-<DD>Define a safe PATH environment to pass to CGI executables.
- Default value is "/usr/local/bin:/usr/bin:/bin".
-</DL>
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>Checking your suEXEC setup</STRONG><BR>
-Before you compile and install the suEXEC wrapper you can check
-the configuration with the --layout option.
-<BR>
-Example output:
-<PRE>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Apache suEXEC Support</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Apache suEXEC Support</h1>
+
+ <ol>
+ <li><big><strong>CONTENTS</strong></big></li>
+
+ <li><a href="#what">What is suEXEC?</a></li>
+
+ <li><a href="#before">Before we begin.</a></li>
+
+ <li><a href="#model">suEXEC Security Model.</a></li>
+
+ <li><a href="#install">Configuring & Installing
+ suEXEC</a></li>
+
+ <li><a href="#enable">Enabling & Disabling
+ suEXEC</a></li>
+
+ <li><a href="#usage">Using suEXEC</a></li>
+
+ <li><a href="#debug">Debugging suEXEC</a></li>
+
+ <li><a href="#jabberwock">Beware the Jabberwock: Warnings
+ & Examples</a></li>
+ </ol>
+ <br />
+ <br />
+
+
+ <h3><a id="what" name="what">What is suEXEC?</a></h3>
+
+ <p align="LEFT">The <strong>suEXEC</strong> feature --
+ introduced in Apache 1.2 -- provides Apache users the ability
+ to run <strong>CGI</strong> and <strong>SSI</strong> programs
+ under user IDs different from the user ID of the calling
+ web-server. Normally, when a CGI or SSI program executes, it
+ runs as the same user who is running the web server.</p>
+
+ <p align="LEFT">Used properly, this feature can reduce
+ considerably the security risks involved with allowing users to
+ develop and run private CGI or SSI programs. However, if suEXEC
+ is improperly configured, it can cause any number of problems
+ and possibly create new holes in your computer's security. If
+ you aren't familiar with managing setuid root programs and the
+ security issues they present, we highly recommend that you not
+ consider using suEXEC.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="before" name="before">Before we begin.</a></h3>
+
+ <p align="LEFT">Before jumping head-first into this document,
+ you should be aware of the assumptions made on the part of the
+ Apache Group and this document.</p>
+
+ <p align="LEFT">First, it is assumed that you are using a UNIX
+ derivate operating system that is capable of
+ <strong>setuid</strong> and <strong>setgid</strong> operations.
+ All command examples are given in this regard. Other platforms,
+ if they are capable of supporting suEXEC, may differ in their
+ configuration.</p>
+
+ <p align="LEFT">Second, it is assumed you are familiar with
+ some basic concepts of your computer's security and its
+ administration. This involves an understanding of
+ <strong>setuid/setgid</strong> operations and the various
+ effects they may have on your system and its level of
+ security.</p>
+
+ <p align="LEFT">Third, it is assumed that you are using an
+ <strong>unmodified</strong> version of suEXEC code. All code
+ for suEXEC has been carefully scrutinized and tested by the
+ developers as well as numerous beta testers. Every precaution
+ has been taken to ensure a simple yet solidly safe base of
+ code. Altering this code can cause unexpected problems and new
+ security risks. It is <strong>highly</strong> recommended you
+ not alter the suEXEC code unless you are well versed in the
+ particulars of security programming and are willing to share
+ your work with the Apache Group for consideration.</p>
+
+ <p align="LEFT">Fourth, and last, it has been the decision of
+ the Apache Group to <strong>NOT</strong> make suEXEC part of
+ the default installation of Apache. To this end, suEXEC
+ configuration requires of the administrator careful attention
+ to details. After due consideration has been given to the
+ various settings for suEXEC, the administrator may install
+ suEXEC through normal installation methods. The values for
+ these settings need to be carefully determined and specified by
+ the administrator to properly maintain system security during
+ the use of suEXEC functionality. It is through this detailed
+ process that the Apache Group hopes to limit suEXEC
+ installation only to those who are careful and determined
+ enough to use it.</p>
+
+ <p align="LEFT">Still with us? Yes? Good. Let's move on!</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="model" name="model">suEXEC Security Model</a></h3>
+
+ <p align="LEFT">Before we begin configuring and installing
+ suEXEC, we will first discuss the security model you are about
+ to implement. By doing so, you may better understand what
+ exactly is going on inside suEXEC and what precautions are
+ taken to ensure your system's security.</p>
+
+ <p align="LEFT"><strong>suEXEC</strong> is based on a setuid
+ "wrapper" program that is called by the main Apache web server.
+ This wrapper is called when an HTTP request is made for a CGI
+ or SSI program that the administrator has designated to run as
+ a userid other than that of the main server. When such a
+ request is made, Apache provides the suEXEC wrapper with the
+ program's name and the user and group IDs under which the
+ program is to execute.</p>
+
+ <p align="LEFT">The wrapper then employs the following process
+ to determine success or failure -- if any one of these
+ conditions fail, the program logs the failure and exits with an
+ error, otherwise it will continue:</p>
+
+ <ol>
+ <li>
+ <strong>Was the wrapper called with the proper number of
+ arguments?</strong>
+
+ <blockquote>
+ The wrapper will only execute if it is given the proper
+ number of arguments. The proper argument format is known
+ to the Apache web server. If the wrapper is not receiving
+ the proper number of arguments, it is either being
+ hacked, or there is something wrong with the suEXEC
+ portion of your Apache binary.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the user executing this wrapper a valid user of
+ this system?</strong>
+
+ <blockquote>
+ This is to ensure that the user executing the wrapper is
+ truly a user of the system.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is this valid user allowed to run the
+ wrapper?</strong>
+
+ <blockquote>
+ Is this user the user allowed to run this wrapper? Only
+ one user (the Apache user) is allowed to execute this
+ program.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Does the target program have an unsafe hierarchical
+ reference?</strong>
+
+ <blockquote>
+ Does the target program contain a leading '/' or have a
+ '..' backreference? These are not allowed; the target
+ program must reside within the Apache webspace.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target user name valid?</strong>
+
+ <blockquote>
+ Does the target user exist?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target group name valid?</strong>
+
+ <blockquote>
+ Does the target group exist?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target user <em>NOT</em> superuser?</strong>
+
+
+ <blockquote>
+ Presently, suEXEC does not allow 'root' to execute
+ CGI/SSI programs.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target userid <em>ABOVE</em> the minimum ID
+ number?</strong>
+
+ <blockquote>
+ The minimum user ID number is specified during
+ configuration. This allows you to set the lowest possible
+ userid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" accounts.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target group <em>NOT</em> the superuser
+ group?</strong>
+
+ <blockquote>
+ Presently, suEXEC does not allow the 'root' group to
+ execute CGI/SSI programs.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target groupid <em>ABOVE</em> the minimum ID
+ number?</strong>
+
+ <blockquote>
+ The minimum group ID number is specified during
+ configuration. This allows you to set the lowest possible
+ groupid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" groups.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Can the wrapper successfully become the target user
+ and group?</strong>
+
+ <blockquote>
+ Here is where the program becomes the target user and
+ group via setuid and setgid calls. The group access list
+ is also initialized with all of the groups of which the
+ user is a member.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Does the directory in which the program resides
+ exist?</strong>
+
+ <blockquote>
+ If it doesn't exist, it can't very well contain files.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the directory within the Apache
+ webspace?</strong>
+
+ <blockquote>
+ If the request is for a regular portion of the server, is
+ the requested directory within the server's document
+ root? If the request is for a UserDir, is the requested
+ directory within the user's document root?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the directory <em>NOT</em> writable by anyone
+ else?</strong>
+
+ <blockquote>
+ We don't want to open up the directory to others; only
+ the owner user may be able to alter this directories
+ contents.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Does the target program exist?</strong>
+
+ <blockquote>
+ If it doesn't exists, it can't very well be executed.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target program <em>NOT</em> writable by
+ anyone else?</strong>
+
+ <blockquote>
+ We don't want to give anyone other than the owner the
+ ability to change the program.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target program <em>NOT</em> setuid or
+ setgid?</strong>
+
+ <blockquote>
+ We do not want to execute programs that will then change
+ our UID/GID again.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Is the target user/group the same as the program's
+ user/group?</strong>
+
+ <blockquote>
+ Is the user the owner of the file?
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Can we successfully clean the process environment
+ to ensure safe operations?</strong>
+
+ <blockquote>
+ suEXEC cleans the process' environment by establishing a
+ safe execution PATH (defined during configuration), as
+ well as only passing through those variables whose names
+ are listed in the safe environment list (also created
+ during configuration).
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Can we successfully become the target program and
+ execute?</strong>
+
+ <blockquote>
+ Here is where suEXEC ends and the target program begins.
+ </blockquote>
+ </li>
+ </ol>
+ <br />
+ <br />
+
+
+ <p align="LEFT">This is the standard operation of the the
+ suEXEC wrapper's security model. It is somewhat stringent and
+ can impose new limitations and guidelines for CGI/SSI design,
+ but it was developed carefully step-by-step with security in
+ mind.</p>
+
+ <p align="LEFT">For more information as to how this security
+ model can limit your possibilities in regards to server
+ configuration, as well as what security risks can be avoided
+ with a proper suEXEC setup, see the <a
+ href="#jabberwock">"Beware the Jabberwock"</a> section of this
+ document.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="install" name="install">Configuring & Installing
+ suEXEC</a></h3>
+
+ <p align="LEFT">Here's where we begin the fun. If you use
+ Apache 1.2 or prefer to configure Apache 1.3 with the
+ "<code>src/Configure</code>" script you have to edit the suEXEC
+ header file and install the binary in its proper location
+ manually. The following sections describe the configuration and
+ installation for Apache 1.3 with the AutoConf-style interface
+ (APACI).</p>
+
+ <p align="LEFT"><strong>APACI's suEXEC configuration
+ options</strong><br />
+ </p>
+
+ <dl>
+ <dt><code>--enable-suexec</code></dt>
+
+ <dd>This option enables the suEXEC feature which is never
+ installed or activated by default. At least one
+ --suexec-xxxxx option has to be provided together with the
+ --enable-suexec option to let APACI accept your request for
+ using the suEXEC feature.</dd>
+
+ <dt><code>--suexec-caller=<em>UID</em></code></dt>
+
+ <dd>The <a href="mod/core.html#user">username</a> under which
+ Apache normally runs. This is the only user allowed to
+ execute this program.</dd>
+
+ <dt><code>--suexec-docroot=<em>DIR</em></code></dt>
+
+ <dd>Define as the DocumentRoot set for Apache. This will be
+ the only hierarchy (aside from UserDirs) that can be used for
+ suEXEC behavior. The default directory is the --datadir value
+ with the suffix "/htdocs", <em>e.g.</em> if you configure
+ with "<code>--datadir=/home/apache</code>" the directory
+ "/home/apache/htdocs" is used as document root for the suEXEC
+ wrapper.</dd>
+
+ <dt><code>--suexec-logfile=<em>FILE</em></code></dt>
+
+ <dd>This defines the filename to which all suEXEC
+ transactions and errors are logged (useful for auditing and
+ debugging purposes). By default the logfile is named
+ "suexec_log" and located in your standard logfile directory
+ (--logfiledir).</dd>
+
+ <dt><code>--suexec-userdir=<em>DIR</em></code></dt>
+
+ <dd>Define to be the subdirectory under users' home
+ directories where suEXEC access should be allowed. All
+ executables under this directory will be executable by suEXEC
+ as the user so they should be "safe" programs. If you are
+ using a "simple" UserDir directive (ie. one without a "*" in
+ it) this should be set to the same value. suEXEC will not
+ work properly in cases where the UserDir directive points to
+ a location that is not the same as the user's home directory
+ as referenced in the passwd file. Default value is
+ "public_html".<br />
+ If you have virtual hosts with a different UserDir for each,
+ you will need to define them to all reside in one parent
+ directory; then name that parent directory here. <strong>If
+ this is not defined properly, "~userdir" cgi requests will
+ not work!</strong></dd>
+
+ <dt><code>--suexec-uidmin=<em>UID</em></code></dt>
+
+ <dd>Define this as the lowest UID allowed to be a target user
+ for suEXEC. For most systems, 500 or 100 is common. Default
+ value is 100.</dd>
+
+ <dt><code>--suexec-gidmin=<em>GID</em></code></dt>
+
+ <dd>Define this as the lowest GID allowed to be a target
+ group for suEXEC. For most systems, 100 is common and
+ therefore used as default value.</dd>
+
+ <dt><code>--suexec-safepath=<em>PATH</em></code></dt>
+
+ <dd>Define a safe PATH environment to pass to CGI
+ executables. Default value is
+ "/usr/local/bin:/usr/bin:/bin".</dd>
+ </dl>
+ <br />
+ <br />
+
+
+ <p align="LEFT"><strong>Checking your suEXEC
+ setup</strong><br />
+ Before you compile and install the suEXEC wrapper you can
+ check the configuration with the --layout option.<br />
+ Example output:</p>
+<pre>
suEXEC setup:
suexec binary: /usr/local/apache/sbin/suexec
document root: /usr/local/apache/share/htdocs
caller ID: www
minimum user ID: 100
minimum group ID: 100
-</PRE>
-</P>
-
-<P ALIGN="LEFT">
-<STRONG>Compiling and installing the suEXEC wrapper</STRONG><BR>
-If you have enabled the suEXEC feature with the --enable-suexec option
-the suexec binary (together with Apache itself) is automatically built
-if you execute the command "make".
-<BR>
-After all components have been built you can execute the command
-"make install" to install them.
-The binary image "suexec" is installed in the directory defined by
-the --sbindir option. Default location is "/usr/local/apache/sbin/suexec".
-<BR>
-Please note that you need <STRONG><EM>root privileges</EM></STRONG> for
-the installation step. In order for the wrapper to set the user ID, it
-must be installed as owner <CODE><EM>root</EM></CODE> and must have the
-setuserid execution bit set for file modes.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="enable">Enabling & Disabling suEXEC</A></H3>
-<P ALIGN="LEFT">
-Upon startup of Apache, it looks for the file "suexec" in the "sbin"
-directory (default is "/usr/local/apache/sbin/suexec").
-If Apache finds a properly configured suEXEC wrapper, it will print
-the following message to the error log:
-<PRE>
- [notice] suEXEC mechanism enabled (wrapper: <EM>/path/to/suexec</EM>)
-</PRE>
-If you don't see this message at server startup, the server is most
-likely not finding the wrapper program where it expects it, or the
-executable is not installed <EM>setuid root</EM>.
-<BR>
-If you want to enable the suEXEC mechanism for the first time
-and an Apache server is already running you must kill and restart Apache.
-Restarting it with a simple HUP or USR1 signal will not be enough.
-<BR>
-If you want to disable suEXEC you should kill and restart Apache after
-you have removed the "suexec" file.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="usage">Using suEXEC</A></H3>
-<P ALIGN="LEFT">
-<STRONG>Virtual Hosts:</STRONG><BR>
-One way to use the suEXEC wrapper is through the
-<A HREF="mod/core.html#user">User</A> and
-<A HREF="mod/core.html#group">Group</A> directives in
-<A HREF="mod/core.html#virtualhost">VirtualHost</A>
-definitions. By setting these directives to values different from the
-main server user ID, all requests for CGI resources will be executed as
-the <EM>User</EM> and <EM>Group</EM> defined for that
-<CODE><VirtualHost></CODE>. If only one or
-neither of these directives are specified for a
-<CODE><VirtualHost></CODE> then the main
-server userid is assumed.
-<P>
-<STRONG>User directories:</STRONG><BR>
-The suEXEC wrapper can also be used to execute CGI programs as
-the user to which the request is being directed. This is accomplished by
-using the "<STRONG><CODE>~</CODE></STRONG>" character prefixing the user
-ID for whom execution is desired.
-The only requirement needed for this feature to work is for CGI
-execution to be enabled for the user and that the script must meet the
-scrutiny of the <A HREF="#model">security checks</A> above.
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3><A NAME="debug">Debugging suEXEC</A></H3>
-<P ALIGN="LEFT">
-The suEXEC wrapper will write log information to the file defined
-with the --suexec-logfile option as indicated above. If you feel you have
-configured and installed the wrapper properly, have a look at this log
-and the error_log for the server to see where you may have gone astray.
-</P>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<H3>
-<A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A>
-</H3>
-<P ALIGN="LEFT">
-<STRONG>NOTE!</STRONG> This section may not be complete. For the latest
-revision of this section of the documentation, see the Apache Group's
-<A HREF="http://www.apache.org/docs/suexec.html">Online Documentation</A>
-version.
-</P>
-
-<P ALIGN="LEFT">
-There are a few points of interest regarding the wrapper that can cause
-limitations on server setup. Please review these before submitting any
-"bugs" regarding suEXEC.
-<UL>
- <LI><STRONG>suEXEC Points Of Interest</STRONG></LI>
- <LI>Hierarchy limitations
- <BLOCKQUOTE>
- For security and efficiency reasons, all suexec requests must
- remain within either a top-level document root for virtual
- host requests, or one top-level personal document root for
- userdir requests. For example, if you have four VirtualHosts
- configured, you would need to structure all of your VHosts'
- document roots off of one main Apache document hierarchy to
- take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
- </BLOCKQUOTE>
- </LI>
- <LI>suEXEC's PATH environment variable
- <BLOCKQUOTE>
- This can be a dangerous thing to change. Make certain every
- path you include in this define is a <STRONG>trusted</STRONG>
- directory. You don't want to open people up to having someone
- from across the world running a trojan horse on them.
- </BLOCKQUOTE>
- </LI>
- <LI>Altering the suEXEC code
- <BLOCKQUOTE>
- Again, this can cause <STRONG>Big Trouble</STRONG> if you try
- this without knowing what you are doing. Stay away from it
- if at all possible.
- </BLOCKQUOTE>
- </LI>
-</UL>
-
-<P ALIGN="CENTER">
-<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ <br />
+ <br />
+
+
+ <p align="LEFT"><strong>Compiling and installing the suEXEC
+ wrapper</strong><br />
+ If you have enabled the suEXEC feature with the
+ --enable-suexec option the suexec binary (together with Apache
+ itself) is automatically built if you execute the command
+ "make".<br />
+ After all components have been built you can execute the
+ command "make install" to install them. The binary image
+ "suexec" is installed in the directory defined by the --sbindir
+ option. Default location is
+ "/usr/local/apache/sbin/suexec".<br />
+ Please note that you need <strong><em>root
+ privileges</em></strong> for the installation step. In order
+ for the wrapper to set the user ID, it must be installed as
+ owner <code><em>root</em></code> and must have the setuserid
+ execution bit set for file modes.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="enable" name="enable">Enabling & Disabling
+ suEXEC</a></h3>
+
+ <p align="LEFT">Upon startup of Apache, it looks for the file
+ "suexec" in the "sbin" directory (default is
+ "/usr/local/apache/sbin/suexec"). If Apache finds a properly
+ configured suEXEC wrapper, it will print the following message
+ to the error log:</p>
+<pre>
+ [notice] suEXEC mechanism enabled (wrapper: <em>/path/to/suexec</em>)
+</pre>
+ If you don't see this message at server startup, the server is
+ most likely not finding the wrapper program where it expects
+ it, or the executable is not installed <em>setuid root</em>.
+ <br />
+ If you want to enable the suEXEC mechanism for the first time
+ and an Apache server is already running you must kill and
+ restart Apache. Restarting it with a simple HUP or USR1 signal
+ will not be enough. <br />
+ If you want to disable suEXEC you should kill and restart
+ Apache after you have removed the "suexec" file. <br />
+ <br />
+
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="usage" name="usage">Using suEXEC</a></h3>
+
+ <p align="LEFT"><strong>Virtual Hosts:</strong><br />
+ One way to use the suEXEC wrapper is through the <a
+ href="mod/core.html#user">User</a> and <a
+ href="mod/core.html#group">Group</a> directives in <a
+ href="mod/core.html#virtualhost">VirtualHost</a> definitions.
+ By setting these directives to values different from the main
+ server user ID, all requests for CGI resources will be executed
+ as the <em>User</em> and <em>Group</em> defined for that
+ <code><VirtualHost></code>. If only one or neither of
+ these directives are specified for a
+ <code><VirtualHost></code> then the main server userid is
+ assumed.</p>
+
+ <p><strong>User directories:</strong><br />
+ The suEXEC wrapper can also be used to execute CGI programs as
+ the user to which the request is being directed. This is
+ accomplished by using the "<strong><code>~</code></strong>"
+ character prefixing the user ID for whom execution is desired.
+ The only requirement needed for this feature to work is for CGI
+ execution to be enabled for the user and that the script must
+ meet the scrutiny of the <a href="#model">security checks</a>
+ above.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="debug" name="debug">Debugging suEXEC</a></h3>
+
+ <p align="LEFT">The suEXEC wrapper will write log information
+ to the file defined with the --suexec-logfile option as
+ indicated above. If you feel you have configured and installed
+ the wrapper properly, have a look at this log and the error_log
+ for the server to see where you may have gone astray.</p>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+
+ <h3><a id="jabberwock" name="jabberwock">Beware the Jabberwock:
+ Warnings & Examples</a></h3>
+
+ <p align="LEFT"><strong>NOTE!</strong> This section may not be
+ complete. For the latest revision of this section of the
+ documentation, see the Apache Group's <a
+ href="http://www.apache.org/docs/suexec.html">Online
+ Documentation</a> version.</p>
+
+ <p align="LEFT">There are a few points of interest regarding
+ the wrapper that can cause limitations on server setup. Please
+ review these before submitting any "bugs" regarding suEXEC.</p>
+
+ <ul>
+ <li><strong>suEXEC Points Of Interest</strong></li>
+
+ <li>
+ Hierarchy limitations
+
+ <blockquote>
+ For security and efficiency reasons, all suexec requests
+ must remain within either a top-level document root for
+ virtual host requests, or one top-level personal document
+ root for userdir requests. For example, if you have four
+ VirtualHosts configured, you would need to structure all
+ of your VHosts' document roots off of one main Apache
+ document hierarchy to take advantage of suEXEC for
+ VirtualHosts. (Example forthcoming.)
+ </blockquote>
+ </li>
+
+ <li>
+ suEXEC's PATH environment variable
+
+ <blockquote>
+ This can be a dangerous thing to change. Make certain
+ every path you include in this define is a
+ <strong>trusted</strong> directory. You don't want to
+ open people up to having someone from across the world
+ running a trojan horse on them.
+ </blockquote>
+ </li>
+
+ <li>
+ Altering the suEXEC code
+
+ <blockquote>
+ Again, this can cause <strong>Big Trouble</strong> if you
+ try this without knowing what you are doing. Stay away
+ from it if at all possible.
+ </blockquote>
+ </li>
+ </ul>
+
+ <p align="CENTER"><strong><a href="suexec.html">BACK TO
+ CONTENTS</a></strong></p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Upgrading to 2.0 from 1.3</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Upgrading to 2.0 from 1.3</H1>
-
-<P>In order to assist folks upgrading, we maintain a document
-describing information critical to existing Apache users. These are
-intended to be brief notes, and you should be able to find more
-information in either the <A HREF="new_features_2_0.html">New
-Features</A> document, or in the <CODE>src/CHANGES</CODE> file.
-
-<H3>Compile-Time Configuration Changes</H3>
-
-<UL>
-<LI>Apache now uses an <code>autoconf</code> and <code>libtool</code>
-system for <a href="install.html">configuring the build processes</a>.
-Using this system is similar to, but not the same as, using the APACI
-system in Apache 1.3.</li>
-
-<li>In addition to the usual selection of modules which you can choose
-to compile, Apache 2.0 has moved the main part of request processing
-into <a href="mpm.html">Multi-Processing Modules</a> (MPMs).</li>
-</UL>
-
-<H3>Run-Time Configuration Changes</H3>
-
-<UL>
-
-<li>Many directives that were in the core server in Apache 1.3
-are now in the MPMs. If you wish the behavior of the server
-to be as similar as possible to the behavior of Apache 1.3,
-you should select the <a href="mod/prefork.html">prefork</a>
-MPM. Other MPMs will have different directives to control process
-creation and request processing.</li>
-
-<li>The <code>CacheNegotiatedDocs</code> directive now takes
-the argument <code>on</code> or <code>off</code>. Existing
-instances of <code>CacheNegotiatedDocs</code> should be replaced
-with <code>CacheNegotiatedDocs on</code>.</li>
-
-<li>The <code>ErrorDocument</code> directive no longer uses a quote at
-the beginning of the argument to indicate a text message. Instead,
-you should enclose the message in double quotes. For example,
-existing instances of <blockquote><code>ErrorDocument 403 "Some
-Message</code></blockquote> should be replaced with
-<blockquote><code>ErrorDocument 403 "Some
-Message"</code></blockquote> As long as the second argument is not a
-valid URL or pathname, it will be treated as a text message.</li>
-
-<li>The <code>AccessConfig</code> and <code>ResourceConfig</code>
-directives no longer exist. Existing instances of these directives
-can be replaced with the <a
-href="mod/core.html#include"><code>Include</code></a> directive which
-has equivalent functionality. If you were making use of the default
-values of these directives without including them in the configuration
-files, you may need to add <code>Include conf/access.conf</code> and
-<code>Include conf/srm.conf</code> to your httpd.conf. In order to
-assure that Apache reads the configuration files in the same order as
-was implied by the older directives, the <code>Include</code>
-directives should be placed at the end of httpd.conf, with the one for
-<code>srm.conf</code> preceding the one for
-<code>access.conf</code>.</li>
-
-<li>The <code>BindAddress</code> directive no longer exists.
-Equivalent functionality is provided with the more flexible <code><a
-href="mod/mpm_common.html#listen">Listen</a></code> directive.
-
-<li>The <code>ServerType</code> directive no longer exists.
-The method used to serve requests is now determined by the selection
-of MPM. There is currently no MPM designed to be launched by
-inetd.</li>
-
-<li>The mod_log_agent and mod_log_referer modules which provided the
-<code>AgentLog</code>, <code>RefererLog</code> and
-<code>RefererIgnore</code> directives have been removed. Agent and
-referer logs are still available using the <a
-href="mod/mod_log_config.html#customlog">CustomLog</a> directive of
-mod_log_config.</li>
-
-<li>The <code>AddModule</code> and <code>ClearModuleList</code>
-directives no longer exist. These directives where used to ensure
-that modules could be enabled in the correct order. The new
-Apache 2.0 API allows modules to explicitly specify their ordering,
-eliminating the need for these directives.</li>
-
-</UL>
-
-<H3>Misc Changes</H3>
-
-<UL>
-
-<li>The <code>httpd</code> command line option <code>-S</code>
-which was used for printing the virtual host configuration has
-been replaced by <code>-t -D DUMP_VHOSTS</code>.</li>
-
-<li>The module mod_auth_digest, which was experimental in Apache 1.3
-is now a standard module.</li>
-
-<li>The mod_mmap_static module, which was experimental in Apache 1.3
-has been replaced with mod_file_cache.</li>
-
-<li>The distribution has been completely reorganized so that it no
-longer contains an independent <code>src</code> directory. Instead,
-the sources are logically organized under the main distribution
-directory, and installations of the compiled server should be
-directed to a separate directory.</li>
-
-</UL>
-
-<H3>Third Party Modules</H3>
-
-<p>Extensive changes were made to the server API in Apache 2.0.
-Existing modules designed for the Apache 1.3 API will <strong>not</strong>
-work in Apache 2.0 without modification. Details are provided in
-the <a href="developer/">developer documentation</a>.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Upgrading to 2.0 from 1.3</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Upgrading to 2.0 from 1.3</h1>
+
+ <p>In order to assist folks upgrading, we maintain a document
+ describing information critical to existing Apache users. These
+ are intended to be brief notes, and you should be able to find
+ more information in either the <a
+ href="new_features_2_0.html">New Features</a> document, or in
+ the <code>src/CHANGES</code> file.</p>
+
+ <h3>Compile-Time Configuration Changes</h3>
+
+ <ul>
+ <li>Apache now uses an <code>autoconf</code> and
+ <code>libtool</code> system for <a
+ href="install.html">configuring the build processes</a>.
+ Using this system is similar to, but not the same as, using
+ the APACI system in Apache 1.3.</li>
+
+ <li>In addition to the usual selection of modules which you
+ can choose to compile, Apache 2.0 has moved the main part of
+ request processing into <a href="mpm.html">Multi-Processing
+ Modules</a> (MPMs).</li>
+ </ul>
+
+ <h3>Run-Time Configuration Changes</h3>
+
+ <ul>
+ <li>Many directives that were in the core server in Apache
+ 1.3 are now in the MPMs. If you wish the behavior of the
+ server to be as similar as possible to the behavior of Apache
+ 1.3, you should select the <a
+ href="mod/prefork.html">prefork</a> MPM. Other MPMs will have
+ different directives to control process creation and request
+ processing.</li>
+
+ <li>The <code>CacheNegotiatedDocs</code> directive now takes
+ the argument <code>on</code> or <code>off</code>. Existing
+ instances of <code>CacheNegotiatedDocs</code> should be
+ replaced with <code>CacheNegotiatedDocs on</code>.</li>
+
+ <li>
+ The <code>ErrorDocument</code> directive no longer uses a
+ quote at the beginning of the argument to indicate a text
+ message. Instead, you should enclose the message in double
+ quotes. For example, existing instances of
+
+ <blockquote>
+ <code>ErrorDocument 403 "Some Message</code>
+ </blockquote>
+ should be replaced with
+
+ <blockquote>
+ <code>ErrorDocument 403 "Some Message"</code>
+ </blockquote>
+ As long as the second argument is not a valid URL or
+ pathname, it will be treated as a text message.
+ </li>
+
+ <li>The <code>AccessConfig</code> and
+ <code>ResourceConfig</code> directives no longer exist.
+ Existing instances of these directives can be replaced with
+ the <a href="mod/core.html#include"><code>Include</code></a>
+ directive which has equivalent functionality. If you were
+ making use of the default values of these directives without
+ including them in the configuration files, you may need to
+ add <code>Include conf/access.conf</code> and <code>Include
+ conf/srm.conf</code> to your httpd.conf. In order to assure
+ that Apache reads the configuration files in the same order
+ as was implied by the older directives, the
+ <code>Include</code> directives should be placed at the end
+ of httpd.conf, with the one for <code>srm.conf</code>
+ preceding the one for <code>access.conf</code>.</li>
+
+ <li>The <code>BindAddress</code> directive no longer exists.
+ Equivalent functionality is provided with the more flexible
+ <code><a href="mod/mpm_common.html#listen">Listen</a></code>
+ directive.</li>
+
+ <li>The <code>ServerType</code> directive no longer exists.
+ The method used to serve requests is now determined by the
+ selection of MPM. There is currently no MPM designed to be
+ launched by inetd.</li>
+
+ <li>The mod_log_agent and mod_log_referer modules which
+ provided the <code>AgentLog</code>, <code>RefererLog</code>
+ and <code>RefererIgnore</code> directives have been removed.
+ Agent and referer logs are still available using the <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a>
+ directive of mod_log_config.</li>
+
+ <li>The <code>AddModule</code> and
+ <code>ClearModuleList</code> directives no longer exist.
+ These directives where used to ensure that modules could be
+ enabled in the correct order. The new Apache 2.0 API allows
+ modules to explicitly specify their ordering, eliminating the
+ need for these directives.</li>
+ </ul>
+
+ <h3>Misc Changes</h3>
+
+ <ul>
+ <li>The <code>httpd</code> command line option
+ <code>-S</code> which was used for printing the virtual host
+ configuration has been replaced by <code>-t -D
+ DUMP_VHOSTS</code>.</li>
+
+ <li>The module mod_auth_digest, which was experimental in
+ Apache 1.3 is now a standard module.</li>
+
+ <li>The mod_mmap_static module, which was experimental in
+ Apache 1.3 has been replaced with mod_file_cache.</li>
+
+ <li>The distribution has been completely reorganized so that
+ it no longer contains an independent <code>src</code>
+ directory. Instead, the sources are logically organized under
+ the main distribution directory, and installations of the
+ compiled server should be directed to a separate
+ directory.</li>
+ </ul>
+
+ <h3>Third Party Modules</h3>
+
+ <p>Extensive changes were made to the server API in Apache 2.0.
+ Existing modules designed for the Apache 1.3 API will
+ <strong>not</strong> work in Apache 2.0 without modification.
+ Details are provided in the <a href="developer/">developer
+ documentation</a>.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<TITLE>Mise à jour de la version 1.3 à la version 2.0</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Mise à de la version 1.3 à la version 2.0</H1>
-
-<P>Afin d'aider les personnes souhaitant se mettre à jour, nous
-maintenons un document décrivant les informations critiques concernant
-les utilisateurs d'Apache. Ces informations sont sous la forme de brèves
-notes, et vous pouvez trouver plus d'informations dans le document
- <A HREF="new_features_2_0.html">Nouvelles fonctionnalités</A>
- ou dans le fichier <CODE>src/CHANGES</CODE>.
-
-<H3>Changement de la configuration à la compilation</H3>
-
-<UL>
-<LI>Apache utilise maintenant <code>autoconf</code> et <code>libtool</code>
-afin de configurer la compilation. L'utilisation de ces outils est
-similaire, mais pas tout à fait identique, au système APACI
-de configuration existant dans la version 1.3 d'Apache.
-</li>
-
-<li>En plus de l'habituelle sélection de modules que vous pouvez choisir
-de compiler, Apache 2.0 a déplacé la majeure partie du traitement
-des requêtes dans les <a href="mpm.html">modules multi-traitements</a> (MPMs).</li>
-</UL>
-
-<H3>Changement de la configuration à l'exécution</H3>
-
-<UL>
-<li>La directive <code>CacheNegotiatedDocs</code> prend maintenant un
-paramètre qui est soit <code>on</code> soit <code>off</code>. Les configurations
-existantes utilisant la directive <code>CacheNegotiatedDocs</code> doivent
-la remplacer par <code>CacheNegotiatedDocs on</code>.</li>
-
-<li>La directive <code>ErrorDocument</code> n'utilise plus de guillemets
-ou d'apostrophes au début du paramètre indiquant le message.
-Dorénavant, le message devra être entre guillemets. Par exemple, la
-directive <blockquote><code>ErrorDocument 403 "Some Message</code></blockquote>
-devra être remplacé par <blockquote><code>ErrorDocument 403 "Some
-Message"</code></blockquote> Si le second argument n'est pas une URL ou un chemin
-valide, il sera traité comme un message.</li>
-
-<li>Les directives <code>AccessConfig</code> et <code>ResourceConfig</code>
-n'existent plus. Ces directives peuvent être remplacées de manière
-équivalente par la directive
-<a href="mod/core.html#include"><code>Include</code></a>.
-Si vous utilisiez ces directives en utilisant les valeurs par défaut sans
-les définir explicitement, vous devez
-ajouter les lignes <code>Include conf/access.conf</code> et
-<code>Include conf/srm.conf</code> dans votre fichier httpd.conf.
-Afin de garantir qu'Apache lit les différents fichiers de configuration
-dans le même ordre que celui pour les anciennes directives, Les directives
-<code>Include</code> doivent être situées à la fin du fichier
-httpd.conf, celle représentant <code>srm.conf</code> avant celle pour
-<code>access.conf</code>.</li>
-
-<li>La directive <code>BindAddress</code> n'existe plus. La même
-fonctionnalité est fournie par la directive
-<code><a href="mod/mpm_common.html">Listen</a></code>.</li>
-
-<li>La directive <code>ExtendedStatus</code> n'existe plus.
-Le suivi des statuts a été entièrement réécrit
-afin de bénéficier du nouveau système MPM.</li>
-
-<li>La directive <code>ServerType</code> n'existe plus.
-La méthode utilisée pour servir les requêtes est
-déterminée maintenant par la sélection d'un MPM.
-Il n'existe pas actuellement de MPM conçu pour être lancé
-par inetd.</li>
-
-<li>Beaucoup de directives qui étaient situées dans le noyau
-du serveur pour la version 1.3 se trouvent maintenant dans les MPMs.</li>
-
-<li>Les modules mod_log_agent et mod_log_referer qui traitaient les directives
-<code>AgentLog</code>, <code>RefererLog</code> et
-<code>RefererIgnore</code> ont été supprimés.
-Le traçage des agents et référants et toujours disponible
-en utilisant la directive
-<a href="mod/mod_log_config.html#customlog">CustomLog</a> du module
-mod_log_config.</li>
-
-</UL>
-
-<H3>Changements divers</H3>
-
-<UL>
-
-<li>L'option <code>-S</code> du programme <code>httpd</code>
-qui servait à afficher la configuration des hôtes virtuels est
-remplacé par <code>-t -D DUMP_VHOSTS</code>.</li>
-
-<li>Le module mod_auth_digest, qui était expérimental dans la version 1.3,
-est maintenant un module standard.</li>
-
-<li>Le module mod_mmap_static, qui était expérimental dans la version 1.3
-a été remplacé par le module mod_file_cache.</li>
-
-
-</UL>
-
-<H3>Modules tiers</H3>
-
-<p>D'énormes changements ont été réalisés
-sur l'API du serveur Apache 2.0. Les modules conçus à l'aide de
-l'API Apache 1.3 <strong>ne fonctionneront pas</strong> sur Apache 2.0 sans
-modifications. Plus de détails sont fournis dans la
-<a href="developer/">documentation du développeur</a>.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+ <meta http-equiv="Content-Type"
+ content="text/html; charset=iso-8859-1" />
+
+ <title>Mise à jour de la version 1.3 à la version
+ 2.0</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Mise à de la version 1.3 à la
+ version 2.0</h1>
+
+ <p>Afin d'aider les personnes souhaitant se mettre à
+ jour, nous maintenons un document décrivant les
+ informations critiques concernant les utilisateurs d'Apache.
+ Ces informations sont sous la forme de brèves notes, et
+ vous pouvez trouver plus d'informations dans le document <a
+ href="new_features_2_0.html">Nouvelles
+ fonctionnalités</a> ou dans le fichier
+ <code>src/CHANGES</code>.</p>
+
+ <h3>Changement de la configuration à la compilation</h3>
+
+ <ul>
+ <li>Apache utilise maintenant <code>autoconf</code> et
+ <code>libtool</code> afin de configurer la compilation.
+ L'utilisation de ces outils est similaire, mais pas tout
+ à fait identique, au système APACI de
+ configuration existant dans la version 1.3 d'Apache.</li>
+
+ <li>En plus de l'habituelle sélection de modules que
+ vous pouvez choisir de compiler, Apache 2.0 a
+ déplacé la majeure partie du traitement des
+ requêtes dans les <a href="mpm.html">modules
+ multi-traitements</a> (MPMs).</li>
+ </ul>
+
+ <h3>Changement de la configuration à
+ l'exécution</h3>
+
+ <ul>
+ <li>La directive <code>CacheNegotiatedDocs</code> prend
+ maintenant un paramètre qui est soit <code>on</code>
+ soit <code>off</code>. Les configurations existantes
+ utilisant la directive <code>CacheNegotiatedDocs</code>
+ doivent la remplacer par <code>CacheNegotiatedDocs
+ on</code>.</li>
+
+ <li>
+ La directive <code>ErrorDocument</code> n'utilise plus de
+ guillemets ou d'apostrophes au début du
+ paramètre indiquant le message. Dorénavant,
+ le message devra être entre guillemets. Par exemple,
+ la directive
+
+ <blockquote>
+ <code>ErrorDocument 403 "Some Message</code>
+ </blockquote>
+ devra être remplacé par
+
+ <blockquote>
+ <code>ErrorDocument 403 "Some Message"</code>
+ </blockquote>
+ Si le second argument n'est pas une URL ou un chemin
+ valide, il sera traité comme un message.
+ </li>
+
+ <li>Les directives <code>AccessConfig</code> et
+ <code>ResourceConfig</code> n'existent plus. Ces directives
+ peuvent être remplacées de manière
+ équivalente par la directive <a
+ href="mod/core.html#include"><code>Include</code></a>. Si
+ vous utilisiez ces directives en utilisant les valeurs par
+ défaut sans les définir explicitement, vous
+ devez ajouter les lignes <code>Include
+ conf/access.conf</code> et <code>Include conf/srm.conf</code>
+ dans votre fichier httpd.conf. Afin de garantir qu'Apache lit
+ les différents fichiers de configuration dans le
+ même ordre que celui pour les anciennes directives, Les
+ directives <code>Include</code> doivent être
+ situées à la fin du fichier httpd.conf, celle
+ représentant <code>srm.conf</code> avant celle pour
+ <code>access.conf</code>.</li>
+
+ <li>La directive <code>BindAddress</code> n'existe plus. La
+ même fonctionnalité est fournie par la directive
+ <code><a href="mod/mpm_common.html">Listen</a></code>.</li>
+
+ <li>La directive <code>ExtendedStatus</code> n'existe plus.
+ Le suivi des statuts a été entièrement
+ réécrit afin de bénéficier du
+ nouveau système MPM.</li>
+
+ <li>La directive <code>ServerType</code> n'existe plus. La
+ méthode utilisée pour servir les requêtes
+ est déterminée maintenant par la
+ sélection d'un MPM. Il n'existe pas actuellement de
+ MPM conçu pour être lancé par inetd.</li>
+
+ <li>Beaucoup de directives qui étaient situées
+ dans le noyau du serveur pour la version 1.3 se trouvent
+ maintenant dans les MPMs.</li>
+
+ <li>Les modules mod_log_agent et mod_log_referer qui
+ traitaient les directives <code>AgentLog</code>,
+ <code>RefererLog</code> et <code>RefererIgnore</code> ont
+ été supprimés. Le traçage des
+ agents et référants et toujours disponible en
+ utilisant la directive <a
+ href="mod/mod_log_config.html#customlog">CustomLog</a> du
+ module mod_log_config.</li>
+ </ul>
+
+ <h3>Changements divers</h3>
+
+ <ul>
+ <li>L'option <code>-S</code> du programme <code>httpd</code>
+ qui servait à afficher la configuration des
+ hôtes virtuels est remplacé par <code>-t -D
+ DUMP_VHOSTS</code>.</li>
+
+ <li>Le module mod_auth_digest, qui était
+ expérimental dans la version 1.3, est maintenant un
+ module standard.</li>
+
+ <li>Le module mod_mmap_static, qui était
+ expérimental dans la version 1.3 a été
+ remplacé par le module mod_file_cache.</li>
+ </ul>
+
+ <h3>Modules tiers</h3>
+
+ <p>D'énormes changements ont été
+ réalisés sur l'API du serveur Apache 2.0. Les
+ modules conçus à l'aide de l'API Apache 1.3
+ <strong>ne fonctionneront pas</strong> sur Apache 2.0 sans
+ modifications. Plus de détails sont fournis dans la <a
+ href="developer/">documentation du développeur</a>.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Mapping URLs to Filesystem Locations - Apache HTTP Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Mapping URLs to Filesystem Locations</h1>
-
-<p>This document explains how Apache uses the URL of a request to
-determine the filesystem location from which to serve a file.</p>
-
-<ul>
-<li><a href="#documentroot">DocumentRoot</a></li>
-<li><a href="#outside">Files Outside the DocumentRoot</a></li>
-<li><a href="#user">User Directories</a></li>
-<li><a href="#redirect">URL Redirection</a></li>
-<li><a href="#rewrite">Rewrite Engine</a></li>
-<li><a href="#notfound">File Not Found</a></li>
-</ul>
-
-<hr>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_alias.html">mod_alias</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a><br>
-<a href="mod/mod_userdir.html">mod_userdir</a><br>
-<a href="mod/mod_speling.html">mod_speling</a><br>
-<a href="mod/mod_vhost_alias.html">mod_vhost_alias</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_alias.html#alias">Alias</A><br>
-<A HREF="mod/mod_alias.html#aliasmatch">AliasMatch</A><br>
-<A HREF="mod/mod_speling.html#checkspelling">CheckSpelling</A><br>
-<A HREF="mod/core.html#documentroot">DocumentRoot</A><br>
-<A HREF="mod/core.html#errordocument">ErrorDocument</A><br>
-<a href="mod/core.html#options">Options</a><br>
-<A HREF="mod/mod_alias.html#redirect">Redirect</A><br>
-<A HREF="mod/mod_alias.html#redirectmatch">RedirectMatch</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteCond">RewriteCond</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteRule">RewriteRule</A><br>
-<A HREF="mod/mod_alias.html#scriptalias">ScriptAlias</A><br>
-<A HREF="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</A><br>
-<A HREF="mod/mod_userdir.html#userdir">UserDir</A><br>
-
-</td></tr></table>
-
-<h2><a name="documentroot">DocumentRoot</a></h2>
-
-<p>In deciding what file to serve for a given request, Apache's
-default behavior is to take the URL-Path for the request (the part of
-the URL following the hostname and port) and add it to the end of the
-<a href="mod/core.html#documentroot">DocumentRoot</a> specified in
-your configuration files. Therefore, the files and directories
-underneath the <code>DocumentRoot</code> make up the basic document
-tree which will be visible from the web.</p>
-
-<p>Apache is also capable of <a href="vhosts/">Virtual Hosting</a>,
-where the server receives requests for more than one host. In this
-case, a different <code>DocumentRoot</code> can be specified for each
-virtual host, or alternatively, the directives provided by the module
-<a href="mod/mod_vhost_alias.html">mod_vhost_alias</a> can be used to
-dynamically determine the appropriate place from which to serve
-content based on the requested IP address or hostname.</p>
-
-<h2><a name="outside">Files Outside the DocumentRoot</a></h2>
-
-<p>There are frequently circumstances where it is necessary to allow
-web access to parts of the filesystem that are not strictly underneath
-the <a href="mod/core.html#documentroot">DocumentRoot</a>. Apache
-offers several different ways to accomplish this. On Unix systems,
-symbolic links can bring other parts of the filesystem under the
-<code>DocumentRoot</code>. For security reasons, Apache will follow
-symbolic links only if the <a href="mod/core.html#options">Options</a>
-setting for the relevant directory includes
-<code>FollowSymLinks</code> or <code>SymLinksIfOwnerMatch</code>.</p>
-
-<p>Alternatively, the <a href="mod/mod_alias.html#alias">Alias</a>
-directive will map any part of the filesystem into the web
-space. For example, with</p>
-
-<blockquote><code>Alias /docs /var/web/
-</code></blockquote>
-
-<p>the URL <code>http://www.example.com/docs/dir/file.html</code> will
-be served from <code>/var/web/dir/file.html</code>. The <a
-href="mod/mod_alias.html#scriptalias">ScriptAlias</a> directive works
-the same way, with the additional effect that all content located at
-the target path is treated as CGI scripts.</p>
-
-<p>For situations where you require additional flexibility, you can
-use the <a href="mod/mod_alias.html#aliasmatch">AliasMatch</a> and <a
-href="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</a>
-directives to do powerful regular-expression based matching and
-substitution. For example,</p>
-
-<blockquote><code> ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*)
-/home/$1/cgi-bin/$2 </code></blockquote>
-
-<p>will map a request to
-<code>http://example.com/~user/cgi-bin/script.cgi</code> to the path
-<code>/home/user/cgi-bin/script.cgi</code> and will treat the
-resulting file as a CGI script.</p>
-
-<h2><a name="user">User Directories</a></h2>
-
-<p>Traditionally on Unix systems, the home directory of a particular
-<em>user</em> can be referred to as <code>~user/</code>. The module
-<a href="mod/mod_userdir.html">mod_userdir</a> extends this idea to
-the web by allowing files under each user's home directory to be
-accessed using URLs such as the following.</p>
-
-<blockquote><code>http://www.example.com/~user/file.html</code></blockquote>
-
-<p>For security reasons, it is inappropriate to give direct
-access to a user's home directory from the web. Therefore, the <a
-href="mod/mod_userdir.html#userdir">UserDir</a> directive
-specifies a directory underneath the user's home directory where web
-files are located. Using the default setting of <code>Userdir
-public_html</code>, the above URL maps to a file at a directory
-like <code>/home/user/public_html/file.html</code> where
-<code>/home/user/</code> is the user's home directory as specified in
-<code>/etc/passwd</code>.</p>
-
-<p>There are also several other forms of the <code>Userdir</code>
-directive which you can use on systems where <code>/etc/passwd</code>
-does not contain the location of the home directory.</p>
-
-<p>Some people find the "~" symbol (which is often encoded on the web
-as <code>%7e</code>) to be awkward and prefer to use an alternate
-string to represent user directories. This functionality is not
-supported by mod_userdir. However, if users' home directories are
-structured in a regular way, then it is possible to use the <a
-href="mod/mod_alias.html#aliasmatch">AliasMatch</a> directive to
-achieve the desired effect. For example, to make
-<code>http://www.example.com/upages/user/file.html</code> map to
-<code>/home/user/public_html/file.html</code>, use the following
-<code>AliasMatch</code> directive:</p>
-
-<blockquote><code>
-AliasMatch ^/upages/([^/]*)/?(.*) /home/$1/public_html/$2
-</code></blockquote>
-
-<h2><a name="redirect">URL Redirection</a></h2>
-
-<p>The configuration directives discussed in the above sections tell
-Apache to get content from a specific place in the filesystem and
-return it to the client. Sometimes, it is desirable instead to inform
-the client that the requested content is located at a different
-URL, and instruct the client to make a new request with the new URL.
-This is called <em>redirection</em> and is implemented by the
-<a href="mod/mod_alias.html#redirect">Redirect</a> directive. For
-example, if the contents of the directory <code>/foo/</code> under the
-<code>DocumentRoot</code> are moved to the new directory
-<code>/bar/</code>, you can instruct clients to request the content at
-the new location as follows:</p>
-
-<blockquote><code>Redirect permanent
-/foo/ http://www.example.com/bar/</code></blockquote>
-
-<p>This will redirect any URL-Path starting in <code>/foo/</code> to
-the same URL path on the <code>www.example.com</code> server with
-<code>/bar/</code> substituted for <code>/foo/</code>. You can
-redirect clients to any server, not only the origin server.</p>
-
-<p>Apache also provides a <a
-href="mod/mod_alias.html#redirectmatch">RedirectMatch</a> directive
-for more complicated rewriting problems. For example, to redirect
-requests for the site home page to a different site, but leave all
-other requests alone, use the following configuration:</p>
-
-<blockquote><code>
-RedirectMatch permanent ^/$ http://www.example.com/startpage.html
-</code></blockquote>
-
-<p>Alternatively, to temporarily redirect all pages on a site to one
-particular page, use the following:</p>
-
-<blockquote><code>
-RedirectMatch temp .* http://www.example.com/startpage.html
-</code></blockquote>
-
-<h2><a name="rewrite">Rewriting Engine</a></h2>
-
-<p>When even more powerful substitution is required, the rewriting
-engine provided by <a href="mod/mod_rewrite.html">mod_rewrite</a> can
-be useful. The directives provided by this module use
-characteristics of the request such as browser type or source IP
-address in deciding from where to serve content. In addition,
-mod_rewrite can use external database files or programs to determine
-how to handle a request. Many practical examples employing
-mod_rewrite are discussed in the <a href="misc/rewriteguide.html">URL
-Rewriting Guide</a>.</p>
-
-<h2><a name="notfound">File Not Found</a></h2>
-
-<p>Inevitably, URLs will be requested for which no matching file can
-be found in the filesystem. This can happen for several reasons. In
-some cases, it can be a result of moving documents from one location
-to another. In this case, it is best to use <a href="#redirect">URL
-redirection</a> to inform clients of the new location of the resource.
-In this way, you can assure that old bookmarks and links will continue
-to work, even though the resource is at a new location.</p>
-
-<p>Another common cause of "File Not Found" errors is accidental
-mistyping of URLs, either directly in the browser, or in HTML links.
-Apache provides the module <a href="mod/mod_speling.html">mod_speling</a>
-(sic) to help with this problem. When this module is activated, it
-will intercept "File Not Found" errors and look for a resource with a
-similar filename. If one such file is found, mod_speling will send an
-HTTP redirect to the client informing it of the correct location. If
-several "close" files are found, a list of available alternatives will
-be presented to the client.</p>
-
-<p>An especially useful feature of mod_speling, is that it will
-compare filenames without respect to case. This can help systems
-where users are unaware of the case-sensitive nature of URLs and the
-unix filesystem. But using mod_speling for anything more than the
-occasional URL correction can place additional load on the server,
-since each "incorrect" request is followed by a URL redirection and a
-new request from the client.</p>
-
-<p>If all attempts to locate the content fail, Apache returns an error
-page with HTTP status code 404 (file not found). The appearance of
-this page is controlled with the <a
-href="mod/core.html#errordocument">ErrorDocument</a> directive and can
-be customized in a flexible manner as discussed in the <a
-href="custom-error.html">Custom error responses</a> and <a
-href="misc/custom_errordocs.html">International Server Error
-Responses</a> documents.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Mapping URLs to Filesystem Locations - Apache HTTP
+ Server</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Mapping URLs to Filesystem Locations</h1>
+
+ <p>This document explains how Apache uses the URL of a request
+ to determine the filesystem location from which to serve a
+ file.</p>
+
+ <ul>
+ <li><a href="#documentroot">DocumentRoot</a></li>
+
+ <li><a href="#outside">Files Outside the
+ DocumentRoot</a></li>
+
+ <li><a href="#user">User Directories</a></li>
+
+ <li><a href="#redirect">URL Redirection</a></li>
+
+ <li><a href="#rewrite">Rewrite Engine</a></li>
+
+ <li><a href="#notfound">File Not Found</a></li>
+ </ul>
+ <hr />
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_alias.html">mod_alias</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a><br />
+ <a href="mod/mod_userdir.html">mod_userdir</a><br />
+ <a href="mod/mod_speling.html">mod_speling</a><br />
+ <a
+ href="mod/mod_vhost_alias.html">mod_vhost_alias</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_alias.html#alias">Alias</a><br />
+ <a
+ href="mod/mod_alias.html#aliasmatch">AliasMatch</a><br />
+ <a
+ href="mod/mod_speling.html#checkspelling">CheckSpelling</a><br />
+ <a
+ href="mod/core.html#documentroot">DocumentRoot</a><br />
+ <a
+ href="mod/core.html#errordocument">ErrorDocument</a><br />
+ <a href="mod/core.html#options">Options</a><br />
+ <a href="mod/mod_alias.html#redirect">Redirect</a><br />
+ <a
+ href="mod/mod_alias.html#redirectmatch">RedirectMatch</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteCond">RewriteCond</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteRule">RewriteRule</a><br />
+ <a
+ href="mod/mod_alias.html#scriptalias">ScriptAlias</a><br />
+ <a
+ href="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</a><br />
+ <a href="mod/mod_userdir.html#userdir">UserDir</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h2><a id="documentroot"
+ name="documentroot">DocumentRoot</a></h2>
+
+ <p>In deciding what file to serve for a given request, Apache's
+ default behavior is to take the URL-Path for the request (the
+ part of the URL following the hostname and port) and add it to
+ the end of the <a
+ href="mod/core.html#documentroot">DocumentRoot</a> specified in
+ your configuration files. Therefore, the files and directories
+ underneath the <code>DocumentRoot</code> make up the basic
+ document tree which will be visible from the web.</p>
+
+ <p>Apache is also capable of <a href="vhosts/">Virtual
+ Hosting</a>, where the server receives requests for more than
+ one host. In this case, a different <code>DocumentRoot</code>
+ can be specified for each virtual host, or alternatively, the
+ directives provided by the module <a
+ href="mod/mod_vhost_alias.html">mod_vhost_alias</a> can be used
+ to dynamically determine the appropriate place from which to
+ serve content based on the requested IP address or
+ hostname.</p>
+
+ <h2><a id="outside" name="outside">Files Outside the
+ DocumentRoot</a></h2>
+
+ <p>There are frequently circumstances where it is necessary to
+ allow web access to parts of the filesystem that are not
+ strictly underneath the <a
+ href="mod/core.html#documentroot">DocumentRoot</a>. Apache
+ offers several different ways to accomplish this. On Unix
+ systems, symbolic links can bring other parts of the filesystem
+ under the <code>DocumentRoot</code>. For security reasons,
+ Apache will follow symbolic links only if the <a
+ href="mod/core.html#options">Options</a> setting for the
+ relevant directory includes <code>FollowSymLinks</code> or
+ <code>SymLinksIfOwnerMatch</code>.</p>
+
+ <p>Alternatively, the <a
+ href="mod/mod_alias.html#alias">Alias</a> directive will map
+ any part of the filesystem into the web space. For example,
+ with</p>
+
+ <blockquote>
+ <code>Alias /docs /var/web/</code>
+ </blockquote>
+
+ <p>the URL
+ <code>http://www.example.com/docs/dir/file.html</code> will be
+ served from <code>/var/web/dir/file.html</code>. The <a
+ href="mod/mod_alias.html#scriptalias">ScriptAlias</a> directive
+ works the same way, with the additional effect that all content
+ located at the target path is treated as CGI scripts.</p>
+
+ <p>For situations where you require additional flexibility, you
+ can use the <a
+ href="mod/mod_alias.html#aliasmatch">AliasMatch</a> and <a
+ href="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</a>
+ directives to do powerful regular-expression based matching and
+ substitution. For example,</p>
+
+ <blockquote>
+ <code>ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*)
+ /home/$1/cgi-bin/$2</code>
+ </blockquote>
+
+ <p>will map a request to
+ <code>http://example.com/~user/cgi-bin/script.cgi</code> to the
+ path <code>/home/user/cgi-bin/script.cgi</code> and will treat
+ the resulting file as a CGI script.</p>
+
+ <h2><a id="user" name="user">User Directories</a></h2>
+
+ <p>Traditionally on Unix systems, the home directory of a
+ particular <em>user</em> can be referred to as
+ <code>~user/</code>. The module <a
+ href="mod/mod_userdir.html">mod_userdir</a> extends this idea
+ to the web by allowing files under each user's home directory
+ to be accessed using URLs such as the following.</p>
+
+ <blockquote>
+ <code>http://www.example.com/~user/file.html</code>
+ </blockquote>
+
+ <p>For security reasons, it is inappropriate to give direct
+ access to a user's home directory from the web. Therefore, the
+ <a href="mod/mod_userdir.html#userdir">UserDir</a> directive
+ specifies a directory underneath the user's home directory
+ where web files are located. Using the default setting of
+ <code>Userdir public_html</code>, the above URL maps to a file
+ at a directory like
+ <code>/home/user/public_html/file.html</code> where
+ <code>/home/user/</code> is the user's home directory as
+ specified in <code>/etc/passwd</code>.</p>
+
+ <p>There are also several other forms of the
+ <code>Userdir</code> directive which you can use on systems
+ where <code>/etc/passwd</code> does not contain the location of
+ the home directory.</p>
+
+ <p>Some people find the "~" symbol (which is often encoded on
+ the web as <code>%7e</code>) to be awkward and prefer to use an
+ alternate string to represent user directories. This
+ functionality is not supported by mod_userdir. However, if
+ users' home directories are structured in a regular way, then
+ it is possible to use the <a
+ href="mod/mod_alias.html#aliasmatch">AliasMatch</a> directive
+ to achieve the desired effect. For example, to make
+ <code>http://www.example.com/upages/user/file.html</code> map
+ to <code>/home/user/public_html/file.html</code>, use the
+ following <code>AliasMatch</code> directive:</p>
+
+ <blockquote>
+ <code>AliasMatch ^/upages/([^/]*)/?(.*)
+ /home/$1/public_html/$2</code>
+ </blockquote>
+
+ <h2><a id="redirect" name="redirect">URL Redirection</a></h2>
+
+ <p>The configuration directives discussed in the above sections
+ tell Apache to get content from a specific place in the
+ filesystem and return it to the client. Sometimes, it is
+ desirable instead to inform the client that the requested
+ content is located at a different URL, and instruct the client
+ to make a new request with the new URL. This is called
+ <em>redirection</em> and is implemented by the <a
+ href="mod/mod_alias.html#redirect">Redirect</a> directive. For
+ example, if the contents of the directory <code>/foo/</code>
+ under the <code>DocumentRoot</code> are moved to the new
+ directory <code>/bar/</code>, you can instruct clients to
+ request the content at the new location as follows:</p>
+
+ <blockquote>
+ <code>Redirect permanent /foo/
+ http://www.example.com/bar/</code>
+ </blockquote>
+
+ <p>This will redirect any URL-Path starting in
+ <code>/foo/</code> to the same URL path on the
+ <code>www.example.com</code> server with <code>/bar/</code>
+ substituted for <code>/foo/</code>. You can redirect clients to
+ any server, not only the origin server.</p>
+
+ <p>Apache also provides a <a
+ href="mod/mod_alias.html#redirectmatch">RedirectMatch</a>
+ directive for more complicated rewriting problems. For example,
+ to redirect requests for the site home page to a different
+ site, but leave all other requests alone, use the following
+ configuration:</p>
+
+ <blockquote>
+ <code>RedirectMatch permanent ^/$
+ http://www.example.com/startpage.html</code>
+ </blockquote>
+
+ <p>Alternatively, to temporarily redirect all pages on a site
+ to one particular page, use the following:</p>
+
+ <blockquote>
+ <code>RedirectMatch temp .*
+ http://www.example.com/startpage.html</code>
+ </blockquote>
+
+ <h2><a id="rewrite" name="rewrite">Rewriting Engine</a></h2>
+
+ <p>When even more powerful substitution is required, the
+ rewriting engine provided by <a
+ href="mod/mod_rewrite.html">mod_rewrite</a> can be useful. The
+ directives provided by this module use characteristics of the
+ request such as browser type or source IP address in deciding
+ from where to serve content. In addition, mod_rewrite can use
+ external database files or programs to determine how to handle
+ a request. Many practical examples employing mod_rewrite are
+ discussed in the <a href="misc/rewriteguide.html">URL Rewriting
+ Guide</a>.</p>
+
+ <h2><a id="notfound" name="notfound">File Not Found</a></h2>
+
+ <p>Inevitably, URLs will be requested for which no matching
+ file can be found in the filesystem. This can happen for
+ several reasons. In some cases, it can be a result of moving
+ documents from one location to another. In this case, it is
+ best to use <a href="#redirect">URL redirection</a> to inform
+ clients of the new location of the resource. In this way, you
+ can assure that old bookmarks and links will continue to work,
+ even though the resource is at a new location.</p>
+
+ <p>Another common cause of "File Not Found" errors is
+ accidental mistyping of URLs, either directly in the browser,
+ or in HTML links. Apache provides the module <a
+ href="mod/mod_speling.html">mod_speling</a> (sic) to help with
+ this problem. When this module is activated, it will intercept
+ "File Not Found" errors and look for a resource with a similar
+ filename. If one such file is found, mod_speling will send an
+ HTTP redirect to the client informing it of the correct
+ location. If several "close" files are found, a list of
+ available alternatives will be presented to the client.</p>
+
+ <p>An especially useful feature of mod_speling, is that it will
+ compare filenames without respect to case. This can help
+ systems where users are unaware of the case-sensitive nature of
+ URLs and the unix filesystem. But using mod_speling for
+ anything more than the occasional URL correction can place
+ additional load on the server, since each "incorrect" request
+ is followed by a URL redirection and a new request from the
+ client.</p>
+
+ <p>If all attempts to locate the content fail, Apache returns
+ an error page with HTTP status code 404 (file not found). The
+ appearance of this page is controlled with the <a
+ href="mod/core.html#errordocument">ErrorDocument</a> directive
+ and can be customized in a flexible manner as discussed in the
+ <a href="custom-error.html">Custom error responses</a> and <a
+ href="misc/custom_errordocs.html">International Server Error
+ Responses</a> documents.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Mapping URLs to Filesystem Locations - Apache HTTP Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<h1 align="center">Mapping URLs to Filesystem Locations</h1>
-
-<p>This document explains how Apache uses the URL of a request to
-determine the filesystem location from which to serve a file.</p>
-
-<ul>
-<li><a href="#documentroot">DocumentRoot</a></li>
-<li><a href="#outside">Files Outside the DocumentRoot</a></li>
-<li><a href="#user">User Directories</a></li>
-<li><a href="#redirect">URL Redirection</a></li>
-<li><a href="#rewrite">Rewrite Engine</a></li>
-<li><a href="#notfound">File Not Found</a></li>
-</ul>
-
-<hr>
-
-<table border="1">
-<tr><td valign="top">
-<strong>Related Modules</strong><br><br>
-
-<a href="mod/mod_alias.html">mod_alias</a><br>
-<a href="mod/mod_rewrite.html">mod_rewrite</a><br>
-<a href="mod/mod_userdir.html">mod_userdir</a><br>
-<a href="mod/mod_speling.html">mod_speling</a><br>
-<a href="mod/mod_vhost_alias.html">mod_vhost_alias</a><br>
-
-</td><td valign="top">
-<strong>Related Directives</strong><br><br>
-
-<A HREF="mod/mod_alias.html#alias">Alias</A><br>
-<A HREF="mod/mod_alias.html#aliasmatch">AliasMatch</A><br>
-<A HREF="mod/mod_speling.html#checkspelling">CheckSpelling</A><br>
-<A HREF="mod/core.html#documentroot">DocumentRoot</A><br>
-<A HREF="mod/core.html#errordocument">ErrorDocument</A><br>
-<a href="mod/core.html#options">Options</a><br>
-<A HREF="mod/mod_alias.html#redirect">Redirect</A><br>
-<A HREF="mod/mod_alias.html#redirectmatch">RedirectMatch</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteCond">RewriteCond</A><br>
-<A HREF="mod/mod_rewrite.html#RewriteRule">RewriteRule</A><br>
-<A HREF="mod/mod_alias.html#scriptalias">ScriptAlias</A><br>
-<A HREF="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</A><br>
-<A HREF="mod/mod_userdir.html#userdir">UserDir</A><br>
-
-</td></tr></table>
-
-<h2><a name="documentroot">DocumentRoot</a></h2>
-
-<p>In deciding what file to serve for a given request, Apache's
-default behavior is to take the URL-Path for the request (the part of
-the URL following the hostname and port) and add it to the end of the
-<a href="mod/core.html#documentroot">DocumentRoot</a> specified in
-your configuration files. Therefore, the files and directories
-underneath the <code>DocumentRoot</code> make up the basic document
-tree which will be visible from the web.</p>
-
-<p>Apache is also capable of <a href="vhosts/">Virtual Hosting</a>,
-where the server receives requests for more than one host. In this
-case, a different <code>DocumentRoot</code> can be specified for each
-virtual host, or alternatively, the directives provided by the module
-<a href="mod/mod_vhost_alias.html">mod_vhost_alias</a> can be used to
-dynamically determine the appropriate place from which to serve
-content based on the requested IP address or hostname.</p>
-
-<h2><a name="outside">Files Outside the DocumentRoot</a></h2>
-
-<p>There are frequently circumstances where it is necessary to allow
-web access to parts of the filesystem that are not strictly underneath
-the <a href="mod/core.html#documentroot">DocumentRoot</a>. Apache
-offers several different ways to accomplish this. On Unix systems,
-symbolic links can bring other parts of the filesystem under the
-<code>DocumentRoot</code>. For security reasons, Apache will follow
-symbolic links only if the <a href="mod/core.html#options">Options</a>
-setting for the relevant directory includes
-<code>FollowSymLinks</code> or <code>SymLinksIfOwnerMatch</code>.</p>
-
-<p>Alternatively, the <a href="mod/mod_alias.html#alias">Alias</a>
-directive will map any part of the filesystem into the web
-space. For example, with</p>
-
-<blockquote><code>Alias /docs /var/web/
-</code></blockquote>
-
-<p>the URL <code>http://www.example.com/docs/dir/file.html</code> will
-be served from <code>/var/web/dir/file.html</code>. The <a
-href="mod/mod_alias.html#scriptalias">ScriptAlias</a> directive works
-the same way, with the additional effect that all content located at
-the target path is treated as CGI scripts.</p>
-
-<p>For situations where you require additional flexibility, you can
-use the <a href="mod/mod_alias.html#aliasmatch">AliasMatch</a> and <a
-href="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</a>
-directives to do powerful regular-expression based matching and
-substitution. For example,</p>
-
-<blockquote><code> ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*)
-/home/$1/cgi-bin/$2 </code></blockquote>
-
-<p>will map a request to
-<code>http://example.com/~user/cgi-bin/script.cgi</code> to the path
-<code>/home/user/cgi-bin/script.cgi</code> and will treat the
-resulting file as a CGI script.</p>
-
-<h2><a name="user">User Directories</a></h2>
-
-<p>Traditionally on Unix systems, the home directory of a particular
-<em>user</em> can be referred to as <code>~user/</code>. The module
-<a href="mod/mod_userdir.html">mod_userdir</a> extends this idea to
-the web by allowing files under each user's home directory to be
-accessed using URLs such as the following.</p>
-
-<blockquote><code>http://www.example.com/~user/file.html</code></blockquote>
-
-<p>For security reasons, it is inappropriate to give direct
-access to a user's home directory from the web. Therefore, the <a
-href="mod/mod_userdir.html#userdir">UserDir</a> directive
-specifies a directory underneath the user's home directory where web
-files are located. Using the default setting of <code>Userdir
-public_html</code>, the above URL maps to a file at a directory
-like <code>/home/user/public_html/file.html</code> where
-<code>/home/user/</code> is the user's home directory as specified in
-<code>/etc/passwd</code>.</p>
-
-<p>There are also several other forms of the <code>Userdir</code>
-directive which you can use on systems where <code>/etc/passwd</code>
-does not contain the location of the home directory.</p>
-
-<p>Some people find the "~" symbol (which is often encoded on the web
-as <code>%7e</code>) to be awkward and prefer to use an alternate
-string to represent user directories. This functionality is not
-supported by mod_userdir. However, if users' home directories are
-structured in a regular way, then it is possible to use the <a
-href="mod/mod_alias.html#aliasmatch">AliasMatch</a> directive to
-achieve the desired effect. For example, to make
-<code>http://www.example.com/upages/user/file.html</code> map to
-<code>/home/user/public_html/file.html</code>, use the following
-<code>AliasMatch</code> directive:</p>
-
-<blockquote><code>
-AliasMatch ^/upages/([^/]*)/?(.*) /home/$1/public_html/$2
-</code></blockquote>
-
-<h2><a name="redirect">URL Redirection</a></h2>
-
-<p>The configuration directives discussed in the above sections tell
-Apache to get content from a specific place in the filesystem and
-return it to the client. Sometimes, it is desirable instead to inform
-the client that the requested content is located at a different
-URL, and instruct the client to make a new request with the new URL.
-This is called <em>redirection</em> and is implemented by the
-<a href="mod/mod_alias.html#redirect">Redirect</a> directive. For
-example, if the contents of the directory <code>/foo/</code> under the
-<code>DocumentRoot</code> are moved to the new directory
-<code>/bar/</code>, you can instruct clients to request the content at
-the new location as follows:</p>
-
-<blockquote><code>Redirect permanent
-/foo/ http://www.example.com/bar/</code></blockquote>
-
-<p>This will redirect any URL-Path starting in <code>/foo/</code> to
-the same URL path on the <code>www.example.com</code> server with
-<code>/bar/</code> substituted for <code>/foo/</code>. You can
-redirect clients to any server, not only the origin server.</p>
-
-<p>Apache also provides a <a
-href="mod/mod_alias.html#redirectmatch">RedirectMatch</a> directive
-for more complicated rewriting problems. For example, to redirect
-requests for the site home page to a different site, but leave all
-other requests alone, use the following configuration:</p>
-
-<blockquote><code>
-RedirectMatch permanent ^/$ http://www.example.com/startpage.html
-</code></blockquote>
-
-<p>Alternatively, to temporarily redirect all pages on a site to one
-particular page, use the following:</p>
-
-<blockquote><code>
-RedirectMatch temp .* http://www.example.com/startpage.html
-</code></blockquote>
-
-<h2><a name="rewrite">Rewriting Engine</a></h2>
-
-<p>When even more powerful substitution is required, the rewriting
-engine provided by <a href="mod/mod_rewrite.html">mod_rewrite</a> can
-be useful. The directives provided by this module use
-characteristics of the request such as browser type or source IP
-address in deciding from where to serve content. In addition,
-mod_rewrite can use external database files or programs to determine
-how to handle a request. Many practical examples employing
-mod_rewrite are discussed in the <a href="misc/rewriteguide.html">URL
-Rewriting Guide</a>.</p>
-
-<h2><a name="notfound">File Not Found</a></h2>
-
-<p>Inevitably, URLs will be requested for which no matching file can
-be found in the filesystem. This can happen for several reasons. In
-some cases, it can be a result of moving documents from one location
-to another. In this case, it is best to use <a href="#redirect">URL
-redirection</a> to inform clients of the new location of the resource.
-In this way, you can assure that old bookmarks and links will continue
-to work, even though the resource is at a new location.</p>
-
-<p>Another common cause of "File Not Found" errors is accidental
-mistyping of URLs, either directly in the browser, or in HTML links.
-Apache provides the module <a href="mod/mod_speling.html">mod_speling</a>
-(sic) to help with this problem. When this module is activated, it
-will intercept "File Not Found" errors and look for a resource with a
-similar filename. If one such file is found, mod_speling will send an
-HTTP redirect to the client informing it of the correct location. If
-several "close" files are found, a list of available alternatives will
-be presented to the client.</p>
-
-<p>An especially useful feature of mod_speling, is that it will
-compare filenames without respect to case. This can help systems
-where users are unaware of the case-sensitive nature of URLs and the
-unix filesystem. But using mod_speling for anything more than the
-occasional URL correction can place additional load on the server,
-since each "incorrect" request is followed by a URL redirection and a
-new request from the client.</p>
-
-<p>If all attempts to locate the content fail, Apache returns an error
-page with HTTP status code 404 (file not found). The appearance of
-this page is controlled with the <a
-href="mod/core.html#errordocument">ErrorDocument</a> directive and can
-be customized in a flexible manner as discussed in the <a
-href="custom-error.html">Custom error responses</a> and <a
-href="misc/custom_errordocs.html">International Server Error
-Responses</a> documents.</p>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>Mapping URLs to Filesystem Locations - Apache HTTP
+ Server</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
+ vlink="#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="center">Mapping URLs to Filesystem Locations</h1>
+
+ <p>This document explains how Apache uses the URL of a request
+ to determine the filesystem location from which to serve a
+ file.</p>
+
+ <ul>
+ <li><a href="#documentroot">DocumentRoot</a></li>
+
+ <li><a href="#outside">Files Outside the
+ DocumentRoot</a></li>
+
+ <li><a href="#user">User Directories</a></li>
+
+ <li><a href="#redirect">URL Redirection</a></li>
+
+ <li><a href="#rewrite">Rewrite Engine</a></li>
+
+ <li><a href="#notfound">File Not Found</a></li>
+ </ul>
+ <hr />
+
+ <table border="1">
+ <tr>
+ <td valign="top"><strong>Related Modules</strong><br />
+ <br />
+ <a href="mod/mod_alias.html">mod_alias</a><br />
+ <a href="mod/mod_rewrite.html">mod_rewrite</a><br />
+ <a href="mod/mod_userdir.html">mod_userdir</a><br />
+ <a href="mod/mod_speling.html">mod_speling</a><br />
+ <a
+ href="mod/mod_vhost_alias.html">mod_vhost_alias</a><br />
+ </td>
+
+ <td valign="top"><strong>Related Directives</strong><br />
+ <br />
+ <a href="mod/mod_alias.html#alias">Alias</a><br />
+ <a
+ href="mod/mod_alias.html#aliasmatch">AliasMatch</a><br />
+ <a
+ href="mod/mod_speling.html#checkspelling">CheckSpelling</a><br />
+ <a
+ href="mod/core.html#documentroot">DocumentRoot</a><br />
+ <a
+ href="mod/core.html#errordocument">ErrorDocument</a><br />
+ <a href="mod/core.html#options">Options</a><br />
+ <a href="mod/mod_alias.html#redirect">Redirect</a><br />
+ <a
+ href="mod/mod_alias.html#redirectmatch">RedirectMatch</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteCond">RewriteCond</a><br />
+ <a
+ href="mod/mod_rewrite.html#RewriteRule">RewriteRule</a><br />
+ <a
+ href="mod/mod_alias.html#scriptalias">ScriptAlias</a><br />
+ <a
+ href="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</a><br />
+ <a href="mod/mod_userdir.html#userdir">UserDir</a><br />
+ </td>
+ </tr>
+ </table>
+
+ <h2><a id="documentroot"
+ name="documentroot">DocumentRoot</a></h2>
+
+ <p>In deciding what file to serve for a given request, Apache's
+ default behavior is to take the URL-Path for the request (the
+ part of the URL following the hostname and port) and add it to
+ the end of the <a
+ href="mod/core.html#documentroot">DocumentRoot</a> specified in
+ your configuration files. Therefore, the files and directories
+ underneath the <code>DocumentRoot</code> make up the basic
+ document tree which will be visible from the web.</p>
+
+ <p>Apache is also capable of <a href="vhosts/">Virtual
+ Hosting</a>, where the server receives requests for more than
+ one host. In this case, a different <code>DocumentRoot</code>
+ can be specified for each virtual host, or alternatively, the
+ directives provided by the module <a
+ href="mod/mod_vhost_alias.html">mod_vhost_alias</a> can be used
+ to dynamically determine the appropriate place from which to
+ serve content based on the requested IP address or
+ hostname.</p>
+
+ <h2><a id="outside" name="outside">Files Outside the
+ DocumentRoot</a></h2>
+
+ <p>There are frequently circumstances where it is necessary to
+ allow web access to parts of the filesystem that are not
+ strictly underneath the <a
+ href="mod/core.html#documentroot">DocumentRoot</a>. Apache
+ offers several different ways to accomplish this. On Unix
+ systems, symbolic links can bring other parts of the filesystem
+ under the <code>DocumentRoot</code>. For security reasons,
+ Apache will follow symbolic links only if the <a
+ href="mod/core.html#options">Options</a> setting for the
+ relevant directory includes <code>FollowSymLinks</code> or
+ <code>SymLinksIfOwnerMatch</code>.</p>
+
+ <p>Alternatively, the <a
+ href="mod/mod_alias.html#alias">Alias</a> directive will map
+ any part of the filesystem into the web space. For example,
+ with</p>
+
+ <blockquote>
+ <code>Alias /docs /var/web/</code>
+ </blockquote>
+
+ <p>the URL
+ <code>http://www.example.com/docs/dir/file.html</code> will be
+ served from <code>/var/web/dir/file.html</code>. The <a
+ href="mod/mod_alias.html#scriptalias">ScriptAlias</a> directive
+ works the same way, with the additional effect that all content
+ located at the target path is treated as CGI scripts.</p>
+
+ <p>For situations where you require additional flexibility, you
+ can use the <a
+ href="mod/mod_alias.html#aliasmatch">AliasMatch</a> and <a
+ href="mod/mod_alias.html#scriptaliasmatch">ScriptAliasMatch</a>
+ directives to do powerful regular-expression based matching and
+ substitution. For example,</p>
+
+ <blockquote>
+ <code>ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*)
+ /home/$1/cgi-bin/$2</code>
+ </blockquote>
+
+ <p>will map a request to
+ <code>http://example.com/~user/cgi-bin/script.cgi</code> to the
+ path <code>/home/user/cgi-bin/script.cgi</code> and will treat
+ the resulting file as a CGI script.</p>
+
+ <h2><a id="user" name="user">User Directories</a></h2>
+
+ <p>Traditionally on Unix systems, the home directory of a
+ particular <em>user</em> can be referred to as
+ <code>~user/</code>. The module <a
+ href="mod/mod_userdir.html">mod_userdir</a> extends this idea
+ to the web by allowing files under each user's home directory
+ to be accessed using URLs such as the following.</p>
+
+ <blockquote>
+ <code>http://www.example.com/~user/file.html</code>
+ </blockquote>
+
+ <p>For security reasons, it is inappropriate to give direct
+ access to a user's home directory from the web. Therefore, the
+ <a href="mod/mod_userdir.html#userdir">UserDir</a> directive
+ specifies a directory underneath the user's home directory
+ where web files are located. Using the default setting of
+ <code>Userdir public_html</code>, the above URL maps to a file
+ at a directory like
+ <code>/home/user/public_html/file.html</code> where
+ <code>/home/user/</code> is the user's home directory as
+ specified in <code>/etc/passwd</code>.</p>
+
+ <p>There are also several other forms of the
+ <code>Userdir</code> directive which you can use on systems
+ where <code>/etc/passwd</code> does not contain the location of
+ the home directory.</p>
+
+ <p>Some people find the "~" symbol (which is often encoded on
+ the web as <code>%7e</code>) to be awkward and prefer to use an
+ alternate string to represent user directories. This
+ functionality is not supported by mod_userdir. However, if
+ users' home directories are structured in a regular way, then
+ it is possible to use the <a
+ href="mod/mod_alias.html#aliasmatch">AliasMatch</a> directive
+ to achieve the desired effect. For example, to make
+ <code>http://www.example.com/upages/user/file.html</code> map
+ to <code>/home/user/public_html/file.html</code>, use the
+ following <code>AliasMatch</code> directive:</p>
+
+ <blockquote>
+ <code>AliasMatch ^/upages/([^/]*)/?(.*)
+ /home/$1/public_html/$2</code>
+ </blockquote>
+
+ <h2><a id="redirect" name="redirect">URL Redirection</a></h2>
+
+ <p>The configuration directives discussed in the above sections
+ tell Apache to get content from a specific place in the
+ filesystem and return it to the client. Sometimes, it is
+ desirable instead to inform the client that the requested
+ content is located at a different URL, and instruct the client
+ to make a new request with the new URL. This is called
+ <em>redirection</em> and is implemented by the <a
+ href="mod/mod_alias.html#redirect">Redirect</a> directive. For
+ example, if the contents of the directory <code>/foo/</code>
+ under the <code>DocumentRoot</code> are moved to the new
+ directory <code>/bar/</code>, you can instruct clients to
+ request the content at the new location as follows:</p>
+
+ <blockquote>
+ <code>Redirect permanent /foo/
+ http://www.example.com/bar/</code>
+ </blockquote>
+
+ <p>This will redirect any URL-Path starting in
+ <code>/foo/</code> to the same URL path on the
+ <code>www.example.com</code> server with <code>/bar/</code>
+ substituted for <code>/foo/</code>. You can redirect clients to
+ any server, not only the origin server.</p>
+
+ <p>Apache also provides a <a
+ href="mod/mod_alias.html#redirectmatch">RedirectMatch</a>
+ directive for more complicated rewriting problems. For example,
+ to redirect requests for the site home page to a different
+ site, but leave all other requests alone, use the following
+ configuration:</p>
+
+ <blockquote>
+ <code>RedirectMatch permanent ^/$
+ http://www.example.com/startpage.html</code>
+ </blockquote>
+
+ <p>Alternatively, to temporarily redirect all pages on a site
+ to one particular page, use the following:</p>
+
+ <blockquote>
+ <code>RedirectMatch temp .*
+ http://www.example.com/startpage.html</code>
+ </blockquote>
+
+ <h2><a id="rewrite" name="rewrite">Rewriting Engine</a></h2>
+
+ <p>When even more powerful substitution is required, the
+ rewriting engine provided by <a
+ href="mod/mod_rewrite.html">mod_rewrite</a> can be useful. The
+ directives provided by this module use characteristics of the
+ request such as browser type or source IP address in deciding
+ from where to serve content. In addition, mod_rewrite can use
+ external database files or programs to determine how to handle
+ a request. Many practical examples employing mod_rewrite are
+ discussed in the <a href="misc/rewriteguide.html">URL Rewriting
+ Guide</a>.</p>
+
+ <h2><a id="notfound" name="notfound">File Not Found</a></h2>
+
+ <p>Inevitably, URLs will be requested for which no matching
+ file can be found in the filesystem. This can happen for
+ several reasons. In some cases, it can be a result of moving
+ documents from one location to another. In this case, it is
+ best to use <a href="#redirect">URL redirection</a> to inform
+ clients of the new location of the resource. In this way, you
+ can assure that old bookmarks and links will continue to work,
+ even though the resource is at a new location.</p>
+
+ <p>Another common cause of "File Not Found" errors is
+ accidental mistyping of URLs, either directly in the browser,
+ or in HTML links. Apache provides the module <a
+ href="mod/mod_speling.html">mod_speling</a> (sic) to help with
+ this problem. When this module is activated, it will intercept
+ "File Not Found" errors and look for a resource with a similar
+ filename. If one such file is found, mod_speling will send an
+ HTTP redirect to the client informing it of the correct
+ location. If several "close" files are found, a list of
+ available alternatives will be presented to the client.</p>
+
+ <p>An especially useful feature of mod_speling, is that it will
+ compare filenames without respect to case. This can help
+ systems where users are unaware of the case-sensitive nature of
+ URLs and the unix filesystem. But using mod_speling for
+ anything more than the occasional URL correction can place
+ additional load on the server, since each "incorrect" request
+ is followed by a URL redirection and a new request from the
+ client.</p>
+
+ <p>If all attempts to locate the content fail, Apache returns
+ an error page with HTTP status code 404 (file not found). The
+ appearance of this page is controlled with the <a
+ href="mod/core.html#errordocument">ErrorDocument</a> directive
+ and can be customized in a flexible manner as discussed in the
+ <a href="custom-error.html">Custom error responses</a> and <a
+ href="misc/custom_errordocs.html">International Server Error
+ Responses</a> documents.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
projects / thirdparty / apache / httpd.git / commitdiff
