]> granicus.if.org Git - apache/commitdiff
A truly mighty mod normalising HTML tags to uppercase, and
authorKen Coar <coar@apache.org>
Mon, 26 Jan 1998 16:54:35 +0000 (16:54 +0000)
committerKen Coar <coar@apache.org>
Mon, 26 Jan 1998 16:54:35 +0000 (16:54 +0000)
'i' and 'b' to 'EM' and 'STRONG' respectively.  Been threatening
to do this for months.. no-one need try to maintain this when
writing/modifiying the docs.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80021 13f79535-47bb-0310-9956-ffa450edef68

92 files changed:
docs/manual/bind.html
docs/manual/bind.html.en
docs/manual/cgi_path.html
docs/manual/cgi_path.html.en
docs/manual/content-negotiation.html
docs/manual/content-negotiation.html.en
docs/manual/custom-error.html
docs/manual/custom-error.html.en
docs/manual/developer/API.html
docs/manual/dns-caveats.html
docs/manual/env.html
docs/manual/env.html.en
docs/manual/handler.html
docs/manual/handler.html.en
docs/manual/install.html
docs/manual/install.html.en
docs/manual/invoking.html
docs/manual/invoking.html.en
docs/manual/location.html
docs/manual/misc/API.html
docs/manual/misc/FAQ.html
docs/manual/misc/client_block_api.html
docs/manual/misc/compat_notes.html
docs/manual/misc/descriptors.html
docs/manual/misc/fin_wait_2.html
docs/manual/misc/howto.html
docs/manual/misc/index.html
docs/manual/misc/known_client_problems.html
docs/manual/misc/perf-tuning.html
docs/manual/misc/security_tips.html
docs/manual/mod/core.html
docs/manual/mod/directives.html
docs/manual/mod/index.html
docs/manual/mod/mod_access.html
docs/manual/mod/mod_actions.html
docs/manual/mod/mod_alias.html
docs/manual/mod/mod_asis.html
docs/manual/mod/mod_auth.html
docs/manual/mod/mod_auth_anon.html
docs/manual/mod/mod_auth_db.html
docs/manual/mod/mod_auth_dbm.html
docs/manual/mod/mod_autoindex.html
docs/manual/mod/mod_cern_meta.html
docs/manual/mod/mod_cgi.html
docs/manual/mod/mod_dir.html
docs/manual/mod/mod_env.html
docs/manual/mod/mod_example.html
docs/manual/mod/mod_expires.html
docs/manual/mod/mod_headers.html
docs/manual/mod/mod_imap.html
docs/manual/mod/mod_include.html
docs/manual/mod/mod_info.html
docs/manual/mod/mod_isapi.html
docs/manual/mod/mod_log_agent.html
docs/manual/mod/mod_log_config.html
docs/manual/mod/mod_log_referer.html
docs/manual/mod/mod_mime.html
docs/manual/mod/mod_mime_magic.html
docs/manual/mod/mod_negotiation.html
docs/manual/mod/mod_proxy.html
docs/manual/mod/mod_rewrite.html
docs/manual/mod/mod_speling.html
docs/manual/mod/mod_status.html
docs/manual/mod/mod_unique_id.html
docs/manual/mod/mod_userdir.html
docs/manual/mod/mod_usertrack.html
docs/manual/platform/perf-bsd44.html
docs/manual/platform/perf-dec.html
docs/manual/platform/perf-hp.html
docs/manual/platform/perf.html
docs/manual/platform/unixware.html
docs/manual/platform/windows.html
docs/manual/process-model.html
docs/manual/sections.html
docs/manual/sections.html.en
docs/manual/stopping.html
docs/manual/stopping.html.en
docs/manual/suexec.html
docs/manual/suexec.html.en
docs/manual/vhosts/details.html
docs/manual/vhosts/details_1_2.html
docs/manual/vhosts/examples.html
docs/manual/vhosts/fd-limits.html
docs/manual/vhosts/fd-limits.html.en
docs/manual/vhosts/host.html
docs/manual/vhosts/index.html
docs/manual/vhosts/index.html.en
docs/manual/vhosts/ip-based.html
docs/manual/vhosts/name-based.html
docs/manual/vhosts/name-based.html.en
docs/manual/vhosts/vhosts-in-depth.html
docs/manual/vhosts/virtual-host.html

index 2398082a14006c8fd3d4b331e2a56b1e2c5feced..3b31b437a263b17facbecdbf5e9feb0eebedc9ad 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Setting which addresses and ports Apache uses</title>
-</head>
+<HTML><HEAD>
+<TITLE>Setting which addresses and ports Apache uses</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Setting which addresses and ports Apache uses</h1>
+<h1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
 
-<hr>
+<HR>
 
 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 <tt>Port</tt> directive in the server configuration.
+as specified by the <TT>Port</TT> 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>
+responds to different IP addresses, hostnames and ports.<P>
 
 There are two directives used to restrict or specify which addresses
 and ports Apache listens to.
 
-<ul>
-<li><a href="#bindaddress">BindAddress</a> is used to restrict the server to listening to
+<UL>
+<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to listening to
   a single address, and can be used to permit multiple Apache servers
   on the same machine listening to different IP addresses.
-<li><a href="#listen">Listen</a> can be used to make a single Apache server listen
+<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server listen
   to more than one address and/or port.
-</ul>
+</UL>
 
-<h3><a name="bindaddress">BindAddress</a></h3>
-<strong>Syntax:</strong> BindAddress <em>[ * | IP-address | hostname ]</em><br>
-<strong>Default:</strong> <code>BindAddress *</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<p>
+<h3><A name="bindaddress">BindAddress</A></h3>
+<STRONG>Syntax:</STRONG> BindAddress <EM>[ * | IP-address | hostname ]</EM><BR>
+<STRONG>Default:</STRONG> <CODE>BindAddress *</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<P>
 
 Makes the server listen to just the specified address. If the argument
 is *, the server listens to all addresses. The port listened to
-is set with the <tt>Port</tt> directive. Only one BindAddress
+is set with the <TT>Port</TT> directive. Only one BindAddress
 should be used.
 
-<h3><a name="listen">Listen</a></h3>
-<strong>Syntax:</strong> Listen <em>[ port | IP-address:port ]</em><br>
-<strong>Default:</strong> <code>none</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<p>
+<h3><A name="listen">Listen</A></h3>
+<STRONG>Syntax:</STRONG> Listen <EM>[ port | IP-address:port ]</EM><BR>
+<STRONG>Default:</STRONG> <CODE>none</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<P>
 
-<tt>Listen</tt> can be used instead of <tt>BindAddress</tt> and
-<tt>Port</tt>. It tells the server to accept incoming requests on the
+<TT>Listen</TT> can be used instead of <TT>BindAddress</TT> and
+<TT>Port</TT>. It tells the server to accept incoming requests on the
 specified port or address-and-port combination. If the first format is
 used, with a port number only, the server listens to the given port on
-all interfaces, instead of the port given by the <tt>Port</tt>
+all interfaces, instead of the port given by the <TT>Port</TT>
 directive. If an IP address is given as well as a port, the server
-will listen on the given port and interface.  <p> Multiple Listen
+will listen on the given port and interface.  <P> 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>
+addresses and ports.<P>
 
 For example, to make the server accept connections on both port
 80 and port 8000, use:
-<pre>
+<PRE>
    Listen 80
    Listen 8000
-</pre>
+</PRE>
 
 To make the server accept connections on two specified
 interfaces and port numbers, use
-<pre>
+<PRE>
    Listen 192.170.2.1:80
    Listen 192.170.2.5:8000
-</pre>
+</PRE>
 
 <h2>How this works with Virtual Hosts</h2>
 
@@ -95,12 +95,12 @@ not listening to, it cannot be accessed.
 <h2>See also</h2>
 
 See also the documentation on
-<a href="vhosts/index.html">Virtual Hosts</a>,
-<a href="mod/core.html#bindaddress">BindAddress directive</a>,
-<a href="mod/core.html#port">Port directive</a>,
-<a href="dns-caveats.html">DNS Issues</a>
+<A HREF="vhosts/index.html">Virtual Hosts</A>,
+<A HREF="mod/core.html#bindaddress">BindAddress directive</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">&lt;VirtualHost&gt; section</a>.
+<A HREF="mod/core.html#virtualhost">&lt;VirtualHost&gt; section</A>.
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 2398082a14006c8fd3d4b331e2a56b1e2c5feced..3b31b437a263b17facbecdbf5e9feb0eebedc9ad 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Setting which addresses and ports Apache uses</title>
-</head>
+<HTML><HEAD>
+<TITLE>Setting which addresses and ports Apache uses</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Setting which addresses and ports Apache uses</h1>
+<h1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
 
-<hr>
+<HR>
 
 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 <tt>Port</tt> directive in the server configuration.
+as specified by the <TT>Port</TT> 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>
+responds to different IP addresses, hostnames and ports.<P>
 
 There are two directives used to restrict or specify which addresses
 and ports Apache listens to.
 
-<ul>
-<li><a href="#bindaddress">BindAddress</a> is used to restrict the server to listening to
+<UL>
+<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to listening to
   a single address, and can be used to permit multiple Apache servers
   on the same machine listening to different IP addresses.
-<li><a href="#listen">Listen</a> can be used to make a single Apache server listen
+<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server listen
   to more than one address and/or port.
-</ul>
+</UL>
 
-<h3><a name="bindaddress">BindAddress</a></h3>
-<strong>Syntax:</strong> BindAddress <em>[ * | IP-address | hostname ]</em><br>
-<strong>Default:</strong> <code>BindAddress *</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<p>
+<h3><A name="bindaddress">BindAddress</A></h3>
+<STRONG>Syntax:</STRONG> BindAddress <EM>[ * | IP-address | hostname ]</EM><BR>
+<STRONG>Default:</STRONG> <CODE>BindAddress *</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<P>
 
 Makes the server listen to just the specified address. If the argument
 is *, the server listens to all addresses. The port listened to
-is set with the <tt>Port</tt> directive. Only one BindAddress
+is set with the <TT>Port</TT> directive. Only one BindAddress
 should be used.
 
-<h3><a name="listen">Listen</a></h3>
-<strong>Syntax:</strong> Listen <em>[ port | IP-address:port ]</em><br>
-<strong>Default:</strong> <code>none</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<p>
+<h3><A name="listen">Listen</A></h3>
+<STRONG>Syntax:</STRONG> Listen <EM>[ port | IP-address:port ]</EM><BR>
+<STRONG>Default:</STRONG> <CODE>none</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<P>
 
-<tt>Listen</tt> can be used instead of <tt>BindAddress</tt> and
-<tt>Port</tt>. It tells the server to accept incoming requests on the
+<TT>Listen</TT> can be used instead of <TT>BindAddress</TT> and
+<TT>Port</TT>. It tells the server to accept incoming requests on the
 specified port or address-and-port combination. If the first format is
 used, with a port number only, the server listens to the given port on
-all interfaces, instead of the port given by the <tt>Port</tt>
+all interfaces, instead of the port given by the <TT>Port</TT>
 directive. If an IP address is given as well as a port, the server
-will listen on the given port and interface.  <p> Multiple Listen
+will listen on the given port and interface.  <P> 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>
+addresses and ports.<P>
 
 For example, to make the server accept connections on both port
 80 and port 8000, use:
-<pre>
+<PRE>
    Listen 80
    Listen 8000
-</pre>
+</PRE>
 
 To make the server accept connections on two specified
 interfaces and port numbers, use
-<pre>
+<PRE>
    Listen 192.170.2.1:80
    Listen 192.170.2.5:8000
-</pre>
+</PRE>
 
 <h2>How this works with Virtual Hosts</h2>
 
@@ -95,12 +95,12 @@ not listening to, it cannot be accessed.
 <h2>See also</h2>
 
 See also the documentation on
-<a href="vhosts/index.html">Virtual Hosts</a>,
-<a href="mod/core.html#bindaddress">BindAddress directive</a>,
-<a href="mod/core.html#port">Port directive</a>,
-<a href="dns-caveats.html">DNS Issues</a>
+<A HREF="vhosts/index.html">Virtual Hosts</A>,
+<A HREF="mod/core.html#bindaddress">BindAddress directive</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">&lt;VirtualHost&gt; section</a>.
+<A HREF="mod/core.html#virtualhost">&lt;VirtualHost&gt; section</A>.
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 8ac3bc0dd1914d50e6771b42bfea13dbf57b35a3..ed95efcd42a3839dfc0873948893f005f8d748df 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>PATH_INFO Changes in the CGI Environment</title>
-</head>
+<HTML><HEAD>
+<TITLE>PATH_INFO Changes in the CGI Environment</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</h1>
+<h1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</H1>
 
-<hr>
+<HR>
 
-<h2><a name="over">Overview</a></h2>
+<h2><A name="over">Overview</A></h2>
 
-<p>As implemented in Apache 1.1.1 and earlier versions, the method
+<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>).
+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>
+<h2><A name="prob">The Problem</A></h2>
 
-<p>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME
+<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>
+<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"
+</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
+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>
+crash.</P>
 
-<h2><a name="solution">The Solution</a></h2>
+<h2><A name="solution">The Solution</A></h2>
 
-<p>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by
+<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
+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>"
+"<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
+<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>
+provide <A HREF="#compat">a workaround.</A>
 
-<h2><a name="compat">Compatibility with Previous Servers</a></h2>
+<h2><A name="compat">Compatibility with Previous Servers</A></h2>
 
-<p>It may be necessary for a script that was designed for earlier
+<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>
+with Apache 1.1.1.</P>
 
-<p>A script that wishes to work with both Apache 1.2 and earlier
+<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>
+<PRE>
     $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-</pre>
+</PRE>
 
-<p>By doing this, a script can work with all servers supporting the
-CGI/1.1 specification, including all 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>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 8ac3bc0dd1914d50e6771b42bfea13dbf57b35a3..ed95efcd42a3839dfc0873948893f005f8d748df 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>PATH_INFO Changes in the CGI Environment</title>
-</head>
+<HTML><HEAD>
+<TITLE>PATH_INFO Changes in the CGI Environment</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</h1>
+<h1 ALIGN="CENTER">PATH_INFO Changes in the CGI Environment</H1>
 
-<hr>
+<HR>
 
-<h2><a name="over">Overview</a></h2>
+<h2><A name="over">Overview</A></h2>
 
-<p>As implemented in Apache 1.1.1 and earlier versions, the method
+<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>).
+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>
+<h2><A name="prob">The Problem</A></h2>
 
-<p>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME
+<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>
+<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"
+</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
+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>
+crash.</P>
 
-<h2><a name="solution">The Solution</a></h2>
+<h2><A name="solution">The Solution</A></h2>
 
-<p>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by
+<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
+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>"
+"<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
+<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>
+provide <A HREF="#compat">a workaround.</A>
 
-<h2><a name="compat">Compatibility with Previous Servers</a></h2>
+<h2><A name="compat">Compatibility with Previous Servers</A></h2>
 
-<p>It may be necessary for a script that was designed for earlier
+<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>
+with Apache 1.1.1.</P>
 
-<p>A script that wishes to work with both Apache 1.2 and earlier
+<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>
+<PRE>
     $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
-</pre>
+</PRE>
 
-<p>By doing this, a script can work with all servers supporting the
-CGI/1.1 specification, including all 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>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index c6b096a688ac239a9e694496c8c407416fd11015..2a0abb5ccde2a3ad6392e28d23e20f205a5d97c3 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Content Negotiation</h1>
+<h1 ALIGN="CENTER">Content Negotiation</H1>
 
-<p>
+<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>
+browsers which send incomplete negotiation information.  <P>
 
 Content negotiation is provided by the
-<a href="mod/mod_negotiation.html">mod_negotiation</a> module,
+<A HREF="mod/mod_negotiation.html">mod_negotiation</A> module,
 which is compiled in by default.
 
-<hr>
+<HR>
 
 <h2>About Content Negotiation</h2>
 
-<p>
+<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
@@ -44,14 +44,14 @@ 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>
+<PRE>
   Accept-Language: fr
-</pre>
+</PRE>
 
-<p>
+<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
@@ -59,54 +59,54 @@ 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>
   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>
+</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.
-<p>
+<P>
 
-The terms used in content negotiation are: a <b>resource</b> is an
+The terms used in content negotiation are: a <STRONG>resource</STRONG> is an
 item which can be requested of a server, which might be selected as
 the result of a content negotiation algorithm. If a resource is
-available in several formats, these are called <b>representations</b>
-or <b>variants</b>. The ways in which the variants for a particular
-resource vary are called the <b>dimensions</b> of negotiation.
+available in several formats, these are called <STRONG>representations</STRONG>
+or <STRONG>variants</STRONG>. The ways in which the variants for a particular
+resource vary are called the <STRONG>dimensions</STRONG> of negotiation.
 
 <h2>Negotiation in Apache</h2>
 
-<p>
+<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 (i.e., a <code>*.var</code> file) which
+<UL>
+  <LI> Using a type map (i.e., a <CODE>*.var</CODE> file) which
        names the files containing the variants explicitly
-  <li> Or using a 'MultiViews' search, where the server does an implicit
+  <LI> Or using a 'MultiViews' search, where the server does an implicit
        filename pattern match, and chooses from among the results.
-</ul>
+</UL>
 
 <h3>Using a type-map file</h3>
 
-<p>
+<P>
 A type map is a document which is associated with the handler
-named <code>type-map</code> (or, for backwards-compatibility with
+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've got to have a <code>SetHandler</code> some place which defines a
-file suffix as <code>type-map</code>; this is best done with a
-<pre>
+<CODE>application/x-type-map</CODE>).  Note that to use this feature,
+you've got to have a <CODE>SetHandler</CODE> some place which defines a
+file suffix as <CODE>type-map</CODE>; this is best done with a
+<PRE>
 
   AddHandler type-map var
 
-</pre>
-in <code>srm.conf</code>.  See comments in the sample config files for
-details. <p>
+</PRE>
+in <CODE>srm.conf</CODE>.  See comments in the sample config files for
+details. <P>
 
 Type map files have an entry for each available variant; these entries
 consist of contiguous RFC822-format header lines.  Entries for
@@ -115,7 +115,7 @@ 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:
-<pre>
+<PRE>
 
   URI: foo
 
@@ -126,12 +126,12 @@ map file is:
   URI: foo.fr.de.html
   Content-type: text/html; charset=iso-8859-2
   Content-language: fr, de
-</pre>
+</PRE>
 
 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>
   URI: foo
 
   URI: foo.jpeg
@@ -143,83 +143,83 @@ as jpeg, gif, or ASCII-art):
   URI: foo.txt
   Content-type: text/plain; qs=0.01
 
-</pre>
-<p>
+</PRE>
+<P>
 
 qs values can vary between 0.000 and 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.  <p>
+parameter value are given a qs factor of 1.0.  <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
+<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
+  <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;&nbsp;level=3</code>.
-  <dt> <code>Content-language:</code>
-  <dd> The languages of the variant, specified as an Internet standard
-       language code (e.g., <code>en</code> for English,
-       <code>kr</code> for Korean, etc.).
-  <dt> <code>Content-encoding:</code>
-  <dd> If the file is compressed, or otherwise encoded, rather than
+       <CODE>image/gif</CODE>, <CODE>text/plain</CODE>, or
+       <CODE>text/html;&nbsp;level=3</CODE>.
+  <DT> <CODE>Content-language:</CODE>
+  <DD> The languages of the variant, specified as an Internet standard
+       language code (e.g., <CODE>en</CODE> for English,
+       <CODE>kr</CODE> for Korean, etc.).
+  <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.
        For compressed files (the only case where this generally comes
        up), content encoding should be
-       <code>x-compress</code>, or <code>x-gzip</code>, as appropriate.
-  <dt> <code>Content-length:</code>
-  <dd> The size of the file.  Clients can ask to receive a given media
+       <CODE>x-compress</CODE>, or <CODE>x-gzip</CODE>, as appropriate.
+  <DT> <CODE>Content-length:</CODE>
+  <DD> The size of the file.  Clients can ask to receive a given media
        type only if the variant isn't too big; specifying a content
        length in the map allows the server to compare against these
        thresholds without checking the actual file.
-</dl>
+</DL>
 
 <h3>Multiviews</h3>
 
-<p>
+<P>
 This is a per-directory option, meaning it can be set with an
-<code>Options</code> directive within a <code>&lt;Directory&gt;</code>,
-<code>&lt;Location&gt;</code> or <code>&lt;Files&gt;</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
+<CODE>Options</CODE> directive within a <CODE>&lt;Directory&gt;</CODE>,
+<CODE>&lt;Location&gt;</CODE> or <CODE>&lt;Files&gt;</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.  (Fixing this is a one-line change to
-<code>http_core.h</code>).
+<CODE>http_core.h</CODE>).
 
-<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
+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, and forwards them along.
 
-<p>
+<P>
 
 This applies to searches for the file named by the
-<code>DirectoryIndex</code> directive, if the server is trying to
+<CODE>DirectoryIndex</CODE> directive, if the server is trying to
 index a directory; if the configuration files specify
-<pre>
+<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.
+</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>
+<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
@@ -238,7 +238,7 @@ any. To do this it calculates a quality value for each variant in each
 of the dimensions of variance. 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 in detail the algorithm used for those interested.  <p>
+explains in detail the algorithm used for those interested.  <P>
 
 In some circumstances, Apache can 'fiddle' the quality factor of a
 particular dimension to achieve a better result. The ways Apache can
@@ -246,93 +246,93 @@ fiddle quality factors is explained in more detail below.
 
 <h3>Dimensions of Negotiation</h3>
 
-<table>
-<tr><th>Dimension
-<th>Notes
-<tr><td>Media Type
-<td>Browser indicates preferences on Accept: header. Each item
+<TABLE>
+<TR><TH>Dimension
+<TH>Notes
+<TR><TD>Media Type
+<TD>Browser indicates preferences on Accept: header. Each item
 can have an associated quality factor. Variant description can also
 have a quality factor.
-<tr><td>Language
-<td>Browser indicates preferences on Accept-Language: header. Each
+<TR><TD>Language
+<TD>Browser indicates preferences on Accept-Language: header. Each
 item
 can have a quality factor. Variants can be associated with none, one
 or more languages.
-<tr><td>Encoding
-<td>Browser indicates preference with Accept-Encoding: header.
-<tr><td>Charset
-<td>Browser indicates preference with Accept-Charset: header. Variants
+<TR><TD>Encoding
+<TD>Browser indicates preference with Accept-Encoding: header.
+<TR><TD>Charset
+<TD>Browser indicates preference with Accept-Charset: header. Variants
 can indicate a charset as a parameter of the media type.
-</table>
+</TABLE>
 
 <h3>Apache Negotiation Algorithm</h3>
 
-<p>
+<P>
 Apache uses an algorithm to select the 'best' variant (if any) to
 return to the browser. This algorithm is not configurable. It operates
 like this:
 
-<ol>
-<li>
+<OL>
+<LI>
 Firstly, for each dimension of the negotiation, the appropriate
 Accept header is checked and a quality assigned to this each
 variant. If the Accept header for any dimension means 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
+<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 stage are eliminated. After each test, if only one variant
 remains, it is selected as the best match. If more than one variant
 remains, move onto the next test.
 
-<ol>
-<li>Multiply the quality factor from the Accept header with the
+<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 highest language quality factor
 
-<li>Select the variants with the best language match, using either the
-  order of languages on the <code>LanguagePriority</code> directive (if present),
+<LI>Select the variants with the best language match, using either the
+  order of languages on the <CODE>LanguagePriority</CODE> directive (if present),
   else the order of languages on the Accept-Language header.
 
-<li>Select the variants with the highest 'level' media parameter
+<LI>Select the variants with the highest 'level' media parameter
   (used to give the version of text/html media types).
 
-<li>Select only unencoded variants, if there is a mix of encoded
+<LI>Select only unencoded variants, if there is a mix of encoded
   and non-encoded variants. If either all variants are encoded
   or all variants are not encoded, select all.
 
-<li>Select only variants with acceptable charset media parameters,
+<LI>Select only variants with acceptable charset media parameters,
   as given on the Accept-Charset header line. Charset ISO-8859-1
   is always acceptable. Variants not associated with a particular
   charset are assumed to be in ISO-8859-1.
 
-<li>Select the variants with the smallest content length
+<LI>Select the variants with the smallest content length
 
-<li>Select the first variant of those remaining (this will be either the
+<LI>Select the first variant of those remaining (this will be either the
 first listed in the type-map file, or the first read from the directory)
 and go to stage 3.
 
-</ol>
+</OL>
 
-<li>The algorithm has now selected one 'best' variant, so return
+<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 non are acceptable
+<LI>To get here means no variant was selected (because non 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>
+</OL>
 
-<h2><a name="better">Fiddling with Quality Values</a></h2>
+<h2><A name="better">Fiddling with Quality Values</A></h2>
 
-<p>
+<P>
 Apache sometimes changes the quality values from what would be
 expected by a strict interpretation of the algorithm above. This is to
 get a better result from the algorithm for browsers which do not send
@@ -341,25 +341,25 @@ 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>
+<P>
 
 <h3>Media Types and Wildcards</h3>
 
-<p>
+<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>
   Accept: image/*, */*
-</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>
+<PRE>
   Accept: text/html, text/plain, image/gif, image/jpeg, */*
-</pre>
+</PRE>
 
 The intention of this is to indicate that the explicitly
 listed types are preferred, but if a different representation is
@@ -368,30 +368,30 @@ 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>
   Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-</pre>
+</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>
+<P>
 
-If the Accept: header contains <i>no</i> q factors at all, Apache sets
+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 <i>not</i> applied, so requests from browsers
+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>
+<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>
+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
@@ -400,13 +400,13 @@ 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>
+<UL>
+<LI>foo.en.html, language en
+<LI>foo.fr.html, language en
+<LI>foo.html, no language
+</UL>
 
-<p>
+<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
@@ -415,94 +415,94 @@ either en or fr as acceptable, foo.html will be returned instead.
 
 <h2>Note on hyperlinks and naming conventions</h2>
 
-<p>
+<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 <a href="mod/mod_mime.html">mod_mime</a> documentation for details).
-<p>
-A typical file has a mime-type extension (e.g. <samp>html</samp>),
-maybe an encoding extension (e.g. <samp>gz</samp> and of course a
-language extension (e.g. <samp>en</samp>) when we have different
+(see <A HREF="mod/mod_mime.html">mod_mime</A> documentation for details).
+<P>
+A typical file has a mime-type extension (e.g. <SAMP>html</SAMP>),
+maybe an encoding extension (e.g. <SAMP>gz</SAMP> and of course a
+language extension (e.g. <SAMP>en</SAMP>) when we have different
 language variants of this file.
 
-<p>
+<P>
 Examples:
-<ul>
-<li>foo.en.html
-<li>foo.html.en
-<li>foo.en.html.gz
-</ul>
+<UL>
+<LI>foo.en.html
+<LI>foo.html.en
+<LI>foo.en.html.gz
+</UL>
 
-<p>
+<P>
 Here some more examples of filenames together with valid and invalid hyperlinks:
-</p>
+</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>
+<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 (e.g. <samp>foo</samp>).
+use the name without any extensions  in an hyperlink (e.g. <SAMP>foo</SAMP>).
 The advantage is that you can hide the actual type of a
-document rsp. file and can change it later, e.g. from <samp>html</samp>
-to <samp>shtml</samp> or <samp>cgi</samp> without changing any
+document rsp. file and can change it later, e.g. 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 (e.g.
-<samp>foo.html</samp>) the language extension (including an encoding extension
+<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
-(e.g. <samp>foo.html.en</samp>).
+(e.g. <SAMP>foo.html.en</SAMP>).
 
 
 <h2>Note on Caching</h2>
 
-<p>
+<P>
 When a cache stores a document, it associates it with the request URL.
 The next time that URL is requested, the cache can use the stored
 document, provided it is still within date. But if the resource is
@@ -514,7 +514,7 @@ 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
+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
index c6b096a688ac239a9e694496c8c407416fd11015..2a0abb5ccde2a3ad6392e28d23e20f205a5d97c3 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Content Negotiation</h1>
+<h1 ALIGN="CENTER">Content Negotiation</H1>
 
-<p>
+<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>
+browsers which send incomplete negotiation information.  <P>
 
 Content negotiation is provided by the
-<a href="mod/mod_negotiation.html">mod_negotiation</a> module,
+<A HREF="mod/mod_negotiation.html">mod_negotiation</A> module,
 which is compiled in by default.
 
-<hr>
+<HR>
 
 <h2>About Content Negotiation</h2>
 
-<p>
+<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
@@ -44,14 +44,14 @@ 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>
+<PRE>
   Accept-Language: fr
-</pre>
+</PRE>
 
-<p>
+<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
@@ -59,54 +59,54 @@ 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>
   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>
+</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.
-<p>
+<P>
 
-The terms used in content negotiation are: a <b>resource</b> is an
+The terms used in content negotiation are: a <STRONG>resource</STRONG> is an
 item which can be requested of a server, which might be selected as
 the result of a content negotiation algorithm. If a resource is
-available in several formats, these are called <b>representations</b>
-or <b>variants</b>. The ways in which the variants for a particular
-resource vary are called the <b>dimensions</b> of negotiation.
+available in several formats, these are called <STRONG>representations</STRONG>
+or <STRONG>variants</STRONG>. The ways in which the variants for a particular
+resource vary are called the <STRONG>dimensions</STRONG> of negotiation.
 
 <h2>Negotiation in Apache</h2>
 
-<p>
+<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 (i.e., a <code>*.var</code> file) which
+<UL>
+  <LI> Using a type map (i.e., a <CODE>*.var</CODE> file) which
        names the files containing the variants explicitly
-  <li> Or using a 'MultiViews' search, where the server does an implicit
+  <LI> Or using a 'MultiViews' search, where the server does an implicit
        filename pattern match, and chooses from among the results.
-</ul>
+</UL>
 
 <h3>Using a type-map file</h3>
 
-<p>
+<P>
 A type map is a document which is associated with the handler
-named <code>type-map</code> (or, for backwards-compatibility with
+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've got to have a <code>SetHandler</code> some place which defines a
-file suffix as <code>type-map</code>; this is best done with a
-<pre>
+<CODE>application/x-type-map</CODE>).  Note that to use this feature,
+you've got to have a <CODE>SetHandler</CODE> some place which defines a
+file suffix as <CODE>type-map</CODE>; this is best done with a
+<PRE>
 
   AddHandler type-map var
 
-</pre>
-in <code>srm.conf</code>.  See comments in the sample config files for
-details. <p>
+</PRE>
+in <CODE>srm.conf</CODE>.  See comments in the sample config files for
+details. <P>
 
 Type map files have an entry for each available variant; these entries
 consist of contiguous RFC822-format header lines.  Entries for
@@ -115,7 +115,7 @@ 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:
-<pre>
+<PRE>
 
   URI: foo
 
@@ -126,12 +126,12 @@ map file is:
   URI: foo.fr.de.html
   Content-type: text/html; charset=iso-8859-2
   Content-language: fr, de
-</pre>
+</PRE>
 
 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>
   URI: foo
 
   URI: foo.jpeg
@@ -143,83 +143,83 @@ as jpeg, gif, or ASCII-art):
   URI: foo.txt
   Content-type: text/plain; qs=0.01
 
-</pre>
-<p>
+</PRE>
+<P>
 
 qs values can vary between 0.000 and 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.  <p>
+parameter value are given a qs factor of 1.0.  <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
+<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
+  <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;&nbsp;level=3</code>.
-  <dt> <code>Content-language:</code>
-  <dd> The languages of the variant, specified as an Internet standard
-       language code (e.g., <code>en</code> for English,
-       <code>kr</code> for Korean, etc.).
-  <dt> <code>Content-encoding:</code>
-  <dd> If the file is compressed, or otherwise encoded, rather than
+       <CODE>image/gif</CODE>, <CODE>text/plain</CODE>, or
+       <CODE>text/html;&nbsp;level=3</CODE>.
+  <DT> <CODE>Content-language:</CODE>
+  <DD> The languages of the variant, specified as an Internet standard
+       language code (e.g., <CODE>en</CODE> for English,
+       <CODE>kr</CODE> for Korean, etc.).
+  <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.
        For compressed files (the only case where this generally comes
        up), content encoding should be
-       <code>x-compress</code>, or <code>x-gzip</code>, as appropriate.
-  <dt> <code>Content-length:</code>
-  <dd> The size of the file.  Clients can ask to receive a given media
+       <CODE>x-compress</CODE>, or <CODE>x-gzip</CODE>, as appropriate.
+  <DT> <CODE>Content-length:</CODE>
+  <DD> The size of the file.  Clients can ask to receive a given media
        type only if the variant isn't too big; specifying a content
        length in the map allows the server to compare against these
        thresholds without checking the actual file.
-</dl>
+</DL>
 
 <h3>Multiviews</h3>
 
-<p>
+<P>
 This is a per-directory option, meaning it can be set with an
-<code>Options</code> directive within a <code>&lt;Directory&gt;</code>,
-<code>&lt;Location&gt;</code> or <code>&lt;Files&gt;</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
+<CODE>Options</CODE> directive within a <CODE>&lt;Directory&gt;</CODE>,
+<CODE>&lt;Location&gt;</CODE> or <CODE>&lt;Files&gt;</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.  (Fixing this is a one-line change to
-<code>http_core.h</code>).
+<CODE>http_core.h</CODE>).
 
-<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
+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, and forwards them along.
 
-<p>
+<P>
 
 This applies to searches for the file named by the
-<code>DirectoryIndex</code> directive, if the server is trying to
+<CODE>DirectoryIndex</CODE> directive, if the server is trying to
 index a directory; if the configuration files specify
-<pre>
+<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.
+</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>
+<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
@@ -238,7 +238,7 @@ any. To do this it calculates a quality value for each variant in each
 of the dimensions of variance. 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 in detail the algorithm used for those interested.  <p>
+explains in detail the algorithm used for those interested.  <P>
 
 In some circumstances, Apache can 'fiddle' the quality factor of a
 particular dimension to achieve a better result. The ways Apache can
@@ -246,93 +246,93 @@ fiddle quality factors is explained in more detail below.
 
 <h3>Dimensions of Negotiation</h3>
 
-<table>
-<tr><th>Dimension
-<th>Notes
-<tr><td>Media Type
-<td>Browser indicates preferences on Accept: header. Each item
+<TABLE>
+<TR><TH>Dimension
+<TH>Notes
+<TR><TD>Media Type
+<TD>Browser indicates preferences on Accept: header. Each item
 can have an associated quality factor. Variant description can also
 have a quality factor.
-<tr><td>Language
-<td>Browser indicates preferences on Accept-Language: header. Each
+<TR><TD>Language
+<TD>Browser indicates preferences on Accept-Language: header. Each
 item
 can have a quality factor. Variants can be associated with none, one
 or more languages.
-<tr><td>Encoding
-<td>Browser indicates preference with Accept-Encoding: header.
-<tr><td>Charset
-<td>Browser indicates preference with Accept-Charset: header. Variants
+<TR><TD>Encoding
+<TD>Browser indicates preference with Accept-Encoding: header.
+<TR><TD>Charset
+<TD>Browser indicates preference with Accept-Charset: header. Variants
 can indicate a charset as a parameter of the media type.
-</table>
+</TABLE>
 
 <h3>Apache Negotiation Algorithm</h3>
 
-<p>
+<P>
 Apache uses an algorithm to select the 'best' variant (if any) to
 return to the browser. This algorithm is not configurable. It operates
 like this:
 
-<ol>
-<li>
+<OL>
+<LI>
 Firstly, for each dimension of the negotiation, the appropriate
 Accept header is checked and a quality assigned to this each
 variant. If the Accept header for any dimension means 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
+<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 stage are eliminated. After each test, if only one variant
 remains, it is selected as the best match. If more than one variant
 remains, move onto the next test.
 
-<ol>
-<li>Multiply the quality factor from the Accept header with the
+<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 highest language quality factor
 
-<li>Select the variants with the best language match, using either the
-  order of languages on the <code>LanguagePriority</code> directive (if present),
+<LI>Select the variants with the best language match, using either the
+  order of languages on the <CODE>LanguagePriority</CODE> directive (if present),
   else the order of languages on the Accept-Language header.
 
-<li>Select the variants with the highest 'level' media parameter
+<LI>Select the variants with the highest 'level' media parameter
   (used to give the version of text/html media types).
 
-<li>Select only unencoded variants, if there is a mix of encoded
+<LI>Select only unencoded variants, if there is a mix of encoded
   and non-encoded variants. If either all variants are encoded
   or all variants are not encoded, select all.
 
-<li>Select only variants with acceptable charset media parameters,
+<LI>Select only variants with acceptable charset media parameters,
   as given on the Accept-Charset header line. Charset ISO-8859-1
   is always acceptable. Variants not associated with a particular
   charset are assumed to be in ISO-8859-1.
 
-<li>Select the variants with the smallest content length
+<LI>Select the variants with the smallest content length
 
-<li>Select the first variant of those remaining (this will be either the
+<LI>Select the first variant of those remaining (this will be either the
 first listed in the type-map file, or the first read from the directory)
 and go to stage 3.
 
-</ol>
+</OL>
 
-<li>The algorithm has now selected one 'best' variant, so return
+<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 non are acceptable
+<LI>To get here means no variant was selected (because non 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>
+</OL>
 
-<h2><a name="better">Fiddling with Quality Values</a></h2>
+<h2><A name="better">Fiddling with Quality Values</A></h2>
 
-<p>
+<P>
 Apache sometimes changes the quality values from what would be
 expected by a strict interpretation of the algorithm above. This is to
 get a better result from the algorithm for browsers which do not send
@@ -341,25 +341,25 @@ 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>
+<P>
 
 <h3>Media Types and Wildcards</h3>
 
-<p>
+<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>
   Accept: image/*, */*
-</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>
+<PRE>
   Accept: text/html, text/plain, image/gif, image/jpeg, */*
-</pre>
+</PRE>
 
 The intention of this is to indicate that the explicitly
 listed types are preferred, but if a different representation is
@@ -368,30 +368,30 @@ 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>
   Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
-</pre>
+</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>
+<P>
 
-If the Accept: header contains <i>no</i> q factors at all, Apache sets
+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 <i>not</i> applied, so requests from browsers
+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>
+<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>
+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
@@ -400,13 +400,13 @@ 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>
+<UL>
+<LI>foo.en.html, language en
+<LI>foo.fr.html, language en
+<LI>foo.html, no language
+</UL>
 
-<p>
+<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
@@ -415,94 +415,94 @@ either en or fr as acceptable, foo.html will be returned instead.
 
 <h2>Note on hyperlinks and naming conventions</h2>
 
-<p>
+<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 <a href="mod/mod_mime.html">mod_mime</a> documentation for details).
-<p>
-A typical file has a mime-type extension (e.g. <samp>html</samp>),
-maybe an encoding extension (e.g. <samp>gz</samp> and of course a
-language extension (e.g. <samp>en</samp>) when we have different
+(see <A HREF="mod/mod_mime.html">mod_mime</A> documentation for details).
+<P>
+A typical file has a mime-type extension (e.g. <SAMP>html</SAMP>),
+maybe an encoding extension (e.g. <SAMP>gz</SAMP> and of course a
+language extension (e.g. <SAMP>en</SAMP>) when we have different
 language variants of this file.
 
-<p>
+<P>
 Examples:
-<ul>
-<li>foo.en.html
-<li>foo.html.en
-<li>foo.en.html.gz
-</ul>
+<UL>
+<LI>foo.en.html
+<LI>foo.html.en
+<LI>foo.en.html.gz
+</UL>
 
-<p>
+<P>
 Here some more examples of filenames together with valid and invalid hyperlinks:
-</p>
+</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>
+<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 (e.g. <samp>foo</samp>).
+use the name without any extensions  in an hyperlink (e.g. <SAMP>foo</SAMP>).
 The advantage is that you can hide the actual type of a
-document rsp. file and can change it later, e.g. from <samp>html</samp>
-to <samp>shtml</samp> or <samp>cgi</samp> without changing any
+document rsp. file and can change it later, e.g. 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 (e.g.
-<samp>foo.html</samp>) the language extension (including an encoding extension
+<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
-(e.g. <samp>foo.html.en</samp>).
+(e.g. <SAMP>foo.html.en</SAMP>).
 
 
 <h2>Note on Caching</h2>
 
-<p>
+<P>
 When a cache stores a document, it associates it with the request URL.
 The next time that URL is requested, the cache can use the stored
 document, provided it is still within date. But if the resource is
@@ -514,7 +514,7 @@ 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
+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
index cdd4ac9b5488f72c72841a33d810e0f8fa55e922..802bd5cbe3081a678bd5a8411dffc10de8698e30 100644 (file)
   <P>To achieve this, Apache will define new CGI-like environment
      variables, e.g.
 
-  <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
+  <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.
-     <b>None</b> of these will be set if your ErrorDocument is an
-     <i>external</i> redirect (i.e. anything starting with a protocol name
-     like <code>http:</code>, even if it refers to the same host as the
-     server).<p>
+     <STRONG>None</STRONG> of these will be set if your ErrorDocument is an
+     <EM>external</EM> redirect (i.e. anything starting with a protocol name
+     like <CODE>http:</CODE>, even if it refers to the same host as the
+     server).<P>
 
 <DT>Configuration
 
@@ -85,25 +85,25 @@ REDIRECT_URL=/cgi-bin/buggy.pl <br>
 
   <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>
+  <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>
+  </CODE></BLOCKQUOTE>
 
   <P>The syntax is,
 
-  <P><code><A HREF="mod/core.html#errordocument">ErrorDocument</A></code>
+  <P><CODE><A HREF="mod/core.html#errordocument">ErrorDocument</A></CODE>
 &lt;3-digit-code&gt; action
 
   <P>where the action can be,
 
   <OL>
     <LI>Text to be displayed.  Prefix the text with a quote (&quot;). Whatever
-        follows the quote is displayed. <em>Note: the (&quot;) prefix isn't
-        displayed.</em>
+        follows the quote is displayed. <EM>Note: the (&quot;) prefix isn't
+        displayed.</EM>
 
     <LI>An external URL to redirect to.
 
@@ -121,27 +121,27 @@ ErrorDocument 401 /Subscription/how_to_subscribe.html
 <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>
+      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>
+  <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
+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, i.e. <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.
+prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>
+prefix, i.e. <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.
 
index cdd4ac9b5488f72c72841a33d810e0f8fa55e922..802bd5cbe3081a678bd5a8411dffc10de8698e30 100644 (file)
   <P>To achieve this, Apache will define new CGI-like environment
      variables, e.g.
 
-  <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
+  <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.
-     <b>None</b> of these will be set if your ErrorDocument is an
-     <i>external</i> redirect (i.e. anything starting with a protocol name
-     like <code>http:</code>, even if it refers to the same host as the
-     server).<p>
+     <STRONG>None</STRONG> of these will be set if your ErrorDocument is an
+     <EM>external</EM> redirect (i.e. anything starting with a protocol name
+     like <CODE>http:</CODE>, even if it refers to the same host as the
+     server).<P>
 
 <DT>Configuration
 
@@ -85,25 +85,25 @@ REDIRECT_URL=/cgi-bin/buggy.pl <br>
 
   <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>
+  <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>
+  </CODE></BLOCKQUOTE>
 
   <P>The syntax is,
 
-  <P><code><A HREF="mod/core.html#errordocument">ErrorDocument</A></code>
+  <P><CODE><A HREF="mod/core.html#errordocument">ErrorDocument</A></CODE>
 &lt;3-digit-code&gt; action
 
   <P>where the action can be,
 
   <OL>
     <LI>Text to be displayed.  Prefix the text with a quote (&quot;). Whatever
-        follows the quote is displayed. <em>Note: the (&quot;) prefix isn't
-        displayed.</em>
+        follows the quote is displayed. <EM>Note: the (&quot;) prefix isn't
+        displayed.</EM>
 
     <LI>An external URL to redirect to.
 
@@ -121,27 +121,27 @@ ErrorDocument 401 /Subscription/how_to_subscribe.html
 <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>
+      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>
+  <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
+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, i.e. <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.
+prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>
+prefix, i.e. <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.
 
index dba84c18d525bc2a3ced89e1320b2a3eaad88005..fdcd8737a315b68a4217415aa21b9bbb2eaac048 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache API notes</title>
-</head>
+<HTML><HEAD>
+<TITLE>Apache API notes</TITLE>
+</HEAD>
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache API notes</h1>
+<h1 ALIGN="CENTER">Apache API notes</H1>
 
 These are some notes on the Apache API and the data structures you
 have to deal with, etc.  They are not yet nearly complete, but
 hopefully, they will help you get your bearings.  Keep in mind that
 the API is still subject to change as we gain experience with it.
-(See the TODO file for what <em>might</em> be coming).  However,
+(See the TODO file for what <EM>might</EM> be coming).  However,
 it will be easy to adapt modules to any changes that are made.
 (We have more modules to adapt than you do).
-<p>
+<P>
 
 A few notes on general pedagogical style here.  In the interest of
 conciseness, all structure declarations here are incomplete --- the
@@ -28,77 +28,77 @@ real ones have more slots that I'm not telling you about.  For the
 most part, these are reserved to one component of the server core or
 another, and should be altered by modules with caution.  However, in
 some cases, they really are things I just haven't gotten around to
-yet.  Welcome to the bleeding edge.<p>
+yet.  Welcome to the bleeding edge.<P>
 
 Finally, here's an outline, to give you some bare idea of what's
 coming up, and in what order:
 
-<ul>
-<li> <a href="#basics">Basic concepts.</a>
-<menu>
- <li> <a href="#HMR">Handlers, Modules, and Requests</a>
- <li> <a href="#moduletour">A brief tour of a module</a>
-</menu>
-<li> <a href="#handlers">How handlers work</a>
-<menu>
- <li> <a href="#req_tour">A brief tour of the <code>request_rec</code></a>
- <li> <a href="#req_orig">Where request_rec structures come from</a>
- <li> <a href="#req_return">Handling requests, declining, and returning error codes</a>
- <li> <a href="#resp_handlers">Special considerations for response handlers</a>
- <li> <a href="#auth_handlers">Special considerations for authentication handlers</a>
- <li> <a href="#log_handlers">Special considerations for logging handlers</a>
-</menu>
-<li> <a href="#pools">Resource allocation and resource pools</a>
-<li> <a href="#config">Configuration, commands and the like</a>
-<menu>
- <li> <a href="#per-dir">Per-directory configuration structures</a>
- <li> <a href="#commands">Command handling</a>
- <li> <a href="#servconf">Side notes --- per-server configuration, virtual servers, etc.</a>
-</menu>
-</ul>
-
-<h2><a name="basics">Basic concepts.</a></h2>
+<UL>
+<LI> <A HREF="#basics">Basic concepts.</A>
+<MENU>
+ <LI> <A HREF="#HMR">Handlers, Modules, and Requests</A>
+ <LI> <A HREF="#moduletour">A brief tour of a module</A>
+</MENU>
+<LI> <A HREF="#handlers">How handlers work</A>
+<MENU>
+ <LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A>
+ <LI> <A HREF="#req_orig">Where request_rec structures come from</A>
+ <LI> <A HREF="#req_return">Handling requests, declining, and returning error codes</A>
+ <LI> <A HREF="#resp_handlers">Special considerations for response handlers</A>
+ <LI> <A HREF="#auth_handlers">Special considerations for authentication handlers</A>
+ <LI> <A HREF="#log_handlers">Special considerations for logging handlers</A>
+</MENU>
+<LI> <A HREF="#pools">Resource allocation and resource pools</A>
+<LI> <A HREF="#config">Configuration, commands and the like</A>
+<MENU>
+ <LI> <A HREF="#per-dir">Per-directory configuration structures</A>
+ <LI> <A HREF="#commands">Command handling</A>
+ <LI> <A HREF="#servconf">Side notes --- per-server configuration, virtual servers, etc.</A>
+</MENU>
+</UL>
+
+<h2><A name="basics">Basic concepts.</A></h2>
 
 We begin with an overview of the basic concepts behind the
 API, and how they are manifested in the code.
 
-<h3><a name="HMR">Handlers, Modules, and Requests</a></h3>
+<h3><A name="HMR">Handlers, Modules, and Requests</A></h3>
 
 Apache breaks down request handling into a series of steps, more or
 less the same way the Netscape server API does (although this API has
 a few more stages than NetSite does, as hooks for stuff I thought
 might be useful in the future).  These are:
 
-<ul>
-  <li> URI -&gt; Filename translation
-  <li> Auth ID checking [is the user who they say they are?]
-  <li> Auth access checking [is the user authorized <em>here</em>?]
-  <li> Access checking other than auth
-  <li> Determining MIME type of the object requested
-  <li> `Fixups' --- there aren't any of these yet, but the phase is
+<UL>
+  <LI> URI -&gt; Filename translation
+  <LI> Auth ID checking [is the user who they say they are?]
+  <LI> Auth access checking [is the user authorized <EM>here</EM>?]
+  <LI> Access checking other than auth
+  <LI> Determining MIME type of the object requested
+  <LI> `Fixups' --- there aren't any of these yet, but the phase is
        intended as a hook for possible extensions like
-       <code>SetEnv</code>, which don't really fit well elsewhere.
-  <li> Actually sending a response back to the client.
-  <li> Logging the request
-</ul>
+       <CODE>SetEnv</CODE>, which don't really fit well elsewhere.
+  <LI> Actually sending a response back to the client.
+  <LI> Logging the request
+</UL>
 
 These phases are handled by looking at each of a succession of
-<em>modules</em>, looking to see if each of them has a handler for the
+<EM>modules</EM>, looking to see if each of them has a handler for the
 phase, and attempting invoking it if so.  The handler can typically do
 one of three things:
 
-<ul>
-  <li> <em>Handle</em> the request, and indicate that it has done so
-       by returning the magic constant <code>OK</code>.
-  <li> <em>Decline</em> to handle the request, by returning the magic
-       integer constant <code>DECLINED</code>.  In this case, the
+<UL>
+  <LI> <EM>Handle</EM> the request, and indicate that it has done so
+       by returning the magic constant <CODE>OK</CODE>.
+  <LI> <EM>Decline</EM> to handle the request, by returning the magic
+       integer constant <CODE>DECLINED</CODE>.  In this case, the
        server behaves in all respects as if the handler simply hadn't
        been there.
-  <li> Signal an error, by returning one of the HTTP error codes.
+  <LI> Signal an error, by returning one of the HTTP error codes.
        This terminates normal handling of the request, although an
        ErrorDocument may be invoked to try to mop up, and it will be
        logged in any case.
-</ul>
+</UL>
 
 Most phases are terminated by the first module that handles them;
 however, for logging, `fixups', and non-access authentication
@@ -106,62 +106,62 @@ checking, all handlers always run (barring an error).  Also, the
 response phase is unique in that modules may declare multiple handlers
 for it, via a dispatch table keyed on the MIME type of the requested
 object.  Modules may declare a response-phase handler which can handle
-<em>any</em> request, by giving it the key <code>*/*</code> (i.e., a
+<EM>any</EM> request, by giving it the key <CODE>*/*</CODE> (i.e., a
 wildcard MIME type specification).  However, wildcard handlers are
 only invoked if the server has already tried and failed to find a more
 specific response handler for the MIME type of the requested object
-(either none existed, or they all declined).<p>
+(either none existed, or they all declined).<P>
 
 The handlers themselves are functions of one argument (a
-<code>request_rec</code> structure. vide infra), which returns an
-integer, as above.<p>
+<CODE>request_rec</CODE> structure. vide infra), which returns an
+integer, as above.<P>
 
-<h3><a name="moduletour">A brief tour of a module</a></h3>
+<h3><A name="moduletour">A brief tour of a module</A></h3>
 
 At this point, we need to explain the structure of a module.  Our
 candidate will be one of the messier ones, the CGI module --- this
-handles both CGI scripts and the <code>ScriptAlias</code> config file
+handles both CGI scripts and the <CODE>ScriptAlias</CODE> config file
 command.  It's actually a great deal more complicated than most
 modules, but if we're going to have only one example, it might as well
-be the one with its fingers in every place.<p>
+be the one with its fingers in every place.<P>
 
 Let's begin with handlers.  In order to handle the CGI scripts, the
 module declares a response handler for them. Because of
-<code>ScriptAlias</code>, it also has handlers for the name
-translation phase (to recognize <code>ScriptAlias</code>ed URIs), the
-type-checking phase (any <code>ScriptAlias</code>ed request is typed
-as a CGI script).<p>
+<CODE>ScriptAlias</CODE>, it also has handlers for the name
+translation phase (to recognize <CODE>ScriptAlias</CODE>ed URIs), the
+type-checking phase (any <CODE>ScriptAlias</CODE>ed request is typed
+as a CGI script).<P>
 
 The module needs to maintain some per (virtual)
-server information, namely, the <code>ScriptAlias</code>es in effect;
+server information, namely, the <CODE>ScriptAlias</CODE>es in effect;
 the module structure therefore contains pointers to a functions which
 builds these structures, and to another which combines two of them (in
 case the main server and a virtual server both have
-<code>ScriptAlias</code>es declared).<p>
+<CODE>ScriptAlias</CODE>es declared).<P>
 
 Finally, this module contains code to handle the
-<code>ScriptAlias</code> command itself.  This particular module only
+<CODE>ScriptAlias</CODE> command itself.  This particular module only
 declares one command, but there could be more, so modules have
-<em>command tables</em> which declare their commands, and describe
-where they are permitted, and how they are to be invoked.  <p>
+<EM>command tables</EM> which declare their commands, and describe
+where they are permitted, and how they are to be invoked.  <P>
 
 A final note on the declared types of the arguments of some of these
-commands: a <code>pool</code> is a pointer to a <em>resource pool</em>
+commands: a <CODE>pool</CODE> is a pointer to a <EM>resource pool</EM>
 structure; these are used by the server to keep track of the memory
 which has been allocated, files opened, etc., either to service a
 particular request, or to handle the process of configuring itself.
 That way, when the request is over (or, for the configuration pool,
 when the server is restarting), the memory can be freed, and the files
-closed, <i>en masse</i>, without anyone having to write explicit code to
+closed, <EM>en masse</EM>, without anyone having to write explicit code to
 track them all down and dispose of them.  Also, a
-<code>cmd_parms</code> structure contains various information about
+<CODE>cmd_parms</CODE> structure contains various information about
 the config file being read, and other status information, which is
 sometimes of use to the function which processes a config-file command
-(such as <code>ScriptAlias</code>).
+(such as <CODE>ScriptAlias</CODE>).
 
 With no further ado, the module itself:
 
-<pre>
+<PRE>
 /* Declarations of handlers. */
 
 int translate_scriptalias (request_rec *);
@@ -213,34 +213,34 @@ module cgi_module = {
    NULL,                     /* logger */
    NULL                      /* header parser */
 };
-</pre>
+</PRE>
 
-<h2><a name="handlers">How handlers work</a></h2>
+<h2><A name="handlers">How handlers work</A></h2>
 
-The sole argument to handlers is a <code>request_rec</code> structure.
+The sole argument to handlers is a <CODE>request_rec</CODE> structure.
 This structure describes a particular request which has been made to
 the server, on behalf of a client.  In most cases, each connection to
-the client generates only one <code>request_rec</code> structure.<p>
+the client generates only one <CODE>request_rec</CODE> structure.<P>
 
-<h3><a name="req_tour">A brief tour of the <code>request_rec</code></a></h3>
+<h3><A name="req_tour">A brief tour of the <CODE>request_rec</CODE></A></h3>
 
-The <code>request_rec</code> contains pointers to a resource pool
+The <CODE>request_rec</CODE> contains pointers to a resource pool
 which will be cleared when the server is finished handling the
 request; to structures containing per-server and per-connection
-information, and most importantly, information on the request itself.<p>
+information, and most importantly, information on the request itself.<P>
 
 The most important such information is a small set of character
 strings describing attributes of the object being requested, including
 its URI, filename, content-type and content-encoding (these being filled
 in by the translation and type-check handlers which handle the
-request, respectively). <p>
+request, respectively). <P>
 
 Other commonly used data items are tables giving the MIME headers on
 the client's original request, MIME headers to be sent back with the
 response (which modules can add to at will), and environment variables
 for any subprocesses which are spawned off in the course of servicing
 the request.  These tables are manipulated using the
-<code>table_get</code> and <code>table_set</code> routines. <p>
+<CODE>table_get</CODE> and <CODE>table_set</CODE> routines. <P>
 <BLOCKQUOTE>
  Note that the <SAMP>Content-type</SAMP> header value <EM>cannot</EM> be
  set by module content-handlers using the <SAMP>table_*()</SAMP>
@@ -255,17 +255,17 @@ Finally, there are pointers to two data structures which, in turn,
 point to per-module configuration structures.  Specifically, these
 hold pointers to the data structures which the module has built to
 describe the way it has been configured to operate in a given
-directory (via <code>.htaccess</code> files or
-<code>&lt;Directory&gt;</code> sections), for private data it has
+directory (via <CODE>.htaccess</CODE> files or
+<CODE>&lt;Directory&gt;</CODE> sections), for private data it has
 built in the course of servicing the request (so modules' handlers for
 one phase can pass `notes' to their handlers for other phases).  There
-is another such configuration vector in the <code>server_rec</code>
-data structure pointed to by the <code>request_rec</code>, which
-contains per (virtual) server configuration data.<p>
+is another such configuration vector in the <CODE>server_rec</CODE>
+data structure pointed to by the <CODE>request_rec</CODE>, which
+contains per (virtual) server configuration data.<P>
 
-Here is an abridged declaration, giving the fields most commonly used:<p>
+Here is an abridged declaration, giving the fields most commonly used:<P>
 
-<pre>
+<PRE>
 struct request_rec {
 
   pool *pool;
@@ -327,101 +327,101 @@ struct request_rec {
 
 };
 
-</pre>
+</PRE>
 
-<h3><a name="req_orig">Where request_rec structures come from</a></h3>
+<h3><A name="req_orig">Where request_rec structures come from</A></h3>
 
-Most <code>request_rec</code> structures are built by reading an HTTP
+Most <CODE>request_rec</CODE> structures are built by reading an HTTP
 request from a client, and filling in the fields.  However, there are
 a few exceptions:
 
-<ul>
-  <li> If the request is to an imagemap, a type map (i.e., a
-       <code>*.var</code> file), or a CGI script which returned a
+<UL>
+  <LI> If the request is to an imagemap, a type map (i.e., a
+       <CODE>*.var</CODE> file), or a CGI script which returned a
        local `Location:', then the resource which the user requested
        is going to be ultimately located by some URI other than what
        the client originally supplied.  In this case, the server does
-       an <em>internal redirect</em>, constructing a new
-       <code>request_rec</code> for the new URI, and processing it
+       an <EM>internal redirect</EM>, constructing a new
+       <CODE>request_rec</CODE> for the new URI, and processing it
        almost exactly as if the client had requested the new URI
-       directly. <p>
+       directly. <P>
 
-  <li> If some handler signaled an error, and an
-       <code>ErrorDocument</code> is in scope, the same internal
-       redirect machinery comes into play.<p>
+  <LI> If some handler signaled an error, and an
+       <CODE>ErrorDocument</CODE> is in scope, the same internal
+       redirect machinery comes into play.<P>
 
-  <li> Finally, a handler occasionally needs to investigate `what
+  <LI> Finally, a handler occasionally needs to investigate `what
        would happen if' some other request were run.  For instance,
        the directory indexing module needs to know what MIME type
        would be assigned to a request for each directory entry, in
-       order to figure out what icon to use.<p>
+       order to figure out what icon to use.<P>
 
-       Such handlers can construct a <em>sub-request</em>, using the
-       functions <code>sub_req_lookup_file</code> and
-       <code>sub_req_lookup_uri</code>; this constructs a new
-       <code>request_rec</code> structure and processes it as you
+       Such handlers can construct a <EM>sub-request</EM>, using the
+       functions <CODE>sub_req_lookup_file</CODE> and
+       <CODE>sub_req_lookup_uri</CODE>; this constructs a new
+       <CODE>request_rec</CODE> structure and processes it as you
        would expect, up to but not including the point of actually
        sending a response.  (These functions skip over the access
        checks if the sub-request is for a file in the same directory
-       as the original request).<p>
+       as the original request).<P>
 
        (Server-side includes work by building sub-requests and then
        actually invoking the response handler for them, via the
-       function <code>run_sub_request</code>).
-</ul>
+       function <CODE>run_sub_request</CODE>).
+</UL>
 
-<h3><a name="req_return">Handling requests, declining, and returning error codes</a></h3>
+<h3><A name="req_return">Handling requests, declining, and returning error codes</A></h3>
 
 As discussed above, each handler, when invoked to handle a particular
-<code>request_rec</code>, has to return an <code>int</code> to
+<CODE>request_rec</CODE>, has to return an <CODE>int</CODE> to
 indicate what happened.  That can either be
 
-<ul>
-  <li> OK --- the request was handled successfully.  This may or may
+<UL>
+  <LI> OK --- the request was handled successfully.  This may or may
        not terminate the phase.
-  <li> DECLINED --- no erroneous condition exists, but the module
+  <LI> DECLINED --- no erroneous condition exists, but the module
        declines to handle the phase; the server tries to find another.
-  <li> an HTTP error code, which aborts handling of the request.
-</ul>
+  <LI> an HTTP error code, which aborts handling of the request.
+</UL>
 
-Note that if the error code returned is <code>REDIRECT</code>, then
-the module should put a <code>Location</code> in the request's
-<code>headers_out</code>, to indicate where the client should be
-redirected <em>to</em>. <p>
+Note that if the error code returned is <CODE>REDIRECT</CODE>, then
+the module should put a <CODE>Location</CODE> in the request's
+<CODE>headers_out</CODE>, to indicate where the client should be
+redirected <EM>to</EM>. <P>
 
-<h3><a name="resp_handlers">Special considerations for response handlers</a></h3>
+<h3><A name="resp_handlers">Special considerations for response handlers</A></h3>
 
 Handlers for most phases do their work by simply setting a few fields
-in the <code>request_rec</code> structure (or, in the case of access
+in the <CODE>request_rec</CODE> structure (or, in the case of access
 checkers, simply by returning the correct error code).  However,
-response handlers have to actually send a request back to the client. <p>
+response handlers have to actually send a request back to the client. <P>
 
 They should begin by sending an HTTP response header, using the
-function <code>send_http_header</code>.  (You don't have to do
+function <CODE>send_http_header</CODE>.  (You don't have to do
 anything special to skip sending the header for HTTP/0.9 requests; the
 function figures out on its own that it shouldn't do anything).  If
-the request is marked <code>header_only</code>, that's all they should
+the request is marked <CODE>header_only</CODE>, that's all they should
 do; they should return after that, without attempting any further
-output.  <p>
+output.  <P>
 
 Otherwise, they should produce a request body which responds to the
-client as appropriate.  The primitives for this are <code>rputc</code>
-and <code>rprintf</code>, for internally generated output, and
-<code>send_fd</code>, to copy the contents of some <code>FILE *</code>
-straight to the client.  <p>
+client as appropriate.  The primitives for this are <CODE>rputc</CODE>
+and <CODE>rprintf</CODE>, for internally generated output, and
+<CODE>send_fd</CODE>, to copy the contents of some <CODE>FILE *</CODE>
+straight to the client.  <P>
 
 At this point, you should more or less understand the following piece
-of code, which is the handler which handles <code>GET</code> requests
+of code, which is the handler which handles <CODE>GET</CODE> requests
 which have no more specific handler; it also shows how conditional
-<code>GET</code>s can be handled, if it's desirable to do so in a
-particular response handler --- <code>set_last_modified</code> checks
-against the <code>If-modified-since</code> value supplied by the
+<CODE>GET</CODE>s can be handled, if it's desirable to do so in a
+particular response handler --- <CODE>set_last_modified</CODE> checks
+against the <CODE>If-modified-since</CODE> value supplied by the
 client, if any, and returns an appropriate code (which will, if
 nonzero, be USE_LOCAL_COPY).   No similar considerations apply for
-<code>set_content_length</code>, but it returns an error code for
-symmetry.<p>
+<CODE>set_content_length</CODE>, but it returns an error code for
+symmetry.<P>
 
-<pre>
+<PRE>
 int default_handler (request_rec *r)
 {
     int errstatus;
@@ -449,96 +449,96 @@ int default_handler (request_rec *r)
     pfclose (r-&gt;pool, f);
     return OK;
 }
-</pre>
+</PRE>
 
 Finally, if all of this is too much of a challenge, there are a few
 ways out of it.  First off, as shown above, a response handler which
 has not yet produced any output can simply return an error code, in
 which case the server will automatically produce an error response.
 Secondly, it can punt to some other handler by invoking
-<code>internal_redirect</code>, which is how the internal redirection
+<CODE>internal_redirect</CODE>, which is how the internal redirection
 machinery discussed above is invoked.  A response handler which has
-internally redirected should always return <code>OK</code>. <p>
+internally redirected should always return <CODE>OK</CODE>. <P>
 
-(Invoking <code>internal_redirect</code> from handlers which are
-<em>not</em> response handlers will lead to serious confusion).
+(Invoking <CODE>internal_redirect</CODE> from handlers which are
+<EM>not</EM> response handlers will lead to serious confusion).
 
-<h3><a name="auth_handlers">Special considerations for authentication handlers</a></h3>
+<h3><A name="auth_handlers">Special considerations for authentication handlers</A></h3>
 
 Stuff that should be discussed here in detail:
 
-<ul>
-  <li> Authentication-phase handlers not invoked unless auth is
+<UL>
+  <LI> Authentication-phase handlers not invoked unless auth is
        configured for the directory.
-  <li> Common auth configuration stored in the core per-dir
-       configuration; it has accessors <code>auth_type</code>,
-       <code>auth_name</code>, and <code>requires</code>.
-  <li> Common routines, to handle the protocol end of things, at least
-       for HTTP basic authentication (<code>get_basic_auth_pw</code>,
-       which sets the <code>connection-&gt;user</code> structure field
-       automatically, and <code>note_basic_auth_failure</code>, which
-       arranges for the proper <code>WWW-Authenticate:</code> header
+  <LI> Common auth configuration stored in the core per-dir
+       configuration; it has accessors <CODE>auth_type</CODE>,
+       <CODE>auth_name</CODE>, and <CODE>requires</CODE>.
+  <LI> Common routines, to handle the protocol end of things, at least
+       for HTTP basic authentication (<CODE>get_basic_auth_pw</CODE>,
+       which sets the <CODE>connection-&gt;user</CODE> structure field
+       automatically, and <CODE>note_basic_auth_failure</CODE>, which
+       arranges for the proper <CODE>WWW-Authenticate:</CODE> header
        to be sent back).
-</ul>
+</UL>
 
-<h3><a name="log_handlers">Special considerations for logging handlers</a></h3>
+<h3><A name="log_handlers">Special considerations for logging handlers</A></h3>
 
 When a request has internally redirected, there is the question of
 what to log.  Apache handles this by bundling the entire chain of
-redirects into a list of <code>request_rec</code> structures which are
-threaded through the <code>r-&gt;prev</code> and <code>r-&gt;next</code>
-pointers.  The <code>request_rec</code> which is passed to the logging
+redirects into a list of <CODE>request_rec</CODE> structures which are
+threaded through the <CODE>r-&gt;prev</CODE> and <CODE>r-&gt;next</CODE>
+pointers.  The <CODE>request_rec</CODE> which is passed to the logging
 handlers in such cases is the one which was originally built for the
 initial request from the client; note that the bytes_sent field will
 only be correct in the last request in the chain (the one for which a
 response was actually sent).
 
-<h2><a name="pools">Resource allocation and resource pools</a></h2>
+<h2><A name="pools">Resource allocation and resource pools</A></h2>
 
 One of the problems of writing and designing a server-pool server is
 that of preventing leakage, that is, allocating resources (memory,
 open files, etc.), without subsequently releasing them.  The resource
 pool machinery is designed to make it easy to prevent this from
 happening, by allowing resource to be allocated in such a way that
-they are <em>automatically</em> released when the server is done with
-them. <p>
+they are <EM>automatically</EM> released when the server is done with
+them. <P>
 
 The way this works is as follows:  the memory which is allocated, file
 opened, etc., to deal with a particular request are tied to a
-<em>resource pool</em> which is allocated for the request.  The pool
-is a data structure which itself tracks the resources in question. <p>
+<EM>resource pool</EM> which is allocated for the request.  The pool
+is a data structure which itself tracks the resources in question. <P>
 
-When the request has been processed, the pool is <em>cleared</em>.  At
+When the request has been processed, the pool is <EM>cleared</EM>.  At
 that point, all the memory associated with it is released for reuse,
 all files associated with it are closed, and any other clean-up
 functions which are associated with the pool are run.  When this is
 over, we can be confident that all the resource tied to the pool have
-been released, and that none of them have leaked. <p>
+been released, and that none of them have leaked. <P>
 
 Server restarts, and allocation of memory and resources for per-server
 configuration, are handled in a similar way.  There is a
-<em>configuration pool</em>, which keeps track of resources which were
+<EM>configuration pool</EM>, which keeps track of resources which were
 allocated while reading the server configuration files, and handling
 the commands therein (for instance, the memory that was allocated for
 per-server module configuration, log files and other files that were
 opened, and so forth).  When the server restarts, and has to reread
 the configuration files, the configuration pool is cleared, and so the
 memory and file descriptors which were taken up by reading them the
-last time are made available for reuse. <p>
+last time are made available for reuse. <P>
 
 It should be noted that use of the pool machinery isn't generally
 obligatory, except for situations like logging handlers, where you
 really need to register cleanups to make sure that the log file gets
 closed when the server restarts (this is most easily done by using the
-function <code><a href="#pool-files">pfopen</a></code>, which also
+function <CODE><A HREF="#pool-files">pfopen</A></CODE>, which also
 arranges for the underlying file descriptor to be closed before any
-child processes, such as for CGI scripts, are <code>exec</code>ed), or
+child processes, such as for CGI scripts, are <CODE>exec</CODE>ed), or
 in case you are using the timeout machinery (which isn't yet even
 documented here).  However, there are two benefits to using it:
 resources allocated to a pool never leak (even if you allocate a
 scratch string, and just forget about it); also, for memory
-allocation, <code>palloc</code> is generally faster than
-<code>malloc</code>.<p>
+allocation, <CODE>palloc</CODE> is generally faster than
+<CODE>malloc</CODE>.<P>
 
 We begin here by describing how memory is allocated to pools, and then
 discuss how other resources are tracked by the resource pool
@@ -547,15 +547,15 @@ machinery.
 <h3>Allocation of memory in pools</h3>
 
 Memory is allocated to pools by calling the function
-<code>palloc</code>, which takes two arguments, one being a pointer to
+<CODE>palloc</CODE>, which takes two arguments, one being a pointer to
 a resource pool structure, and the other being the amount of memory to
-allocate (in <code>char</code>s).  Within handlers for handling
+allocate (in <CODE>char</CODE>s).  Within handlers for handling
 requests, the most common way of getting a resource pool structure is
-by looking at the <code>pool</code> slot of the relevant
-<code>request_rec</code>; hence the repeated appearance of the
+by looking at the <CODE>pool</CODE> slot of the relevant
+<CODE>request_rec</CODE>; hence the repeated appearance of the
 following idiom in module code:
 
-<pre>
+<PRE>
 int my_handler(request_rec *r)
 {
     struct my_structure *foo;
@@ -563,20 +563,20 @@ int my_handler(request_rec *r)
 
     foo = (foo *)palloc (r-&gt;pool, sizeof(my_structure));
 }
-</pre>
+</PRE>
 
-Note that <em>there is no <code>pfree</code></em> ---
-<code>palloc</code>ed memory is freed only when the associated
-resource pool is cleared.  This means that <code>palloc</code> does not
-have to do as much accounting as <code>malloc()</code>; all it does in
+Note that <EM>there is no <CODE>pfree</CODE></EM> ---
+<CODE>palloc</CODE>ed memory is freed only when the associated
+resource pool is cleared.  This means that <CODE>palloc</CODE> does not
+have to do as much accounting as <CODE>malloc()</CODE>; all it does in
 the typical case is to round up the size, bump a pointer, and do a
-range check.<p>
+range check.<P>
 
-(It also raises the possibility that heavy use of <code>palloc</code>
+(It also raises the possibility that heavy use of <CODE>palloc</CODE>
 could cause a server process to grow excessively large.  There are
 two ways to deal with this, which are dealt with below; briefly, you
-can use <code>malloc</code>, and try to be sure that all of the memory
-gets explicitly <code>free</code>d, or you can allocate a sub-pool of
+can use <CODE>malloc</CODE>, and try to be sure that all of the memory
+gets explicitly <CODE>free</CODE>d, or you can allocate a sub-pool of
 the main pool, allocate your memory in the sub-pool, and clear it out
 periodically.  The latter technique is discussed in the section on
 sub-pools below, and is used in the directory-indexing code, in order
@@ -586,107 +586,107 @@ thousands of files).
 <h3>Allocating initialized memory</h3>
 
 There are functions which allocate initialized memory, and are
-frequently useful.  The function <code>pcalloc</code> has the same
-interface as <code>palloc</code>, but clears out the memory it
-allocates before it returns it.  The function <code>pstrdup</code>
-takes a resource pool and a <code>char *</code> as arguments, and
+frequently useful.  The function <CODE>pcalloc</CODE> has the same
+interface as <CODE>palloc</CODE>, but clears out the memory it
+allocates before it returns it.  The function <CODE>pstrdup</CODE>
+takes a resource pool and a <CODE>char *</CODE> as arguments, and
 allocates memory for a copy of the string the pointer points to,
-returning a pointer to the copy.  Finally <code>pstrcat</code> is a
+returning a pointer to the copy.  Finally <CODE>pstrcat</CODE> is a
 varargs-style function, which takes a pointer to a resource pool, and
-at least two <code>char *</code> arguments, the last of which must be
-<code>NULL</code>.  It allocates enough memory to fit copies of each
+at least two <CODE>char *</CODE> arguments, the last of which must be
+<CODE>NULL</CODE>.  It allocates enough memory to fit copies of each
 of the strings, as a unit; for instance:
 
-<pre>
+<PRE>
      pstrcat (r-&gt;pool, "foo", "/", "bar", NULL);
-</pre>
+</PRE>
 
 returns a pointer to 8 bytes worth of memory, initialized to
-<code>"foo/bar"</code>.
+<CODE>"foo/bar"</CODE>.
 
-<h3><a name="pool-files">Tracking open files, etc.</a></h3>
+<h3><A name="pool-files">Tracking open files, etc.</A></h3>
 
 As indicated above, resource pools are also used to track other sorts
 of resources besides memory.  The most common are open files.  The
-routine which is typically used for this is <code>pfopen</code>, which
+routine which is typically used for this is <CODE>pfopen</CODE>, which
 takes a resource pool and two strings as arguments; the strings are
-the same as the typical arguments to <code>fopen</code>, e.g.,
+the same as the typical arguments to <CODE>fopen</CODE>, e.g.,
 
-<pre>
+<PRE>
      ...
      FILE *f = pfopen (r-&gt;pool, r-&gt;filename, "r");
 
      if (f == NULL) { ... } else { ... }
-</pre>
+</PRE>
 
-There is also a <code>popenf</code> routine, which parallels the
-lower-level <code>open</code> system call.  Both of these routines
+There is also a <CODE>popenf</CODE> routine, which parallels the
+lower-level <CODE>open</CODE> system call.  Both of these routines
 arrange for the file to be closed when the resource pool in question
-is cleared.  <p>
+is cleared.  <P>
 
-Unlike the case for memory, there <em>are</em> functions to close
-files allocated with <code>pfopen</code>, and <code>popenf</code>,
-namely <code>pfclose</code> and <code>pclosef</code>.  (This is
+Unlike the case for memory, there <EM>are</EM> functions to close
+files allocated with <CODE>pfopen</CODE>, and <CODE>popenf</CODE>,
+namely <CODE>pfclose</CODE> and <CODE>pclosef</CODE>.  (This is
 because, on many systems, the number of files which a single process
 can have open is quite limited).  It is important to use these
-functions to close files allocated with <code>pfopen</code> and
-<code>popenf</code>, since to do otherwise could cause fatal errors on
+functions to close files allocated with <CODE>pfopen</CODE> and
+<CODE>popenf</CODE>, since to do otherwise could cause fatal errors on
 systems such as Linux, which react badly if the same
-<code>FILE*</code> is closed more than once. <p>
+<CODE>FILE*</CODE> is closed more than once. <P>
 
-(Using the <code>close</code> functions is not mandatory, since the
+(Using the <CODE>close</CODE> functions is not mandatory, since the
 file will eventually be closed regardless, but you should consider it
 in cases where your module is opening, or could open, a lot of files).
 
 <h3>Other sorts of resources --- cleanup functions</h3>
 
 More text goes here.  Describe the the cleanup primitives in terms of
-which the file stuff is implemented; also, <code>spawn_process</code>.
+which the file stuff is implemented; also, <CODE>spawn_process</CODE>.
 
 <h3>Fine control --- creating and dealing with sub-pools, with a note
 on sub-requests</h3>
 
-On rare occasions, too-free use of <code>palloc()</code> and the
+On rare occasions, too-free use of <CODE>palloc()</CODE> and the
 associated primitives may result in undesirably profligate resource
 allocation.  You can deal with such a case by creating a
-<em>sub-pool</em>, allocating within the sub-pool rather than the main
+<EM>sub-pool</EM>, allocating within the sub-pool rather than the main
 pool, and clearing or destroying the sub-pool, which releases the
-resources which were associated with it.  (This really <em>is</em> a
+resources which were associated with it.  (This really <EM>is</EM> a
 rare situation; the only case in which it comes up in the standard
 module set is in case of listing directories, and then only with
-<em>very</em> large directories.  Unnecessary use of the primitives
+<EM>very</EM> large directories.  Unnecessary use of the primitives
 discussed here can hair up your code quite a bit, with very little
-gain). <p>
+gain). <P>
 
-The primitive for creating a sub-pool is <code>make_sub_pool</code>,
+The primitive for creating a sub-pool is <CODE>make_sub_pool</CODE>,
 which takes another pool (the parent pool) as an argument.  When the
 main pool is cleared, the sub-pool will be destroyed.  The sub-pool
 may also be cleared or destroyed at any time, by calling the functions
-<code>clear_pool</code> and <code>destroy_pool</code>, respectively.
-(The difference is that <code>clear_pool</code> frees resources
-associated with the pool, while <code>destroy_pool</code> also
+<CODE>clear_pool</CODE> and <CODE>destroy_pool</CODE>, respectively.
+(The difference is that <CODE>clear_pool</CODE> frees resources
+associated with the pool, while <CODE>destroy_pool</CODE> also
 deallocates the pool itself.  In the former case, you can allocate new
 resources within the pool, and clear it again, and so forth; in the
-latter case, it is simply gone). <p>
+latter case, it is simply gone). <P>
 
 One final note --- sub-requests have their own resource pools, which
 are sub-pools of the resource pool for the main request.  The polite
 way to reclaim the resources associated with a sub request which you
-have allocated (using the <code>sub_req_lookup_...</code> functions)
-is <code>destroy_sub_request</code>, which frees the resource pool.
+have allocated (using the <CODE>sub_req_lookup_...</CODE> functions)
+is <CODE>destroy_sub_request</CODE>, which frees the resource pool.
 Before calling this function, be sure to copy anything that you care
 about which might be allocated in the sub-request's resource pool into
 someplace a little less volatile (for instance, the filename in its
-<code>request_rec</code> structure). <p>
+<CODE>request_rec</CODE> structure). <P>
 
 (Again, under most circumstances, you shouldn't feel obliged to call
 this function; only 2K of memory or so are allocated for a typical sub
 request, and it will be freed anyway when the main request pool is
 cleared.  It is only when you are allocating many, many sub-requests
 for a single main request that you should seriously consider the
-<code>destroy...</code> functions).
+<CODE>destroy...</CODE> functions).
 
-<h2><a name="config">Configuration, commands and the like</a></h2>
+<h2><A name="config">Configuration, commands and the like</A></h2>
 
 One of the design goals for this server was to maintain external
 compatibility with the NCSA 1.3 server --- that is, to read the same
@@ -696,7 +696,7 @@ hand, another design goal was to move as much of the server's
 functionality into modules which have as little as possible to do with
 the monolithic server core.  The only way to reconcile these goals is
 to move the handling of most commands from the central server into the
-modules.  <p>
+modules.  <P>
 
 However, just giving the modules command tables is not enough to
 divorce them completely from the server core.  The server has to
@@ -705,77 +705,77 @@ maintaining data which is private to the modules, and which can be
 either per-server, or per-directory.  Most things are per-directory,
 including in particular access control and authorization information,
 but also information on how to determine file types from suffixes,
-which can be modified by <code>AddType</code> and
-<code>DefaultType</code> directives, and so forth.  In general, the
-governing philosophy is that anything which <em>can</em> be made
+which can be modified by <CODE>AddType</CODE> and
+<CODE>DefaultType</CODE> directives, and so forth.  In general, the
+governing philosophy is that anything which <EM>can</EM> be made
 configurable by directory should be; per-server information is
 generally used in the standard set of modules for information like
-<code>Alias</code>es and <code>Redirect</code>s which come into play
+<CODE>Alias</CODE>es and <CODE>Redirect</CODE>s which come into play
 before the request is tied to a particular place in the underlying
-file system. <p>
+file system. <P>
 
 Another requirement for emulating the NCSA server is being able to
 handle the per-directory configuration files, generally called
-<code>.htaccess</code> files, though even in the NCSA server they can
+<CODE>.htaccess</CODE> files, though even in the NCSA server they can
 contain directives which have nothing at all to do with access
 control.  Accordingly, after URI -&gt; filename translation, but before
 performing any other phase, the server walks down the directory
 hierarchy of the underlying filesystem, following the translated
-pathname, to read any <code>.htaccess</code> files which might be
+pathname, to read any <CODE>.htaccess</CODE> files which might be
 present.  The information which is read in then has to be
-<em>merged</em> with the applicable information from the server's own
-config files (either from the <code>&lt;Directory&gt;</code> sections
-in <code>access.conf</code>, or from defaults in
-<code>srm.conf</code>, which actually behaves for most purposes almost
-exactly like <code>&lt;Directory /&gt;</code>).<p>
+<EM>merged</EM> with the applicable information from the server's own
+config files (either from the <CODE>&lt;Directory&gt;</CODE> sections
+in <CODE>access.conf</CODE>, or from defaults in
+<CODE>srm.conf</CODE>, which actually behaves for most purposes almost
+exactly like <CODE>&lt;Directory /&gt;</CODE>).<P>
 
 Finally, after having served a request which involved reading
-<code>.htaccess</code> files, we need to discard the storage allocated
+<CODE>.htaccess</CODE> files, we need to discard the storage allocated
 for handling them.  That is solved the same way it is solved wherever
 else similar problems come up, by tying those structures to the
-per-transaction resource pool.  <p>
+per-transaction resource pool.  <P>
 
-<h3><a name="per-dir">Per-directory configuration structures</a></h3>
+<h3><A name="per-dir">Per-directory configuration structures</A></h3>
 
-Let's look out how all of this plays out in <code>mod_mime.c</code>,
+Let's look out how all of this plays out in <CODE>mod_mime.c</CODE>,
 which defines the file typing handler which emulates the NCSA server's
 behavior of determining file types from suffixes.  What we'll be
 looking at, here, is the code which implements the
-<code>AddType</code> and <code>AddEncoding</code> commands.  These
-commands can appear in <code>.htaccess</code> files, so they must be
+<CODE>AddType</CODE> and <CODE>AddEncoding</CODE> commands.  These
+commands can appear in <CODE>.htaccess</CODE> files, so they must be
 handled in the module's private per-directory data, which in fact,
-consists of two separate <code>table</code>s for MIME types and
+consists of two separate <CODE>table</CODE>s for MIME types and
 encoding information, and is declared as follows:
 
-<pre>
+<PRE>
 typedef struct {
     table *forced_types;      /* Additional AddTyped stuff */
     table *encoding_types;    /* Added with AddEncoding... */
 } mime_dir_config;
-</pre>
+</PRE>
 
 When the server is reading a configuration file, or
-<code>&lt;Directory&gt;</code> section, which includes one of the MIME
-module's commands, it needs to create a <code>mime_dir_config</code>
+<CODE>&lt;Directory&gt;</CODE> section, which includes one of the MIME
+module's commands, it needs to create a <CODE>mime_dir_config</CODE>
 structure, so those commands have something to act on.  It does this
 by invoking the function it finds in the module's `create per-dir
 config slot', with two arguments: the name of the directory to which
-this configuration information applies (or <code>NULL</code> for
-<code>srm.conf</code>), and a pointer to a resource pool in which the
-allocation should happen. <p>
+this configuration information applies (or <CODE>NULL</CODE> for
+<CODE>srm.conf</CODE>), and a pointer to a resource pool in which the
+allocation should happen. <P>
 
-(If we are reading a <code>.htaccess</code> file, that resource pool
+(If we are reading a <CODE>.htaccess</CODE> file, that resource pool
 is the per-request resource pool for the request; otherwise it is a
 resource pool which is used for configuration data, and cleared on
 restarts.  Either way, it is important for the structure being created
 to vanish when the pool is cleared, by registering a cleanup on the
-pool if necessary). <p>
+pool if necessary). <P>
 
 For the MIME module, the per-dir config creation function just
-<code>palloc</code>s the structure above, and a creates a couple of
-<code>table</code>s to fill it.  That looks like this:
+<CODE>palloc</CODE>s the structure above, and a creates a couple of
+<CODE>table</CODE>s to fill it.  That looks like this:
 
-<pre>
+<PRE>
 void *create_mime_dir_config (pool *p, char *dummy)
 {
     mime_dir_config *new =
@@ -786,15 +786,15 @@ void *create_mime_dir_config (pool *p, char *dummy)
 
     return new;
 }
-</pre>
+</PRE>
 
-Now, suppose we've just read in a <code>.htaccess</code> file.  We
+Now, suppose we've just read in a <CODE>.htaccess</CODE> file.  We
 already have the per-directory configuration structure for the next
-directory up in the hierarchy.  If the <code>.htaccess</code> file we
-just read in didn't have any <code>AddType</code> or
-<code>AddEncoding</code> commands, its per-directory config structure
+directory up in the hierarchy.  If the <CODE>.htaccess</CODE> file we
+just read in didn't have any <CODE>AddType</CODE> or
+<CODE>AddEncoding</CODE> commands, its per-directory config structure
 for the MIME module is still valid, and we can just use it.
-Otherwise, we need to merge the two structures somehow. <p>
+Otherwise, we need to merge the two structures somehow. <P>
 
 To do that, the server invokes the module's per-directory config merge
 function, if one is present.  That function takes three arguments:
@@ -803,7 +803,7 @@ allocate the result.  For the MIME module, all that needs to be done
 is overlay the tables from the new per-directory config structure with
 those from the parent:
 
-<pre>
+<PRE>
 void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
 {
     mime_dir_config *parent_dir = (mime_dir_config *)parent_dirv;
@@ -818,63 +818,63 @@ void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
 
     return new;
 }
-</pre>
+</PRE>
 
 As a note --- if there is no per-directory merge function present, the
 server will just use the subdirectory's configuration info, and ignore
 the parent's.  For some modules, that works just fine (e.g., for the
 includes module, whose per-directory configuration information
-consists solely of the state of the <code>XBITHACK</code>), and for
+consists solely of the state of the <CODE>XBITHACK</CODE>), and for
 those modules, you can just not declare one, and leave the
-corresponding structure slot in the module itself <code>NULL</code>.<p>
+corresponding structure slot in the module itself <CODE>NULL</CODE>.<P>
 
-<h3><a name="commands">Command handling</a></h3>
+<h3><A name="commands">Command handling</A></h3>
 
 Now that we have these structures, we need to be able to figure out
 how to fill them.  That involves processing the actual
-<code>AddType</code> and <code>AddEncoding</code> commands.  To find
-commands, the server looks in the module's <code>command table</code>.
+<CODE>AddType</CODE> and <CODE>AddEncoding</CODE> commands.  To find
+commands, the server looks in the module's <CODE>command table</CODE>.
 That table contains information on how many arguments the commands
 take, and in what formats, where it is permitted, and so forth.  That
 information is sufficient to allow the server to invoke most
 command-handling functions with pre-parsed arguments.  Without further
-ado, let's look at the <code>AddType</code> command handler, which
-looks like this (the <code>AddEncoding</code> command looks basically
+ado, let's look at the <CODE>AddType</CODE> command handler, which
+looks like this (the <CODE>AddEncoding</CODE> command looks basically
 the same, and won't be shown here):
 
-<pre>
+<PRE>
 char *add_type(cmd_parms *cmd, mime_dir_config *m, char *ct, char *ext)
 {
     if (*ext == '.') ++ext;
     table_set (m-&gt;forced_types, ext, ct);
     return NULL;
 }
-</pre>
+</PRE>
 
 This command handler is unusually simple.  As you can see, it takes
 four arguments, two of which are pre-parsed arguments, the third being
 the per-directory configuration structure for the module in question,
-and the fourth being a pointer to a <code>cmd_parms</code> structure.
+and the fourth being a pointer to a <CODE>cmd_parms</CODE> structure.
 That structure contains a bunch of arguments which are frequently of
 use to some, but not all, commands, including a resource pool (from
 which memory can be allocated, and to which cleanups should be tied),
 and the (virtual) server being configured, from which the module's
-per-server configuration data can be obtained if required.<p>
+per-server configuration data can be obtained if required.<P>
 
 Another way in which this particular command handler is unusually
 simple is that there are no error conditions which it can encounter.
 If there were, it could return an error message instead of
-<code>NULL</code>; this causes an error to be printed out on the
-server's <code>stderr</code>, followed by a quick exit, if it is in
-the main config files; for a <code>.htaccess</code> file, the syntax
+<CODE>NULL</CODE>; this causes an error to be printed out on the
+server's <CODE>stderr</CODE>, followed by a quick exit, if it is in
+the main config files; for a <CODE>.htaccess</CODE> file, the syntax
 error is logged in the server error log (along with an indication of
 where it came from), and the request is bounced with a server error
-response (HTTP error status, code 500). <p>
+response (HTTP error status, code 500). <P>
 
 The MIME module's command table has entries for these commands, which
 look like this:
 
-<pre>
+<PRE>
 command_rec mime_cmds[] = {
 { "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
     "a mime type followed by a file extension" },
@@ -882,54 +882,54 @@ command_rec mime_cmds[] = {
     "an encoding (e.g., gzip), followed by a file extension" },
 { NULL }
 };
-</pre>
+</PRE>
 
 The entries in these tables are:
 
-<ul>
-  <li> The name of the command
-  <li> The function which handles it
-  <li> a <code>(void *)</code> pointer, which is passed in the
-       <code>cmd_parms</code> structure to the command handler ---
+<UL>
+  <LI> The name of the command
+  <LI> The function which handles it
+  <LI> a <CODE>(void *)</CODE> pointer, which is passed in the
+       <CODE>cmd_parms</CODE> structure to the command handler ---
        this is useful in case many similar commands are handled by the
        same function.
-  <li> A bit mask indicating where the command may appear.  There are
-       mask bits corresponding to each <code>AllowOverride</code>
-       option, and an additional mask bit, <code>RSRC_CONF</code>,
+  <LI> A bit mask indicating where the command may appear.  There are
+       mask bits corresponding to each <CODE>AllowOverride</CODE>
+       option, and an additional mask bit, <CODE>RSRC_CONF</CODE>,
        indicating that the command may appear in the server's own
-       config files, but <em>not</em> in any <code>.htaccess</code>
+       config files, but <EM>not</EM> in any <CODE>.htaccess</CODE>
        file.
-  <li> A flag indicating how many arguments the command handler wants
+  <LI> A flag indicating how many arguments the command handler wants
        pre-parsed, and how they should be passed in.
-       <code>TAKE2</code> indicates two pre-parsed arguments.  Other
-       options are <code>TAKE1</code>, which indicates one pre-parsed
-       argument, <code>FLAG</code>, which indicates that the argument
-       should be <code>On</code> or <code>Off</code>, and is passed in
-       as a boolean flag, <code>RAW_ARGS</code>, which causes the
+       <CODE>TAKE2</CODE> indicates two pre-parsed arguments.  Other
+       options are <CODE>TAKE1</CODE>, which indicates one pre-parsed
+       argument, <CODE>FLAG</CODE>, which indicates that the argument
+       should be <CODE>On</CODE> or <CODE>Off</CODE>, and is passed in
+       as a boolean flag, <CODE>RAW_ARGS</CODE>, which causes the
        server to give the command the raw, unparsed arguments
        (everything but the command name itself).  There is also
-       <code>ITERATE</code>, which means that the handler looks the
-       same as <code>TAKE1</code>, but that if multiple arguments are
+       <CODE>ITERATE</CODE>, which means that the handler looks the
+       same as <CODE>TAKE1</CODE>, but that if multiple arguments are
        present, it should be called multiple times, and finally
-       <code>ITERATE2</code>, which indicates that the command handler
-       looks like a <code>TAKE2</code>, but if more arguments are
+       <CODE>ITERATE2</CODE>, which indicates that the command handler
+       looks like a <CODE>TAKE2</CODE>, but if more arguments are
        present, then it should be called multiple times, holding the
        first argument constant.
-  <li> Finally, we have a string which describes the arguments that
+  <LI> Finally, we have a string which describes the arguments that
        should be present.  If the arguments in the actual config file
        are not as required, this string will be used to help give a
        more specific error message.  (You can safely leave this
-       <code>NULL</code>).
-</ul>
+       <CODE>NULL</CODE>).
+</UL>
 
 Finally, having set this all up, we have to use it.  This is
 ultimately done in the module's handlers, specifically for its
 file-typing handler, which looks more or less like this; note that the
 per-directory configuration structure is extracted from the
-<code>request_rec</code>'s per-directory configuration vector by using
-the <code>get_module_config</code> function.
+<CODE>request_rec</CODE>'s per-directory configuration vector by using
+the <CODE>get_module_config</CODE> function.
 
-<pre>
+<PRE>
 int find_ct(request_rec *r)
 {
     int i;
@@ -965,9 +965,9 @@ int find_ct(request_rec *r)
     return OK;
 }
 
-</pre>
+</PRE>
 
-<h3><a name="servconf">Side notes --- per-server configuration, virtual servers, etc.</a></h3>
+<h3><A name="servconf">Side notes --- per-server configuration, virtual servers, etc.</A></h3>
 
 The basic ideas behind per-server module configuration are basically
 the same as those for per-directory configuration; there is a creation
@@ -976,17 +976,17 @@ virtual server has partially overridden the base server configuration,
 and a combined structure must be computed.  (As with per-directory
 configuration, the default if no merge function is specified, and a
 module is configured in some virtual server, is that the base
-configuration is simply ignored). <p>
+configuration is simply ignored). <P>
 
 The only substantial difference is that when a command needs to
 configure the per-server private module data, it needs to go to the
-<code>cmd_parms</code> data to get at it.  Here's an example, from the
+<CODE>cmd_parms</CODE> data to get at it.  Here's an example, from the
 alias module, which also indicates how a syntax error can be returned
 (note that the per-directory configuration argument to the command
 handler is declared as a dummy, since the module doesn't actually have
 per-directory config data):
 
-<pre>
+<PRE>
 char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
 {
     server_rec *s = cmd-&gt;server;
@@ -999,6 +999,6 @@ char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
     new-&gt;fake = f; new-&gt;real = url;
     return NULL;
 }
-</pre>
+</PRE>
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
index 66d0c22c99d9dcaadb0f8cf2a8ffb994b7c69146..4e9719df3b2d6344376b5f4bcb6e44886043005c 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Issues Regarding DNS and Apache</title>
-</head>
+<HTML><HEAD>
+<TITLE>Issues Regarding DNS and Apache</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Issues Regarding DNS and Apache</h1>
+<h1 ALIGN="CENTER">Issues Regarding DNS and Apache</H1>
 
-<p>This page could be summarized with the statement: <i>don't require
-Apache to use DNS for any parsing of the configuration files</i>.
+<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
@@ -25,35 +25,35 @@ from other users).
 
 Consider this configuration snippet:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost www.abc.dom&gt;
     ServerAdmin webgirl@abc.dom
     DocumentRoot /www/abc
     &lt;/VirtualHost&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<p>In order for Apache to function properly it absolutely needs
+<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>
+<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
+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 <b>will not be configured</b>.  It
+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
+<P>Suppose that <CODE>www.abc.dom</CODE> has address 10.0.0.1.  Then
 consider this configuration snippet:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost 10.0.0.1&gt;
     ServerAdmin webgirl@abc.dom
     DocumentRoot /www/abc
     &lt;/VirtualHost&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<p>Now Apache needs to use reverse DNS to find the <code>ServerName</code>
+<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
@@ -61,108 +61,108 @@ 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.
+<P>Here is a snippet that avoids both of these problems.
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost 10.0.0.1&gt;
     ServerName www.abc.dom
     ServerAdmin webgirl@abc.dom
     DocumentRoot /www/abc
     &lt;/VirtualHost&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 <h3>Denial of Service</h3>
 
-<p>There are (at least) two forms that denial of service can come in.
+<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>
+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.
+<CODE>www.abc.dom</CODE> record.
 
-<p>Another form is far more insidious.  Consider this configuration
+<P>Another form is far more insidious.  Consider this configuration
 snippet:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost www.abc.dom&gt;
     ServerAdmin webgirl@abc.dom
     DocumentRoot /www/abc
     &lt;/VirtualHost&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost www.def.dom&gt;
     ServerAdmin webguy@def.dom
     DocumentRoot /www/def
     &lt;/VirtualHost&gt;
-</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.
+</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.
+<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
+<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>.
+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
+<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
+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
+<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>
+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>.
+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
+<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
+<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>
+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>
+<h3><A name="tips">Tips to Avoid these problems</A></h3>
 
-<ul>
-<li> use IP addresses in <code>&lt;VirtualHost&gt</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>&lt;VirtualHost _default_:*&gt;</code> server that
+<UL>
+<LI> use IP addresses in <CODE>&lt;VirtualHost&gt</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>&lt;VirtualHost _default_:*&gt;</CODE> server that
     has no pages to serve
-</ul>
+</UL>
 
 <h3>Appendix: Future Directions</h3>
 
-<p>The situation regarding DNS is highly undesirable.  For Apache
+<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 <a
-href="http://www.ietf.org/html.charters/pier-charter.html">renumbering
-</a> is a necessity.
+configuration files is highly undesirable in today's Internet where <A
+HREF="http://www.ietf.org/html.charters/pier-charter.html">renumbering
+</A> is a necessity.
 
-<p>A possible work around to the theft of service attack described above
+<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
@@ -170,14 +170,14 @@ 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
+<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
+<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
index 0ea86178a670a9b39b2177902ed553dab62f806c..6fd778adaa8f7f90a79ccd47febb71f1e7821dae 100644 (file)
@@ -13,7 +13,7 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Special Purpose Environment Variables</h1>
+<h1 ALIGN="CENTER">Special Purpose Environment Variables</H1>
 <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
@@ -38,7 +38,7 @@ when given an HTTP/1.1 response, and this can be used to interoperate with
 them.
 
 <H2>downgrade-1.0</H2>
-<p>This forces the request to be treated as a HTTP/1.0 request even if it
+<P>This forces the request to be treated as a HTTP/1.0 request even if it
 was in a later dialect.
 
 <!--#include virtual="footer.html" -->
index 0ea86178a670a9b39b2177902ed553dab62f806c..6fd778adaa8f7f90a79ccd47febb71f1e7821dae 100644 (file)
@@ -13,7 +13,7 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Special Purpose Environment Variables</h1>
+<h1 ALIGN="CENTER">Special Purpose Environment Variables</H1>
 <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
@@ -38,7 +38,7 @@ when given an HTTP/1.1 response, and this can be used to interoperate with
 them.
 
 <H2>downgrade-1.0</H2>
-<p>This forces the request to be treated as a HTTP/1.0 request even if it
+<P>This forces the request to be treated as a HTTP/1.0 request even if it
 was in a later dialect.
 
 <!--#include virtual="footer.html" -->
index 80592161123d241126541551543ab96c8e54ab83..504dd09ebfa363df093d1f01735d8dfbf0e74974 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache's Handler Use</h1>
+<h1 ALIGN="CENTER">Apache's Handler Use</H1>
 
 <h2>What is a Handler</h2>
 
-<p>A "handler" is an internal Apache representation of the action to be
+<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 typed are "handled"
 separately. For example, you may use a type of
-"application/x-httpd-cgi" to invoke CGI scripts.</p>
+"application/x-httpd-cgi" to invoke CGI scripts.</P>
 
-<p>Apache 1.1 adds the additional ability to use handlers
+<P>Apache 1.1 adds the additional ability to use handlers
 explicitly. Either based on filename extensions or on location, these
 handlers are unrelated to file type. This is advantageous both because
 it is a more elegant solution, but it also allows for both a type
-<strong>and</strong> a handler to be associated with a file.</p>
+<STRONG>and</STRONG> a handler to be associated with a file.</P>
 
-<p>Handlers can either be built into the server or to 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>
+<P>Handlers can either be built into the server or to 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>send-as-is</strong>:
+<UL>
+<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>:
+    (<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>:
+    (<A HREF="mod/mod_cgi.html">mod_cgi</A>)
+<LI><STRONG>imap-file</STRONG>:
     Imagemap rule file.
-    (<a href="mod/mod_imap.html">mod_imap</a>)
-<li><strong>server-info</strong>:
+    (<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-parsed</strong>:
+    (<A HREF="mod/mod_info.html">mod_info</A>)
+<LI><STRONG>server-parsed</STRONG>:
     Parse for server-side includes
-    (<a href="mod/mod_include.html">mod_include</a>)
-<li><strong>server-status</strong>:
+    (<A HREF="mod/mod_include.html">mod_include</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>:
+    (<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>
+    (<A HREF="mod/mod_negotiation.html">mod_negotiation</A>)
+</UL>
 
-<p>
+<P>
 
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#addhandler">AddHandler</A>
-<li><A HREF="#sethandler">SetHandler</A>
-</ul>
+<UL>
+<LI><A HREF="#addhandler">AddHandler</A>
+<LI><A HREF="#sethandler">SetHandler</A>
+</UL>
 
-<hr>
+<HR>
 
-<h2><a name="addhandler">AddHandler</a></h2>
+<h2><A name="addhandler">AddHandler</A></h2>
 
-<strong>Syntax:</strong> &lt;AddHandler <em>handler-name extension</em>&gt;<br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime
+<STRONG>Syntax:</STRONG> &lt;AddHandler <EM>handler-name extension</EM>&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime
 
-<p>AddHandler maps the filename extension <em>extension</em> to the
-handler <em>handler-name</em>. For example, to activate CGI scripts
-with the file extension "<code>.cgi</code>", you might use:
-<pre>
+<P>AddHandler maps the filename extension <EM>extension</EM> to the
+handler <EM>handler-name</EM>. For example, to activate CGI scripts
+with the file extension "<CODE>.cgi</CODE>", you might use:
+<PRE>
     AddHandler cgi-script cgi
-</pre>
+</PRE>
 
-<p>Once that has been put into your srm.conf or httpd.conf file, any
-file ending with "<code>.cgi</code>" will be treated as a CGI
-program.</p>
+<P>Once that has been put into your srm.conf or httpd.conf file, any
+file ending with "<CODE>.cgi</CODE>" will be treated as a CGI
+program.</P>
 
-<hr>
+<HR>
 
-<h2><a name="sethandler">SetHandler</a></h2>
+<h2><A name="sethandler">SetHandler</A></h2>
 
-<strong>Syntax:</strong> &lt;SetHandler <em>handler-name</em>&gt;<br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime
+<STRONG>Syntax:</STRONG> &lt;SetHandler <EM>handler-name</EM>&gt;<BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime
 
-<p>When placed into an <code>.htaccess</code> file or a
-<code>&lt;Directory&gt;</code> or <code>&lt;Location&gt;</code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE>&lt;Directory&gt;</CODE> or <CODE>&lt;Location&gt;</CODE> section,
 this directive forces all matching files to be parsed through the
-handler given by <em>handler-name</em>. For example, if you had a
+handler given by <EM>handler-name</EM>. For example, if you had a
 directory you wanted to be parsed entirely as imagemap rule files,
 regardless of extension, you might put the following into an
-<code>.htaccess</code> file in that directory:
-<pre>
+<CODE>.htaccess</CODE> file in that directory:
+<PRE>
     SetHandler imap-file
-</pre>
-<p>Another example: if you wanted to have the server display a status
-report whenever a URL of <code>http://servername/status</code> was
+</PRE>
+<P>Another example: if you wanted to have the server display a status
+report whenever a URL of <CODE>http://servername/status</CODE> was
 called, you might put the following into access.conf:
-<pre>
+<PRE>
     &lt;Location /status&gt;
     SetHandler server-status
     &lt;/Location&gt;
-</pre>
+</PRE>
 
-<p><hr>
+<P><HR>
 
 <h2>Programmer's Note</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
+<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>
+<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-&gt;handler</code> to the name of the handler at any time
-prior to the <code>invoke_handler</code> stage of the
+</PRE>
+<P>If you wish to have your module engage a handler, you need only to
+set <CODE>r-&gt;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>
+type name-space.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 80592161123d241126541551543ab96c8e54ab83..504dd09ebfa363df093d1f01735d8dfbf0e74974 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache's Handler Use</h1>
+<h1 ALIGN="CENTER">Apache's Handler Use</H1>
 
 <h2>What is a Handler</h2>
 
-<p>A "handler" is an internal Apache representation of the action to be
+<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 typed are "handled"
 separately. For example, you may use a type of
-"application/x-httpd-cgi" to invoke CGI scripts.</p>
+"application/x-httpd-cgi" to invoke CGI scripts.</P>
 
-<p>Apache 1.1 adds the additional ability to use handlers
+<P>Apache 1.1 adds the additional ability to use handlers
 explicitly. Either based on filename extensions or on location, these
 handlers are unrelated to file type. This is advantageous both because
 it is a more elegant solution, but it also allows for both a type
-<strong>and</strong> a handler to be associated with a file.</p>
+<STRONG>and</STRONG> a handler to be associated with a file.</P>
 
-<p>Handlers can either be built into the server or to 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>
+<P>Handlers can either be built into the server or to 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>send-as-is</strong>:
+<UL>
+<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>:
+    (<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>:
+    (<A HREF="mod/mod_cgi.html">mod_cgi</A>)
+<LI><STRONG>imap-file</STRONG>:
     Imagemap rule file.
-    (<a href="mod/mod_imap.html">mod_imap</a>)
-<li><strong>server-info</strong>:
+    (<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-parsed</strong>:
+    (<A HREF="mod/mod_info.html">mod_info</A>)
+<LI><STRONG>server-parsed</STRONG>:
     Parse for server-side includes
-    (<a href="mod/mod_include.html">mod_include</a>)
-<li><strong>server-status</strong>:
+    (<A HREF="mod/mod_include.html">mod_include</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>:
+    (<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>
+    (<A HREF="mod/mod_negotiation.html">mod_negotiation</A>)
+</UL>
 
-<p>
+<P>
 
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#addhandler">AddHandler</A>
-<li><A HREF="#sethandler">SetHandler</A>
-</ul>
+<UL>
+<LI><A HREF="#addhandler">AddHandler</A>
+<LI><A HREF="#sethandler">SetHandler</A>
+</UL>
 
-<hr>
+<HR>
 
-<h2><a name="addhandler">AddHandler</a></h2>
+<h2><A name="addhandler">AddHandler</A></h2>
 
-<strong>Syntax:</strong> &lt;AddHandler <em>handler-name extension</em>&gt;<br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime
+<STRONG>Syntax:</STRONG> &lt;AddHandler <EM>handler-name extension</EM>&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime
 
-<p>AddHandler maps the filename extension <em>extension</em> to the
-handler <em>handler-name</em>. For example, to activate CGI scripts
-with the file extension "<code>.cgi</code>", you might use:
-<pre>
+<P>AddHandler maps the filename extension <EM>extension</EM> to the
+handler <EM>handler-name</EM>. For example, to activate CGI scripts
+with the file extension "<CODE>.cgi</CODE>", you might use:
+<PRE>
     AddHandler cgi-script cgi
-</pre>
+</PRE>
 
-<p>Once that has been put into your srm.conf or httpd.conf file, any
-file ending with "<code>.cgi</code>" will be treated as a CGI
-program.</p>
+<P>Once that has been put into your srm.conf or httpd.conf file, any
+file ending with "<CODE>.cgi</CODE>" will be treated as a CGI
+program.</P>
 
-<hr>
+<HR>
 
-<h2><a name="sethandler">SetHandler</a></h2>
+<h2><A name="sethandler">SetHandler</A></h2>
 
-<strong>Syntax:</strong> &lt;SetHandler <em>handler-name</em>&gt;<br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime
+<STRONG>Syntax:</STRONG> &lt;SetHandler <EM>handler-name</EM>&gt;<BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime
 
-<p>When placed into an <code>.htaccess</code> file or a
-<code>&lt;Directory&gt;</code> or <code>&lt;Location&gt;</code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE>&lt;Directory&gt;</CODE> or <CODE>&lt;Location&gt;</CODE> section,
 this directive forces all matching files to be parsed through the
-handler given by <em>handler-name</em>. For example, if you had a
+handler given by <EM>handler-name</EM>. For example, if you had a
 directory you wanted to be parsed entirely as imagemap rule files,
 regardless of extension, you might put the following into an
-<code>.htaccess</code> file in that directory:
-<pre>
+<CODE>.htaccess</CODE> file in that directory:
+<PRE>
     SetHandler imap-file
-</pre>
-<p>Another example: if you wanted to have the server display a status
-report whenever a URL of <code>http://servername/status</code> was
+</PRE>
+<P>Another example: if you wanted to have the server display a status
+report whenever a URL of <CODE>http://servername/status</CODE> was
 called, you might put the following into access.conf:
-<pre>
+<PRE>
     &lt;Location /status&gt;
     SetHandler server-status
     &lt;/Location&gt;
-</pre>
+</PRE>
 
-<p><hr>
+<P><HR>
 
 <h2>Programmer's Note</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
+<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>
+<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-&gt;handler</code> to the name of the handler at any time
-prior to the <code>invoke_handler</code> stage of the
+</PRE>
+<P>If you wish to have your module engage a handler, you need only to
+set <CODE>r-&gt;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>
+type name-space.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 6052841af274396a637abbd29a451a15d3b3104f..e799ad0baca8e8285caa49193f3a465b081a5a8b 100644 (file)
@@ -36,7 +36,7 @@ for how to compile the server.
 <h2>Compiling Apache</h2>
 
 Compiling Apache consists of three steps: Firstly select which Apache
-<b>modules</b> you want to include into the server. Secondly create a
+<STRONG>modules</STRONG> you want to include into the server. Secondly create a
 configuration for your operating system. Thirdly compile the
 executable.
 <P>
@@ -111,7 +111,7 @@ The modules we place in the Apache distribution are the ones we have
 tested and are used regularly by various members of the Apache
 development group.  Additional modules contributed by members or third
 parties with specific needs or functions are available at <A
-HREF="http://www.apache.org/dist/contrib/modules/">&lt;URL:http://www.apache.org/dist/contrib/modules/&gt;</a>.
+HREF="http://www.apache.org/dist/contrib/modules/">&lt;URL:http://www.apache.org/dist/contrib/modules/&gt;</A>.
 There are instructions on that page for linking these modules into the
 core Apache code.
 
@@ -126,11 +126,11 @@ designed to be configured and run from the same set of directories
 where it is compiled. If you want to run it from somewhere else, make
 a directory and copy the <CODE>conf</CODE>, <CODE>logs</CODE> and
 <CODE>icons</CODE> directories into it.  In either case you should
-read the <a href="misc/security_tips.html#serverroot">security tips</a>
+read the <A HREF="misc/security_tips.html#serverroot">security tips</A>
 describing how to set the permissions on the server root directory.<P>
 
 The next step is to edit the configuration files for the server. This
-consists of setting up various <B>directives</B> in up to three
+consists of setting up various <STRONG>directives</STRONG> in up to three
 central configuration files. By default, these files are located in
 the <CODE>conf</CODE> directory and are called <CODE>srm.conf</CODE>,
 <CODE>access.conf</CODE> and <CODE>httpd.conf</CODE>.  To help you get
@@ -188,7 +188,7 @@ port of 80, a suitable URL to enter into your browser is
 <P>
 
 Note that when the server starts it will create a number of
-<i>child</i> processes to handle the requests. If you started Apache
+<EM>child</EM> processes to handle the requests. If you started Apache
 as the root user, the parent process will continue to run as root
 while the children will change to the user as given in the httpd.conf
 file.
@@ -214,7 +214,7 @@ this will be located in the file <CODE>error_log</CODE> in the
 If you want your server to continue running after a system reboot, you
 should add a call to <CODE>httpd</CODE> to your system startup files
 (typically <CODE>rc.local</CODE> or a file in an
-<CODE>rc.<I>N</I></CODE> directory). This will start Apache as root.
+<CODE>rc.<EM>N</EM></CODE> directory). This will start Apache as root.
 Before doing this ensure that your server is properly configured
 for security and access restrictions.
 
index 6052841af274396a637abbd29a451a15d3b3104f..e799ad0baca8e8285caa49193f3a465b081a5a8b 100644 (file)
@@ -36,7 +36,7 @@ for how to compile the server.
 <h2>Compiling Apache</h2>
 
 Compiling Apache consists of three steps: Firstly select which Apache
-<b>modules</b> you want to include into the server. Secondly create a
+<STRONG>modules</STRONG> you want to include into the server. Secondly create a
 configuration for your operating system. Thirdly compile the
 executable.
 <P>
@@ -111,7 +111,7 @@ The modules we place in the Apache distribution are the ones we have
 tested and are used regularly by various members of the Apache
 development group.  Additional modules contributed by members or third
 parties with specific needs or functions are available at <A
-HREF="http://www.apache.org/dist/contrib/modules/">&lt;URL:http://www.apache.org/dist/contrib/modules/&gt;</a>.
+HREF="http://www.apache.org/dist/contrib/modules/">&lt;URL:http://www.apache.org/dist/contrib/modules/&gt;</A>.
 There are instructions on that page for linking these modules into the
 core Apache code.
 
@@ -126,11 +126,11 @@ designed to be configured and run from the same set of directories
 where it is compiled. If you want to run it from somewhere else, make
 a directory and copy the <CODE>conf</CODE>, <CODE>logs</CODE> and
 <CODE>icons</CODE> directories into it.  In either case you should
-read the <a href="misc/security_tips.html#serverroot">security tips</a>
+read the <A HREF="misc/security_tips.html#serverroot">security tips</A>
 describing how to set the permissions on the server root directory.<P>
 
 The next step is to edit the configuration files for the server. This
-consists of setting up various <B>directives</B> in up to three
+consists of setting up various <STRONG>directives</STRONG> in up to three
 central configuration files. By default, these files are located in
 the <CODE>conf</CODE> directory and are called <CODE>srm.conf</CODE>,
 <CODE>access.conf</CODE> and <CODE>httpd.conf</CODE>.  To help you get
@@ -188,7 +188,7 @@ port of 80, a suitable URL to enter into your browser is
 <P>
 
 Note that when the server starts it will create a number of
-<i>child</i> processes to handle the requests. If you started Apache
+<EM>child</EM> processes to handle the requests. If you started Apache
 as the root user, the parent process will continue to run as root
 while the children will change to the user as given in the httpd.conf
 file.
@@ -214,7 +214,7 @@ this will be located in the file <CODE>error_log</CODE> in the
 If you want your server to continue running after a system reboot, you
 should add a call to <CODE>httpd</CODE> to your system startup files
 (typically <CODE>rc.local</CODE> or a file in an
-<CODE>rc.<I>N</I></CODE> directory). This will start Apache as root.
+<CODE>rc.<EM>N</EM></CODE> directory). This will start Apache as root.
 Before doing this ensure that your server is properly configured
 for security and access restrictions.
 
index 708c63de29ac01e5dab1cc345feea0c3846c1d0f..d718c2f89c0852ad6768b21300bf81884c50cad5 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Starting Apache</h1>
+<h1 ALIGN="CENTER">Starting Apache</H1>
 
 <h2>Invoking Apache</h2>
-The <code>httpd</code> program is usually run as a daemon which executes
+The <CODE>httpd</CODE> program is usually run as a daemon which executes
 continuously, handling requests.  It is possible to invoke Apache by
-the Internet daemon <code>inetd</code> each time a connection to the HTTP
+the Internet daemon <CODE>inetd</CODE> each time a connection to the HTTP
 service is made (use the
 <A HREF="mod/core.html#servertype">ServerType</A> directive)
 but this is not recommended.
 
 <h2>Command line options</h2>
 The following options are recognized on the httpd command line:
-<dl>
-<dt><code>-d</code> <em>serverroot</em>
-<dd>Set the initial value for the
+<DL>
+<DT><CODE>-d</CODE> <EM>serverroot</EM>
+<DD>Set the initial value for the
 <A HREF="mod/core.html#serverroot">ServerRoot</A> variable to
-<em>serverroot</em>. This can be overridden by the ServerRoot command in the
-configuration file. The default is <code>/usr/local/apache</code>.
+<EM>serverroot</EM>. This can be overridden by the ServerRoot command in the
+configuration file. The default is <CODE>/usr/local/apache</CODE>.
 
-<dt><code>-f</code> <em>config</em>
-<dd>Execute the commands in the file <em>config</em> on startup. If
-<em>config</em> does not begin with a <code>/</code>, then it is taken to be a
+<DT><CODE>-f</CODE> <EM>config</EM>
+<DD>Execute the commands in the file <EM>config</EM> on startup. If
+<EM>config</EM> does not begin with a <CODE>/</CODE>, then it is taken to be a
 path relative to the <A HREF="mod/core.html#serverroot">ServerRoot</A>. The
-default is <code>conf/httpd.conf</code>.
+default is <CODE>conf/httpd.conf</CODE>.
 
-<dt><code>-X</code>
-<dd>Run in single-process mode, for internal debugging purposes only; the
-daemon does not detach from the terminal or fork any children. Do <em>NOT</em>
+<DT><CODE>-X</CODE>
+<DD>Run in single-process mode, for internal debugging purposes only; the
+daemon does not detach from the terminal or fork any children. Do <EM>NOT</EM>
 use this mode to provide ordinary web service.
 
-<dt><code>-v</code>
-<dd>Print the version of httpd and its build date, and then exit.
+<DT><CODE>-v</CODE>
+<DD>Print the version of httpd and its build date, and then exit.
 
-<dt><a name="version"><code>-V</code></a>
-<dd>Print the base version of httpd, its sub-version if defined, its
+<DT><A name="version"><CODE>-V</CODE></A>
+<DD>Print the base version of httpd, its sub-version if defined, its
 build date, and a list of compile time settings which influence the
 behavior and performance of the apache server (e.g., <SAMP>-D USE_MMAP_FILES</SAMP>),
 then exit.
 
-<dt><a name="help"><code>-h</code></a>
-<dd>Give a list of directives together with expected arguments and
+<DT><A name="help"><CODE>-h</CODE></A>
+<DD>Give a list of directives together with expected arguments and
 places where the directive is valid. (New in Apache 1.2)
 
-<dt><code>-l</code>
-<dd>Give a list of all modules compiled into the server.
+<DT><CODE>-l</CODE>
+<DD>Give a list of all modules compiled into the server.
 
-<dt><code>-?</code>
-<dd>Print a list of the httpd options, and then exit.
-</dl>
+<DT><CODE>-?</CODE>
+<DD>Print a list of the httpd options, and then exit.
+</DL>
 
 <h2>Configuration files</h2>
 The server will read three files for configuration directives. Any directive
 may appear in any of these files. The the names of these files are taken
 to be relative to the server root; this is set by the
 <A HREF="mod/core.html#serverroot">ServerRoot</A> directive, or the
-<code>-d</code> command line flag.
+<CODE>-d</CODE> command line flag.
 
 Conventionally, the files are:
-<dl>
-<dt><code>conf/httpd.conf</code>
-<dd>Contains directives that control the operation of the server daemon.
-The filename may be overridden with the <code>-f</code> command line flag.
+<DL>
+<DT><CODE>conf/httpd.conf</CODE>
+<DD>Contains directives that control the operation of the server daemon.
+The filename may be overridden with the <CODE>-f</CODE> command line flag.
 
-<dt><code>conf/srm.conf</code>
-<dd>Contains directives that control the specification of documents that
+<DT><CODE>conf/srm.conf</CODE>
+<DD>Contains directives that control the specification of documents that
 the server can provide to clients. The filename may be overridden with
 the <A HREF="mod/core.html#resourceconfig">ResourceConfig</A> directive.
 
-<dt><code>conf/access.conf</code>
-<dd>Contains directives that control access to documents.
+<DT><CODE>conf/access.conf</CODE>
+<DD>Contains directives that control access to documents.
 The filename may be overridden with the
 <A HREF="mod/core.html#accessconfig">AccessConfig</A> directive.
-</dl>
+</DL>
 However, these conventions need not be adhered to.
-<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>conf/mime.types</code> by default.
+and is <CODE>conf/mime.types</CODE> by default.
 
 <h2>Log files</h2>
 <h3>security warning</h3>
@@ -102,25 +102,25 @@ the consequences; see the <A HREF="misc/security_tips.html">security tips</A>
 document for details.
 <h3>pid file</h3>
 On daemon startup, it saves the process id of the parent httpd process to
-the file <code>logs/httpd.pid</code>. This filename can be changed with the
+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;
 A HUP or USR1 signal causes the daemon to re-read its configuration files and
 a TERM signal causes it to die gracefully.  For more information
-see the <a href="stopping.html">Stopping and Restarting</a> page.
-<p>
+see the <A HREF="stopping.html">Stopping and Restarting</A> page.
+<P>
 If the process dies (or is killed) abnormally, then it will be necessary to
 kill the children httpd processes.
 
 <h3>Error log</h3>
-The server will log error messages to a log file, <code>logs/error_log</code>
+The server will log error messages to a log file, <CODE>logs/error_log</CODE>
 by default. The filename can be set using the
 <A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs can
 be set for different <A HREF="mod/core.html#virtualhost">virtual hosts</A>.
 
 <h3>Transfer log</h3>
 The server will typically log each request to a transfer file,
-<code>logs/access_log</code> by default. The filename can be set using a
+<CODE>logs/access_log</CODE> by default. The filename can be set using a
 <A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different
 transfer logs can be set for different <A HREF="mod/core.html#virtualhost">virtual
 hosts</A>.
index 708c63de29ac01e5dab1cc345feea0c3846c1d0f..d718c2f89c0852ad6768b21300bf81884c50cad5 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Starting Apache</h1>
+<h1 ALIGN="CENTER">Starting Apache</H1>
 
 <h2>Invoking Apache</h2>
-The <code>httpd</code> program is usually run as a daemon which executes
+The <CODE>httpd</CODE> program is usually run as a daemon which executes
 continuously, handling requests.  It is possible to invoke Apache by
-the Internet daemon <code>inetd</code> each time a connection to the HTTP
+the Internet daemon <CODE>inetd</CODE> each time a connection to the HTTP
 service is made (use the
 <A HREF="mod/core.html#servertype">ServerType</A> directive)
 but this is not recommended.
 
 <h2>Command line options</h2>
 The following options are recognized on the httpd command line:
-<dl>
-<dt><code>-d</code> <em>serverroot</em>
-<dd>Set the initial value for the
+<DL>
+<DT><CODE>-d</CODE> <EM>serverroot</EM>
+<DD>Set the initial value for the
 <A HREF="mod/core.html#serverroot">ServerRoot</A> variable to
-<em>serverroot</em>. This can be overridden by the ServerRoot command in the
-configuration file. The default is <code>/usr/local/apache</code>.
+<EM>serverroot</EM>. This can be overridden by the ServerRoot command in the
+configuration file. The default is <CODE>/usr/local/apache</CODE>.
 
-<dt><code>-f</code> <em>config</em>
-<dd>Execute the commands in the file <em>config</em> on startup. If
-<em>config</em> does not begin with a <code>/</code>, then it is taken to be a
+<DT><CODE>-f</CODE> <EM>config</EM>
+<DD>Execute the commands in the file <EM>config</EM> on startup. If
+<EM>config</EM> does not begin with a <CODE>/</CODE>, then it is taken to be a
 path relative to the <A HREF="mod/core.html#serverroot">ServerRoot</A>. The
-default is <code>conf/httpd.conf</code>.
+default is <CODE>conf/httpd.conf</CODE>.
 
-<dt><code>-X</code>
-<dd>Run in single-process mode, for internal debugging purposes only; the
-daemon does not detach from the terminal or fork any children. Do <em>NOT</em>
+<DT><CODE>-X</CODE>
+<DD>Run in single-process mode, for internal debugging purposes only; the
+daemon does not detach from the terminal or fork any children. Do <EM>NOT</EM>
 use this mode to provide ordinary web service.
 
-<dt><code>-v</code>
-<dd>Print the version of httpd and its build date, and then exit.
+<DT><CODE>-v</CODE>
+<DD>Print the version of httpd and its build date, and then exit.
 
-<dt><a name="version"><code>-V</code></a>
-<dd>Print the base version of httpd, its sub-version if defined, its
+<DT><A name="version"><CODE>-V</CODE></A>
+<DD>Print the base version of httpd, its sub-version if defined, its
 build date, and a list of compile time settings which influence the
 behavior and performance of the apache server (e.g., <SAMP>-D USE_MMAP_FILES</SAMP>),
 then exit.
 
-<dt><a name="help"><code>-h</code></a>
-<dd>Give a list of directives together with expected arguments and
+<DT><A name="help"><CODE>-h</CODE></A>
+<DD>Give a list of directives together with expected arguments and
 places where the directive is valid. (New in Apache 1.2)
 
-<dt><code>-l</code>
-<dd>Give a list of all modules compiled into the server.
+<DT><CODE>-l</CODE>
+<DD>Give a list of all modules compiled into the server.
 
-<dt><code>-?</code>
-<dd>Print a list of the httpd options, and then exit.
-</dl>
+<DT><CODE>-?</CODE>
+<DD>Print a list of the httpd options, and then exit.
+</DL>
 
 <h2>Configuration files</h2>
 The server will read three files for configuration directives. Any directive
 may appear in any of these files. The the names of these files are taken
 to be relative to the server root; this is set by the
 <A HREF="mod/core.html#serverroot">ServerRoot</A> directive, or the
-<code>-d</code> command line flag.
+<CODE>-d</CODE> command line flag.
 
 Conventionally, the files are:
-<dl>
-<dt><code>conf/httpd.conf</code>
-<dd>Contains directives that control the operation of the server daemon.
-The filename may be overridden with the <code>-f</code> command line flag.
+<DL>
+<DT><CODE>conf/httpd.conf</CODE>
+<DD>Contains directives that control the operation of the server daemon.
+The filename may be overridden with the <CODE>-f</CODE> command line flag.
 
-<dt><code>conf/srm.conf</code>
-<dd>Contains directives that control the specification of documents that
+<DT><CODE>conf/srm.conf</CODE>
+<DD>Contains directives that control the specification of documents that
 the server can provide to clients. The filename may be overridden with
 the <A HREF="mod/core.html#resourceconfig">ResourceConfig</A> directive.
 
-<dt><code>conf/access.conf</code>
-<dd>Contains directives that control access to documents.
+<DT><CODE>conf/access.conf</CODE>
+<DD>Contains directives that control access to documents.
 The filename may be overridden with the
 <A HREF="mod/core.html#accessconfig">AccessConfig</A> directive.
-</dl>
+</DL>
 However, these conventions need not be adhered to.
-<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>conf/mime.types</code> by default.
+and is <CODE>conf/mime.types</CODE> by default.
 
 <h2>Log files</h2>
 <h3>security warning</h3>
@@ -102,25 +102,25 @@ the consequences; see the <A HREF="misc/security_tips.html">security tips</A>
 document for details.
 <h3>pid file</h3>
 On daemon startup, it saves the process id of the parent httpd process to
-the file <code>logs/httpd.pid</code>. This filename can be changed with the
+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;
 A HUP or USR1 signal causes the daemon to re-read its configuration files and
 a TERM signal causes it to die gracefully.  For more information
-see the <a href="stopping.html">Stopping and Restarting</a> page.
-<p>
+see the <A HREF="stopping.html">Stopping and Restarting</A> page.
+<P>
 If the process dies (or is killed) abnormally, then it will be necessary to
 kill the children httpd processes.
 
 <h3>Error log</h3>
-The server will log error messages to a log file, <code>logs/error_log</code>
+The server will log error messages to a log file, <CODE>logs/error_log</CODE>
 by default. The filename can be set using the
 <A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs can
 be set for different <A HREF="mod/core.html#virtualhost">virtual hosts</A>.
 
 <h3>Transfer log</h3>
 The server will typically log each request to a transfer file,
-<code>logs/access_log</code> by default. The filename can be set using a
+<CODE>logs/access_log</CODE> by default. The filename can be set using a
 <A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different
 transfer logs can be set for different <A HREF="mod/core.html#virtualhost">virtual
 hosts</A>.
index 96ab3a85447ecf6609d059027e3d9e2af7bb65f9..b5c3fd5e307e3e830ba3a28da38a403f9dc16c3d 100644 (file)
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Access Control by URL</H1>
 
-<h2><a name="location">The <code>&lt;Location&gt;</code> Directive</a></h2>
+<h2><A name="location">The <CODE>&lt;Location&gt;</CODE> Directive</A></h2>
 
-<strong>Syntax:</strong> &lt;Location <em>URL prefix</em>&gt;<br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
+<STRONG>Syntax:</STRONG> &lt;Location <EM>URL prefix</EM>&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
 
-<p>The &lt;Location&gt; directive provides for access control by
-URL. It is comparable to the <a
-href="mod/core.html#directory">&lt;Directory&gt;</a> directive, and
+<P>The &lt;Location&gt; directive provides for access control by
+URL. It is comparable to the <A
+HREF="mod/core.html#directory">&lt;Directory&gt;</A> directive, and
 should be matched with a &lt;/Location&gt; directive. Directives that
 apply to the URL given should be listen
-within. <code>&lt;Location&gt;</code> sections are processed in the
+within. <CODE>&lt;Location&gt;</CODE> sections are processed in the
 order they appear in the configuration file, after the
-&lt;Directory&gt; sections and <code>.htaccess</code> files are
-read.</p>
+&lt;Directory&gt; sections and <CODE>.htaccess</CODE> files are
+read.</P>
 
-<p>Note that, due to the way HTTP functions, <em>URL prefix</em>
-should, save for proxy requests, be of the form <code>/path/</code>,
-and should not include the <code>http://servername</code>. It doesn't
+<P>Note that, due to the way HTTP functions, <EM>URL prefix</EM>
+should, save for proxy requests, be of the form <CODE>/path/</CODE>,
+and should not include the <CODE>http://servername</CODE>. It doesn't
 necessarily have to protect a directory (it can be an individual
 file, or a number of files), and can include wild-cards.  In a wild-card
 string, `?' matches any single character, and `*' matches any
 sequences of characters.
 
-<p>This functionality is especially useful when combined with the
-<code><a href="mod/mod_mime.html#sethandler">SetHandler</a></code>
+<P>This functionality is especially useful when combined with the
+<CODE><A HREF="mod/mod_mime.html#sethandler">SetHandler</A></CODE>
 directive. For example, to enable status requests, but allow them only
 from browsers at foo.com, you might use:
 
-<pre>
+<PRE>
     &lt;Location /status&gt;
     SetHandler server-status
     order deny,allow
     deny from all
     allow from .foo.com
     &lt;/Location&gt;
-</pre>
+</PRE>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index dba84c18d525bc2a3ced89e1320b2a3eaad88005..fdcd8737a315b68a4217415aa21b9bbb2eaac048 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache API notes</title>
-</head>
+<HTML><HEAD>
+<TITLE>Apache API notes</TITLE>
+</HEAD>
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache API notes</h1>
+<h1 ALIGN="CENTER">Apache API notes</H1>
 
 These are some notes on the Apache API and the data structures you
 have to deal with, etc.  They are not yet nearly complete, but
 hopefully, they will help you get your bearings.  Keep in mind that
 the API is still subject to change as we gain experience with it.
-(See the TODO file for what <em>might</em> be coming).  However,
+(See the TODO file for what <EM>might</EM> be coming).  However,
 it will be easy to adapt modules to any changes that are made.
 (We have more modules to adapt than you do).
-<p>
+<P>
 
 A few notes on general pedagogical style here.  In the interest of
 conciseness, all structure declarations here are incomplete --- the
@@ -28,77 +28,77 @@ real ones have more slots that I'm not telling you about.  For the
 most part, these are reserved to one component of the server core or
 another, and should be altered by modules with caution.  However, in
 some cases, they really are things I just haven't gotten around to
-yet.  Welcome to the bleeding edge.<p>
+yet.  Welcome to the bleeding edge.<P>
 
 Finally, here's an outline, to give you some bare idea of what's
 coming up, and in what order:
 
-<ul>
-<li> <a href="#basics">Basic concepts.</a>
-<menu>
- <li> <a href="#HMR">Handlers, Modules, and Requests</a>
- <li> <a href="#moduletour">A brief tour of a module</a>
-</menu>
-<li> <a href="#handlers">How handlers work</a>
-<menu>
- <li> <a href="#req_tour">A brief tour of the <code>request_rec</code></a>
- <li> <a href="#req_orig">Where request_rec structures come from</a>
- <li> <a href="#req_return">Handling requests, declining, and returning error codes</a>
- <li> <a href="#resp_handlers">Special considerations for response handlers</a>
- <li> <a href="#auth_handlers">Special considerations for authentication handlers</a>
- <li> <a href="#log_handlers">Special considerations for logging handlers</a>
-</menu>
-<li> <a href="#pools">Resource allocation and resource pools</a>
-<li> <a href="#config">Configuration, commands and the like</a>
-<menu>
- <li> <a href="#per-dir">Per-directory configuration structures</a>
- <li> <a href="#commands">Command handling</a>
- <li> <a href="#servconf">Side notes --- per-server configuration, virtual servers, etc.</a>
-</menu>
-</ul>
-
-<h2><a name="basics">Basic concepts.</a></h2>
+<UL>
+<LI> <A HREF="#basics">Basic concepts.</A>
+<MENU>
+ <LI> <A HREF="#HMR">Handlers, Modules, and Requests</A>
+ <LI> <A HREF="#moduletour">A brief tour of a module</A>
+</MENU>
+<LI> <A HREF="#handlers">How handlers work</A>
+<MENU>
+ <LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A>
+ <LI> <A HREF="#req_orig">Where request_rec structures come from</A>
+ <LI> <A HREF="#req_return">Handling requests, declining, and returning error codes</A>
+ <LI> <A HREF="#resp_handlers">Special considerations for response handlers</A>
+ <LI> <A HREF="#auth_handlers">Special considerations for authentication handlers</A>
+ <LI> <A HREF="#log_handlers">Special considerations for logging handlers</A>
+</MENU>
+<LI> <A HREF="#pools">Resource allocation and resource pools</A>
+<LI> <A HREF="#config">Configuration, commands and the like</A>
+<MENU>
+ <LI> <A HREF="#per-dir">Per-directory configuration structures</A>
+ <LI> <A HREF="#commands">Command handling</A>
+ <LI> <A HREF="#servconf">Side notes --- per-server configuration, virtual servers, etc.</A>
+</MENU>
+</UL>
+
+<h2><A name="basics">Basic concepts.</A></h2>
 
 We begin with an overview of the basic concepts behind the
 API, and how they are manifested in the code.
 
-<h3><a name="HMR">Handlers, Modules, and Requests</a></h3>
+<h3><A name="HMR">Handlers, Modules, and Requests</A></h3>
 
 Apache breaks down request handling into a series of steps, more or
 less the same way the Netscape server API does (although this API has
 a few more stages than NetSite does, as hooks for stuff I thought
 might be useful in the future).  These are:
 
-<ul>
-  <li> URI -&gt; Filename translation
-  <li> Auth ID checking [is the user who they say they are?]
-  <li> Auth access checking [is the user authorized <em>here</em>?]
-  <li> Access checking other than auth
-  <li> Determining MIME type of the object requested
-  <li> `Fixups' --- there aren't any of these yet, but the phase is
+<UL>
+  <LI> URI -&gt; Filename translation
+  <LI> Auth ID checking [is the user who they say they are?]
+  <LI> Auth access checking [is the user authorized <EM>here</EM>?]
+  <LI> Access checking other than auth
+  <LI> Determining MIME type of the object requested
+  <LI> `Fixups' --- there aren't any of these yet, but the phase is
        intended as a hook for possible extensions like
-       <code>SetEnv</code>, which don't really fit well elsewhere.
-  <li> Actually sending a response back to the client.
-  <li> Logging the request
-</ul>
+       <CODE>SetEnv</CODE>, which don't really fit well elsewhere.
+  <LI> Actually sending a response back to the client.
+  <LI> Logging the request
+</UL>
 
 These phases are handled by looking at each of a succession of
-<em>modules</em>, looking to see if each of them has a handler for the
+<EM>modules</EM>, looking to see if each of them has a handler for the
 phase, and attempting invoking it if so.  The handler can typically do
 one of three things:
 
-<ul>
-  <li> <em>Handle</em> the request, and indicate that it has done so
-       by returning the magic constant <code>OK</code>.
-  <li> <em>Decline</em> to handle the request, by returning the magic
-       integer constant <code>DECLINED</code>.  In this case, the
+<UL>
+  <LI> <EM>Handle</EM> the request, and indicate that it has done so
+       by returning the magic constant <CODE>OK</CODE>.
+  <LI> <EM>Decline</EM> to handle the request, by returning the magic
+       integer constant <CODE>DECLINED</CODE>.  In this case, the
        server behaves in all respects as if the handler simply hadn't
        been there.
-  <li> Signal an error, by returning one of the HTTP error codes.
+  <LI> Signal an error, by returning one of the HTTP error codes.
        This terminates normal handling of the request, although an
        ErrorDocument may be invoked to try to mop up, and it will be
        logged in any case.
-</ul>
+</UL>
 
 Most phases are terminated by the first module that handles them;
 however, for logging, `fixups', and non-access authentication
@@ -106,62 +106,62 @@ checking, all handlers always run (barring an error).  Also, the
 response phase is unique in that modules may declare multiple handlers
 for it, via a dispatch table keyed on the MIME type of the requested
 object.  Modules may declare a response-phase handler which can handle
-<em>any</em> request, by giving it the key <code>*/*</code> (i.e., a
+<EM>any</EM> request, by giving it the key <CODE>*/*</CODE> (i.e., a
 wildcard MIME type specification).  However, wildcard handlers are
 only invoked if the server has already tried and failed to find a more
 specific response handler for the MIME type of the requested object
-(either none existed, or they all declined).<p>
+(either none existed, or they all declined).<P>
 
 The handlers themselves are functions of one argument (a
-<code>request_rec</code> structure. vide infra), which returns an
-integer, as above.<p>
+<CODE>request_rec</CODE> structure. vide infra), which returns an
+integer, as above.<P>
 
-<h3><a name="moduletour">A brief tour of a module</a></h3>
+<h3><A name="moduletour">A brief tour of a module</A></h3>
 
 At this point, we need to explain the structure of a module.  Our
 candidate will be one of the messier ones, the CGI module --- this
-handles both CGI scripts and the <code>ScriptAlias</code> config file
+handles both CGI scripts and the <CODE>ScriptAlias</CODE> config file
 command.  It's actually a great deal more complicated than most
 modules, but if we're going to have only one example, it might as well
-be the one with its fingers in every place.<p>
+be the one with its fingers in every place.<P>
 
 Let's begin with handlers.  In order to handle the CGI scripts, the
 module declares a response handler for them. Because of
-<code>ScriptAlias</code>, it also has handlers for the name
-translation phase (to recognize <code>ScriptAlias</code>ed URIs), the
-type-checking phase (any <code>ScriptAlias</code>ed request is typed
-as a CGI script).<p>
+<CODE>ScriptAlias</CODE>, it also has handlers for the name
+translation phase (to recognize <CODE>ScriptAlias</CODE>ed URIs), the
+type-checking phase (any <CODE>ScriptAlias</CODE>ed request is typed
+as a CGI script).<P>
 
 The module needs to maintain some per (virtual)
-server information, namely, the <code>ScriptAlias</code>es in effect;
+server information, namely, the <CODE>ScriptAlias</CODE>es in effect;
 the module structure therefore contains pointers to a functions which
 builds these structures, and to another which combines two of them (in
 case the main server and a virtual server both have
-<code>ScriptAlias</code>es declared).<p>
+<CODE>ScriptAlias</CODE>es declared).<P>
 
 Finally, this module contains code to handle the
-<code>ScriptAlias</code> command itself.  This particular module only
+<CODE>ScriptAlias</CODE> command itself.  This particular module only
 declares one command, but there could be more, so modules have
-<em>command tables</em> which declare their commands, and describe
-where they are permitted, and how they are to be invoked.  <p>
+<EM>command tables</EM> which declare their commands, and describe
+where they are permitted, and how they are to be invoked.  <P>
 
 A final note on the declared types of the arguments of some of these
-commands: a <code>pool</code> is a pointer to a <em>resource pool</em>
+commands: a <CODE>pool</CODE> is a pointer to a <EM>resource pool</EM>
 structure; these are used by the server to keep track of the memory
 which has been allocated, files opened, etc., either to service a
 particular request, or to handle the process of configuring itself.
 That way, when the request is over (or, for the configuration pool,
 when the server is restarting), the memory can be freed, and the files
-closed, <i>en masse</i>, without anyone having to write explicit code to
+closed, <EM>en masse</EM>, without anyone having to write explicit code to
 track them all down and dispose of them.  Also, a
-<code>cmd_parms</code> structure contains various information about
+<CODE>cmd_parms</CODE> structure contains various information about
 the config file being read, and other status information, which is
 sometimes of use to the function which processes a config-file command
-(such as <code>ScriptAlias</code>).
+(such as <CODE>ScriptAlias</CODE>).
 
 With no further ado, the module itself:
 
-<pre>
+<PRE>
 /* Declarations of handlers. */
 
 int translate_scriptalias (request_rec *);
@@ -213,34 +213,34 @@ module cgi_module = {
    NULL,                     /* logger */
    NULL                      /* header parser */
 };
-</pre>
+</PRE>
 
-<h2><a name="handlers">How handlers work</a></h2>
+<h2><A name="handlers">How handlers work</A></h2>
 
-The sole argument to handlers is a <code>request_rec</code> structure.
+The sole argument to handlers is a <CODE>request_rec</CODE> structure.
 This structure describes a particular request which has been made to
 the server, on behalf of a client.  In most cases, each connection to
-the client generates only one <code>request_rec</code> structure.<p>
+the client generates only one <CODE>request_rec</CODE> structure.<P>
 
-<h3><a name="req_tour">A brief tour of the <code>request_rec</code></a></h3>
+<h3><A name="req_tour">A brief tour of the <CODE>request_rec</CODE></A></h3>
 
-The <code>request_rec</code> contains pointers to a resource pool
+The <CODE>request_rec</CODE> contains pointers to a resource pool
 which will be cleared when the server is finished handling the
 request; to structures containing per-server and per-connection
-information, and most importantly, information on the request itself.<p>
+information, and most importantly, information on the request itself.<P>
 
 The most important such information is a small set of character
 strings describing attributes of the object being requested, including
 its URI, filename, content-type and content-encoding (these being filled
 in by the translation and type-check handlers which handle the
-request, respectively). <p>
+request, respectively). <P>
 
 Other commonly used data items are tables giving the MIME headers on
 the client's original request, MIME headers to be sent back with the
 response (which modules can add to at will), and environment variables
 for any subprocesses which are spawned off in the course of servicing
 the request.  These tables are manipulated using the
-<code>table_get</code> and <code>table_set</code> routines. <p>
+<CODE>table_get</CODE> and <CODE>table_set</CODE> routines. <P>
 <BLOCKQUOTE>
  Note that the <SAMP>Content-type</SAMP> header value <EM>cannot</EM> be
  set by module content-handlers using the <SAMP>table_*()</SAMP>
@@ -255,17 +255,17 @@ Finally, there are pointers to two data structures which, in turn,
 point to per-module configuration structures.  Specifically, these
 hold pointers to the data structures which the module has built to
 describe the way it has been configured to operate in a given
-directory (via <code>.htaccess</code> files or
-<code>&lt;Directory&gt;</code> sections), for private data it has
+directory (via <CODE>.htaccess</CODE> files or
+<CODE>&lt;Directory&gt;</CODE> sections), for private data it has
 built in the course of servicing the request (so modules' handlers for
 one phase can pass `notes' to their handlers for other phases).  There
-is another such configuration vector in the <code>server_rec</code>
-data structure pointed to by the <code>request_rec</code>, which
-contains per (virtual) server configuration data.<p>
+is another such configuration vector in the <CODE>server_rec</CODE>
+data structure pointed to by the <CODE>request_rec</CODE>, which
+contains per (virtual) server configuration data.<P>
 
-Here is an abridged declaration, giving the fields most commonly used:<p>
+Here is an abridged declaration, giving the fields most commonly used:<P>
 
-<pre>
+<PRE>
 struct request_rec {
 
   pool *pool;
@@ -327,101 +327,101 @@ struct request_rec {
 
 };
 
-</pre>
+</PRE>
 
-<h3><a name="req_orig">Where request_rec structures come from</a></h3>
+<h3><A name="req_orig">Where request_rec structures come from</A></h3>
 
-Most <code>request_rec</code> structures are built by reading an HTTP
+Most <CODE>request_rec</CODE> structures are built by reading an HTTP
 request from a client, and filling in the fields.  However, there are
 a few exceptions:
 
-<ul>
-  <li> If the request is to an imagemap, a type map (i.e., a
-       <code>*.var</code> file), or a CGI script which returned a
+<UL>
+  <LI> If the request is to an imagemap, a type map (i.e., a
+       <CODE>*.var</CODE> file), or a CGI script which returned a
        local `Location:', then the resource which the user requested
        is going to be ultimately located by some URI other than what
        the client originally supplied.  In this case, the server does
-       an <em>internal redirect</em>, constructing a new
-       <code>request_rec</code> for the new URI, and processing it
+       an <EM>internal redirect</EM>, constructing a new
+       <CODE>request_rec</CODE> for the new URI, and processing it
        almost exactly as if the client had requested the new URI
-       directly. <p>
+       directly. <P>
 
-  <li> If some handler signaled an error, and an
-       <code>ErrorDocument</code> is in scope, the same internal
-       redirect machinery comes into play.<p>
+  <LI> If some handler signaled an error, and an
+       <CODE>ErrorDocument</CODE> is in scope, the same internal
+       redirect machinery comes into play.<P>
 
-  <li> Finally, a handler occasionally needs to investigate `what
+  <LI> Finally, a handler occasionally needs to investigate `what
        would happen if' some other request were run.  For instance,
        the directory indexing module needs to know what MIME type
        would be assigned to a request for each directory entry, in
-       order to figure out what icon to use.<p>
+       order to figure out what icon to use.<P>
 
-       Such handlers can construct a <em>sub-request</em>, using the
-       functions <code>sub_req_lookup_file</code> and
-       <code>sub_req_lookup_uri</code>; this constructs a new
-       <code>request_rec</code> structure and processes it as you
+       Such handlers can construct a <EM>sub-request</EM>, using the
+       functions <CODE>sub_req_lookup_file</CODE> and
+       <CODE>sub_req_lookup_uri</CODE>; this constructs a new
+       <CODE>request_rec</CODE> structure and processes it as you
        would expect, up to but not including the point of actually
        sending a response.  (These functions skip over the access
        checks if the sub-request is for a file in the same directory
-       as the original request).<p>
+       as the original request).<P>
 
        (Server-side includes work by building sub-requests and then
        actually invoking the response handler for them, via the
-       function <code>run_sub_request</code>).
-</ul>
+       function <CODE>run_sub_request</CODE>).
+</UL>
 
-<h3><a name="req_return">Handling requests, declining, and returning error codes</a></h3>
+<h3><A name="req_return">Handling requests, declining, and returning error codes</A></h3>
 
 As discussed above, each handler, when invoked to handle a particular
-<code>request_rec</code>, has to return an <code>int</code> to
+<CODE>request_rec</CODE>, has to return an <CODE>int</CODE> to
 indicate what happened.  That can either be
 
-<ul>
-  <li> OK --- the request was handled successfully.  This may or may
+<UL>
+  <LI> OK --- the request was handled successfully.  This may or may
        not terminate the phase.
-  <li> DECLINED --- no erroneous condition exists, but the module
+  <LI> DECLINED --- no erroneous condition exists, but the module
        declines to handle the phase; the server tries to find another.
-  <li> an HTTP error code, which aborts handling of the request.
-</ul>
+  <LI> an HTTP error code, which aborts handling of the request.
+</UL>
 
-Note that if the error code returned is <code>REDIRECT</code>, then
-the module should put a <code>Location</code> in the request's
-<code>headers_out</code>, to indicate where the client should be
-redirected <em>to</em>. <p>
+Note that if the error code returned is <CODE>REDIRECT</CODE>, then
+the module should put a <CODE>Location</CODE> in the request's
+<CODE>headers_out</CODE>, to indicate where the client should be
+redirected <EM>to</EM>. <P>
 
-<h3><a name="resp_handlers">Special considerations for response handlers</a></h3>
+<h3><A name="resp_handlers">Special considerations for response handlers</A></h3>
 
 Handlers for most phases do their work by simply setting a few fields
-in the <code>request_rec</code> structure (or, in the case of access
+in the <CODE>request_rec</CODE> structure (or, in the case of access
 checkers, simply by returning the correct error code).  However,
-response handlers have to actually send a request back to the client. <p>
+response handlers have to actually send a request back to the client. <P>
 
 They should begin by sending an HTTP response header, using the
-function <code>send_http_header</code>.  (You don't have to do
+function <CODE>send_http_header</CODE>.  (You don't have to do
 anything special to skip sending the header for HTTP/0.9 requests; the
 function figures out on its own that it shouldn't do anything).  If
-the request is marked <code>header_only</code>, that's all they should
+the request is marked <CODE>header_only</CODE>, that's all they should
 do; they should return after that, without attempting any further
-output.  <p>
+output.  <P>
 
 Otherwise, they should produce a request body which responds to the
-client as appropriate.  The primitives for this are <code>rputc</code>
-and <code>rprintf</code>, for internally generated output, and
-<code>send_fd</code>, to copy the contents of some <code>FILE *</code>
-straight to the client.  <p>
+client as appropriate.  The primitives for this are <CODE>rputc</CODE>
+and <CODE>rprintf</CODE>, for internally generated output, and
+<CODE>send_fd</CODE>, to copy the contents of some <CODE>FILE *</CODE>
+straight to the client.  <P>
 
 At this point, you should more or less understand the following piece
-of code, which is the handler which handles <code>GET</code> requests
+of code, which is the handler which handles <CODE>GET</CODE> requests
 which have no more specific handler; it also shows how conditional
-<code>GET</code>s can be handled, if it's desirable to do so in a
-particular response handler --- <code>set_last_modified</code> checks
-against the <code>If-modified-since</code> value supplied by the
+<CODE>GET</CODE>s can be handled, if it's desirable to do so in a
+particular response handler --- <CODE>set_last_modified</CODE> checks
+against the <CODE>If-modified-since</CODE> value supplied by the
 client, if any, and returns an appropriate code (which will, if
 nonzero, be USE_LOCAL_COPY).   No similar considerations apply for
-<code>set_content_length</code>, but it returns an error code for
-symmetry.<p>
+<CODE>set_content_length</CODE>, but it returns an error code for
+symmetry.<P>
 
-<pre>
+<PRE>
 int default_handler (request_rec *r)
 {
     int errstatus;
@@ -449,96 +449,96 @@ int default_handler (request_rec *r)
     pfclose (r-&gt;pool, f);
     return OK;
 }
-</pre>
+</PRE>
 
 Finally, if all of this is too much of a challenge, there are a few
 ways out of it.  First off, as shown above, a response handler which
 has not yet produced any output can simply return an error code, in
 which case the server will automatically produce an error response.
 Secondly, it can punt to some other handler by invoking
-<code>internal_redirect</code>, which is how the internal redirection
+<CODE>internal_redirect</CODE>, which is how the internal redirection
 machinery discussed above is invoked.  A response handler which has
-internally redirected should always return <code>OK</code>. <p>
+internally redirected should always return <CODE>OK</CODE>. <P>
 
-(Invoking <code>internal_redirect</code> from handlers which are
-<em>not</em> response handlers will lead to serious confusion).
+(Invoking <CODE>internal_redirect</CODE> from handlers which are
+<EM>not</EM> response handlers will lead to serious confusion).
 
-<h3><a name="auth_handlers">Special considerations for authentication handlers</a></h3>
+<h3><A name="auth_handlers">Special considerations for authentication handlers</A></h3>
 
 Stuff that should be discussed here in detail:
 
-<ul>
-  <li> Authentication-phase handlers not invoked unless auth is
+<UL>
+  <LI> Authentication-phase handlers not invoked unless auth is
        configured for the directory.
-  <li> Common auth configuration stored in the core per-dir
-       configuration; it has accessors <code>auth_type</code>,
-       <code>auth_name</code>, and <code>requires</code>.
-  <li> Common routines, to handle the protocol end of things, at least
-       for HTTP basic authentication (<code>get_basic_auth_pw</code>,
-       which sets the <code>connection-&gt;user</code> structure field
-       automatically, and <code>note_basic_auth_failure</code>, which
-       arranges for the proper <code>WWW-Authenticate:</code> header
+  <LI> Common auth configuration stored in the core per-dir
+       configuration; it has accessors <CODE>auth_type</CODE>,
+       <CODE>auth_name</CODE>, and <CODE>requires</CODE>.
+  <LI> Common routines, to handle the protocol end of things, at least
+       for HTTP basic authentication (<CODE>get_basic_auth_pw</CODE>,
+       which sets the <CODE>connection-&gt;user</CODE> structure field
+       automatically, and <CODE>note_basic_auth_failure</CODE>, which
+       arranges for the proper <CODE>WWW-Authenticate:</CODE> header
        to be sent back).
-</ul>
+</UL>
 
-<h3><a name="log_handlers">Special considerations for logging handlers</a></h3>
+<h3><A name="log_handlers">Special considerations for logging handlers</A></h3>
 
 When a request has internally redirected, there is the question of
 what to log.  Apache handles this by bundling the entire chain of
-redirects into a list of <code>request_rec</code> structures which are
-threaded through the <code>r-&gt;prev</code> and <code>r-&gt;next</code>
-pointers.  The <code>request_rec</code> which is passed to the logging
+redirects into a list of <CODE>request_rec</CODE> structures which are
+threaded through the <CODE>r-&gt;prev</CODE> and <CODE>r-&gt;next</CODE>
+pointers.  The <CODE>request_rec</CODE> which is passed to the logging
 handlers in such cases is the one which was originally built for the
 initial request from the client; note that the bytes_sent field will
 only be correct in the last request in the chain (the one for which a
 response was actually sent).
 
-<h2><a name="pools">Resource allocation and resource pools</a></h2>
+<h2><A name="pools">Resource allocation and resource pools</A></h2>
 
 One of the problems of writing and designing a server-pool server is
 that of preventing leakage, that is, allocating resources (memory,
 open files, etc.), without subsequently releasing them.  The resource
 pool machinery is designed to make it easy to prevent this from
 happening, by allowing resource to be allocated in such a way that
-they are <em>automatically</em> released when the server is done with
-them. <p>
+they are <EM>automatically</EM> released when the server is done with
+them. <P>
 
 The way this works is as follows:  the memory which is allocated, file
 opened, etc., to deal with a particular request are tied to a
-<em>resource pool</em> which is allocated for the request.  The pool
-is a data structure which itself tracks the resources in question. <p>
+<EM>resource pool</EM> which is allocated for the request.  The pool
+is a data structure which itself tracks the resources in question. <P>
 
-When the request has been processed, the pool is <em>cleared</em>.  At
+When the request has been processed, the pool is <EM>cleared</EM>.  At
 that point, all the memory associated with it is released for reuse,
 all files associated with it are closed, and any other clean-up
 functions which are associated with the pool are run.  When this is
 over, we can be confident that all the resource tied to the pool have
-been released, and that none of them have leaked. <p>
+been released, and that none of them have leaked. <P>
 
 Server restarts, and allocation of memory and resources for per-server
 configuration, are handled in a similar way.  There is a
-<em>configuration pool</em>, which keeps track of resources which were
+<EM>configuration pool</EM>, which keeps track of resources which were
 allocated while reading the server configuration files, and handling
 the commands therein (for instance, the memory that was allocated for
 per-server module configuration, log files and other files that were
 opened, and so forth).  When the server restarts, and has to reread
 the configuration files, the configuration pool is cleared, and so the
 memory and file descriptors which were taken up by reading them the
-last time are made available for reuse. <p>
+last time are made available for reuse. <P>
 
 It should be noted that use of the pool machinery isn't generally
 obligatory, except for situations like logging handlers, where you
 really need to register cleanups to make sure that the log file gets
 closed when the server restarts (this is most easily done by using the
-function <code><a href="#pool-files">pfopen</a></code>, which also
+function <CODE><A HREF="#pool-files">pfopen</A></CODE>, which also
 arranges for the underlying file descriptor to be closed before any
-child processes, such as for CGI scripts, are <code>exec</code>ed), or
+child processes, such as for CGI scripts, are <CODE>exec</CODE>ed), or
 in case you are using the timeout machinery (which isn't yet even
 documented here).  However, there are two benefits to using it:
 resources allocated to a pool never leak (even if you allocate a
 scratch string, and just forget about it); also, for memory
-allocation, <code>palloc</code> is generally faster than
-<code>malloc</code>.<p>
+allocation, <CODE>palloc</CODE> is generally faster than
+<CODE>malloc</CODE>.<P>
 
 We begin here by describing how memory is allocated to pools, and then
 discuss how other resources are tracked by the resource pool
@@ -547,15 +547,15 @@ machinery.
 <h3>Allocation of memory in pools</h3>
 
 Memory is allocated to pools by calling the function
-<code>palloc</code>, which takes two arguments, one being a pointer to
+<CODE>palloc</CODE>, which takes two arguments, one being a pointer to
 a resource pool structure, and the other being the amount of memory to
-allocate (in <code>char</code>s).  Within handlers for handling
+allocate (in <CODE>char</CODE>s).  Within handlers for handling
 requests, the most common way of getting a resource pool structure is
-by looking at the <code>pool</code> slot of the relevant
-<code>request_rec</code>; hence the repeated appearance of the
+by looking at the <CODE>pool</CODE> slot of the relevant
+<CODE>request_rec</CODE>; hence the repeated appearance of the
 following idiom in module code:
 
-<pre>
+<PRE>
 int my_handler(request_rec *r)
 {
     struct my_structure *foo;
@@ -563,20 +563,20 @@ int my_handler(request_rec *r)
 
     foo = (foo *)palloc (r-&gt;pool, sizeof(my_structure));
 }
-</pre>
+</PRE>
 
-Note that <em>there is no <code>pfree</code></em> ---
-<code>palloc</code>ed memory is freed only when the associated
-resource pool is cleared.  This means that <code>palloc</code> does not
-have to do as much accounting as <code>malloc()</code>; all it does in
+Note that <EM>there is no <CODE>pfree</CODE></EM> ---
+<CODE>palloc</CODE>ed memory is freed only when the associated
+resource pool is cleared.  This means that <CODE>palloc</CODE> does not
+have to do as much accounting as <CODE>malloc()</CODE>; all it does in
 the typical case is to round up the size, bump a pointer, and do a
-range check.<p>
+range check.<P>
 
-(It also raises the possibility that heavy use of <code>palloc</code>
+(It also raises the possibility that heavy use of <CODE>palloc</CODE>
 could cause a server process to grow excessively large.  There are
 two ways to deal with this, which are dealt with below; briefly, you
-can use <code>malloc</code>, and try to be sure that all of the memory
-gets explicitly <code>free</code>d, or you can allocate a sub-pool of
+can use <CODE>malloc</CODE>, and try to be sure that all of the memory
+gets explicitly <CODE>free</CODE>d, or you can allocate a sub-pool of
 the main pool, allocate your memory in the sub-pool, and clear it out
 periodically.  The latter technique is discussed in the section on
 sub-pools below, and is used in the directory-indexing code, in order
@@ -586,107 +586,107 @@ thousands of files).
 <h3>Allocating initialized memory</h3>
 
 There are functions which allocate initialized memory, and are
-frequently useful.  The function <code>pcalloc</code> has the same
-interface as <code>palloc</code>, but clears out the memory it
-allocates before it returns it.  The function <code>pstrdup</code>
-takes a resource pool and a <code>char *</code> as arguments, and
+frequently useful.  The function <CODE>pcalloc</CODE> has the same
+interface as <CODE>palloc</CODE>, but clears out the memory it
+allocates before it returns it.  The function <CODE>pstrdup</CODE>
+takes a resource pool and a <CODE>char *</CODE> as arguments, and
 allocates memory for a copy of the string the pointer points to,
-returning a pointer to the copy.  Finally <code>pstrcat</code> is a
+returning a pointer to the copy.  Finally <CODE>pstrcat</CODE> is a
 varargs-style function, which takes a pointer to a resource pool, and
-at least two <code>char *</code> arguments, the last of which must be
-<code>NULL</code>.  It allocates enough memory to fit copies of each
+at least two <CODE>char *</CODE> arguments, the last of which must be
+<CODE>NULL</CODE>.  It allocates enough memory to fit copies of each
 of the strings, as a unit; for instance:
 
-<pre>
+<PRE>
      pstrcat (r-&gt;pool, "foo", "/", "bar", NULL);
-</pre>
+</PRE>
 
 returns a pointer to 8 bytes worth of memory, initialized to
-<code>"foo/bar"</code>.
+<CODE>"foo/bar"</CODE>.
 
-<h3><a name="pool-files">Tracking open files, etc.</a></h3>
+<h3><A name="pool-files">Tracking open files, etc.</A></h3>
 
 As indicated above, resource pools are also used to track other sorts
 of resources besides memory.  The most common are open files.  The
-routine which is typically used for this is <code>pfopen</code>, which
+routine which is typically used for this is <CODE>pfopen</CODE>, which
 takes a resource pool and two strings as arguments; the strings are
-the same as the typical arguments to <code>fopen</code>, e.g.,
+the same as the typical arguments to <CODE>fopen</CODE>, e.g.,
 
-<pre>
+<PRE>
      ...
      FILE *f = pfopen (r-&gt;pool, r-&gt;filename, "r");
 
      if (f == NULL) { ... } else { ... }
-</pre>
+</PRE>
 
-There is also a <code>popenf</code> routine, which parallels the
-lower-level <code>open</code> system call.  Both of these routines
+There is also a <CODE>popenf</CODE> routine, which parallels the
+lower-level <CODE>open</CODE> system call.  Both of these routines
 arrange for the file to be closed when the resource pool in question
-is cleared.  <p>
+is cleared.  <P>
 
-Unlike the case for memory, there <em>are</em> functions to close
-files allocated with <code>pfopen</code>, and <code>popenf</code>,
-namely <code>pfclose</code> and <code>pclosef</code>.  (This is
+Unlike the case for memory, there <EM>are</EM> functions to close
+files allocated with <CODE>pfopen</CODE>, and <CODE>popenf</CODE>,
+namely <CODE>pfclose</CODE> and <CODE>pclosef</CODE>.  (This is
 because, on many systems, the number of files which a single process
 can have open is quite limited).  It is important to use these
-functions to close files allocated with <code>pfopen</code> and
-<code>popenf</code>, since to do otherwise could cause fatal errors on
+functions to close files allocated with <CODE>pfopen</CODE> and
+<CODE>popenf</CODE>, since to do otherwise could cause fatal errors on
 systems such as Linux, which react badly if the same
-<code>FILE*</code> is closed more than once. <p>
+<CODE>FILE*</CODE> is closed more than once. <P>
 
-(Using the <code>close</code> functions is not mandatory, since the
+(Using the <CODE>close</CODE> functions is not mandatory, since the
 file will eventually be closed regardless, but you should consider it
 in cases where your module is opening, or could open, a lot of files).
 
 <h3>Other sorts of resources --- cleanup functions</h3>
 
 More text goes here.  Describe the the cleanup primitives in terms of
-which the file stuff is implemented; also, <code>spawn_process</code>.
+which the file stuff is implemented; also, <CODE>spawn_process</CODE>.
 
 <h3>Fine control --- creating and dealing with sub-pools, with a note
 on sub-requests</h3>
 
-On rare occasions, too-free use of <code>palloc()</code> and the
+On rare occasions, too-free use of <CODE>palloc()</CODE> and the
 associated primitives may result in undesirably profligate resource
 allocation.  You can deal with such a case by creating a
-<em>sub-pool</em>, allocating within the sub-pool rather than the main
+<EM>sub-pool</EM>, allocating within the sub-pool rather than the main
 pool, and clearing or destroying the sub-pool, which releases the
-resources which were associated with it.  (This really <em>is</em> a
+resources which were associated with it.  (This really <EM>is</EM> a
 rare situation; the only case in which it comes up in the standard
 module set is in case of listing directories, and then only with
-<em>very</em> large directories.  Unnecessary use of the primitives
+<EM>very</EM> large directories.  Unnecessary use of the primitives
 discussed here can hair up your code quite a bit, with very little
-gain). <p>
+gain). <P>
 
-The primitive for creating a sub-pool is <code>make_sub_pool</code>,
+The primitive for creating a sub-pool is <CODE>make_sub_pool</CODE>,
 which takes another pool (the parent pool) as an argument.  When the
 main pool is cleared, the sub-pool will be destroyed.  The sub-pool
 may also be cleared or destroyed at any time, by calling the functions
-<code>clear_pool</code> and <code>destroy_pool</code>, respectively.
-(The difference is that <code>clear_pool</code> frees resources
-associated with the pool, while <code>destroy_pool</code> also
+<CODE>clear_pool</CODE> and <CODE>destroy_pool</CODE>, respectively.
+(The difference is that <CODE>clear_pool</CODE> frees resources
+associated with the pool, while <CODE>destroy_pool</CODE> also
 deallocates the pool itself.  In the former case, you can allocate new
 resources within the pool, and clear it again, and so forth; in the
-latter case, it is simply gone). <p>
+latter case, it is simply gone). <P>
 
 One final note --- sub-requests have their own resource pools, which
 are sub-pools of the resource pool for the main request.  The polite
 way to reclaim the resources associated with a sub request which you
-have allocated (using the <code>sub_req_lookup_...</code> functions)
-is <code>destroy_sub_request</code>, which frees the resource pool.
+have allocated (using the <CODE>sub_req_lookup_...</CODE> functions)
+is <CODE>destroy_sub_request</CODE>, which frees the resource pool.
 Before calling this function, be sure to copy anything that you care
 about which might be allocated in the sub-request's resource pool into
 someplace a little less volatile (for instance, the filename in its
-<code>request_rec</code> structure). <p>
+<CODE>request_rec</CODE> structure). <P>
 
 (Again, under most circumstances, you shouldn't feel obliged to call
 this function; only 2K of memory or so are allocated for a typical sub
 request, and it will be freed anyway when the main request pool is
 cleared.  It is only when you are allocating many, many sub-requests
 for a single main request that you should seriously consider the
-<code>destroy...</code> functions).
+<CODE>destroy...</CODE> functions).
 
-<h2><a name="config">Configuration, commands and the like</a></h2>
+<h2><A name="config">Configuration, commands and the like</A></h2>
 
 One of the design goals for this server was to maintain external
 compatibility with the NCSA 1.3 server --- that is, to read the same
@@ -696,7 +696,7 @@ hand, another design goal was to move as much of the server's
 functionality into modules which have as little as possible to do with
 the monolithic server core.  The only way to reconcile these goals is
 to move the handling of most commands from the central server into the
-modules.  <p>
+modules.  <P>
 
 However, just giving the modules command tables is not enough to
 divorce them completely from the server core.  The server has to
@@ -705,77 +705,77 @@ maintaining data which is private to the modules, and which can be
 either per-server, or per-directory.  Most things are per-directory,
 including in particular access control and authorization information,
 but also information on how to determine file types from suffixes,
-which can be modified by <code>AddType</code> and
-<code>DefaultType</code> directives, and so forth.  In general, the
-governing philosophy is that anything which <em>can</em> be made
+which can be modified by <CODE>AddType</CODE> and
+<CODE>DefaultType</CODE> directives, and so forth.  In general, the
+governing philosophy is that anything which <EM>can</EM> be made
 configurable by directory should be; per-server information is
 generally used in the standard set of modules for information like
-<code>Alias</code>es and <code>Redirect</code>s which come into play
+<CODE>Alias</CODE>es and <CODE>Redirect</CODE>s which come into play
 before the request is tied to a particular place in the underlying
-file system. <p>
+file system. <P>
 
 Another requirement for emulating the NCSA server is being able to
 handle the per-directory configuration files, generally called
-<code>.htaccess</code> files, though even in the NCSA server they can
+<CODE>.htaccess</CODE> files, though even in the NCSA server they can
 contain directives which have nothing at all to do with access
 control.  Accordingly, after URI -&gt; filename translation, but before
 performing any other phase, the server walks down the directory
 hierarchy of the underlying filesystem, following the translated
-pathname, to read any <code>.htaccess</code> files which might be
+pathname, to read any <CODE>.htaccess</CODE> files which might be
 present.  The information which is read in then has to be
-<em>merged</em> with the applicable information from the server's own
-config files (either from the <code>&lt;Directory&gt;</code> sections
-in <code>access.conf</code>, or from defaults in
-<code>srm.conf</code>, which actually behaves for most purposes almost
-exactly like <code>&lt;Directory /&gt;</code>).<p>
+<EM>merged</EM> with the applicable information from the server's own
+config files (either from the <CODE>&lt;Directory&gt;</CODE> sections
+in <CODE>access.conf</CODE>, or from defaults in
+<CODE>srm.conf</CODE>, which actually behaves for most purposes almost
+exactly like <CODE>&lt;Directory /&gt;</CODE>).<P>
 
 Finally, after having served a request which involved reading
-<code>.htaccess</code> files, we need to discard the storage allocated
+<CODE>.htaccess</CODE> files, we need to discard the storage allocated
 for handling them.  That is solved the same way it is solved wherever
 else similar problems come up, by tying those structures to the
-per-transaction resource pool.  <p>
+per-transaction resource pool.  <P>
 
-<h3><a name="per-dir">Per-directory configuration structures</a></h3>
+<h3><A name="per-dir">Per-directory configuration structures</A></h3>
 
-Let's look out how all of this plays out in <code>mod_mime.c</code>,
+Let's look out how all of this plays out in <CODE>mod_mime.c</CODE>,
 which defines the file typing handler which emulates the NCSA server's
 behavior of determining file types from suffixes.  What we'll be
 looking at, here, is the code which implements the
-<code>AddType</code> and <code>AddEncoding</code> commands.  These
-commands can appear in <code>.htaccess</code> files, so they must be
+<CODE>AddType</CODE> and <CODE>AddEncoding</CODE> commands.  These
+commands can appear in <CODE>.htaccess</CODE> files, so they must be
 handled in the module's private per-directory data, which in fact,
-consists of two separate <code>table</code>s for MIME types and
+consists of two separate <CODE>table</CODE>s for MIME types and
 encoding information, and is declared as follows:
 
-<pre>
+<PRE>
 typedef struct {
     table *forced_types;      /* Additional AddTyped stuff */
     table *encoding_types;    /* Added with AddEncoding... */
 } mime_dir_config;
-</pre>
+</PRE>
 
 When the server is reading a configuration file, or
-<code>&lt;Directory&gt;</code> section, which includes one of the MIME
-module's commands, it needs to create a <code>mime_dir_config</code>
+<CODE>&lt;Directory&gt;</CODE> section, which includes one of the MIME
+module's commands, it needs to create a <CODE>mime_dir_config</CODE>
 structure, so those commands have something to act on.  It does this
 by invoking the function it finds in the module's `create per-dir
 config slot', with two arguments: the name of the directory to which
-this configuration information applies (or <code>NULL</code> for
-<code>srm.conf</code>), and a pointer to a resource pool in which the
-allocation should happen. <p>
+this configuration information applies (or <CODE>NULL</CODE> for
+<CODE>srm.conf</CODE>), and a pointer to a resource pool in which the
+allocation should happen. <P>
 
-(If we are reading a <code>.htaccess</code> file, that resource pool
+(If we are reading a <CODE>.htaccess</CODE> file, that resource pool
 is the per-request resource pool for the request; otherwise it is a
 resource pool which is used for configuration data, and cleared on
 restarts.  Either way, it is important for the structure being created
 to vanish when the pool is cleared, by registering a cleanup on the
-pool if necessary). <p>
+pool if necessary). <P>
 
 For the MIME module, the per-dir config creation function just
-<code>palloc</code>s the structure above, and a creates a couple of
-<code>table</code>s to fill it.  That looks like this:
+<CODE>palloc</CODE>s the structure above, and a creates a couple of
+<CODE>table</CODE>s to fill it.  That looks like this:
 
-<pre>
+<PRE>
 void *create_mime_dir_config (pool *p, char *dummy)
 {
     mime_dir_config *new =
@@ -786,15 +786,15 @@ void *create_mime_dir_config (pool *p, char *dummy)
 
     return new;
 }
-</pre>
+</PRE>
 
-Now, suppose we've just read in a <code>.htaccess</code> file.  We
+Now, suppose we've just read in a <CODE>.htaccess</CODE> file.  We
 already have the per-directory configuration structure for the next
-directory up in the hierarchy.  If the <code>.htaccess</code> file we
-just read in didn't have any <code>AddType</code> or
-<code>AddEncoding</code> commands, its per-directory config structure
+directory up in the hierarchy.  If the <CODE>.htaccess</CODE> file we
+just read in didn't have any <CODE>AddType</CODE> or
+<CODE>AddEncoding</CODE> commands, its per-directory config structure
 for the MIME module is still valid, and we can just use it.
-Otherwise, we need to merge the two structures somehow. <p>
+Otherwise, we need to merge the two structures somehow. <P>
 
 To do that, the server invokes the module's per-directory config merge
 function, if one is present.  That function takes three arguments:
@@ -803,7 +803,7 @@ allocate the result.  For the MIME module, all that needs to be done
 is overlay the tables from the new per-directory config structure with
 those from the parent:
 
-<pre>
+<PRE>
 void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
 {
     mime_dir_config *parent_dir = (mime_dir_config *)parent_dirv;
@@ -818,63 +818,63 @@ void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
 
     return new;
 }
-</pre>
+</PRE>
 
 As a note --- if there is no per-directory merge function present, the
 server will just use the subdirectory's configuration info, and ignore
 the parent's.  For some modules, that works just fine (e.g., for the
 includes module, whose per-directory configuration information
-consists solely of the state of the <code>XBITHACK</code>), and for
+consists solely of the state of the <CODE>XBITHACK</CODE>), and for
 those modules, you can just not declare one, and leave the
-corresponding structure slot in the module itself <code>NULL</code>.<p>
+corresponding structure slot in the module itself <CODE>NULL</CODE>.<P>
 
-<h3><a name="commands">Command handling</a></h3>
+<h3><A name="commands">Command handling</A></h3>
 
 Now that we have these structures, we need to be able to figure out
 how to fill them.  That involves processing the actual
-<code>AddType</code> and <code>AddEncoding</code> commands.  To find
-commands, the server looks in the module's <code>command table</code>.
+<CODE>AddType</CODE> and <CODE>AddEncoding</CODE> commands.  To find
+commands, the server looks in the module's <CODE>command table</CODE>.
 That table contains information on how many arguments the commands
 take, and in what formats, where it is permitted, and so forth.  That
 information is sufficient to allow the server to invoke most
 command-handling functions with pre-parsed arguments.  Without further
-ado, let's look at the <code>AddType</code> command handler, which
-looks like this (the <code>AddEncoding</code> command looks basically
+ado, let's look at the <CODE>AddType</CODE> command handler, which
+looks like this (the <CODE>AddEncoding</CODE> command looks basically
 the same, and won't be shown here):
 
-<pre>
+<PRE>
 char *add_type(cmd_parms *cmd, mime_dir_config *m, char *ct, char *ext)
 {
     if (*ext == '.') ++ext;
     table_set (m-&gt;forced_types, ext, ct);
     return NULL;
 }
-</pre>
+</PRE>
 
 This command handler is unusually simple.  As you can see, it takes
 four arguments, two of which are pre-parsed arguments, the third being
 the per-directory configuration structure for the module in question,
-and the fourth being a pointer to a <code>cmd_parms</code> structure.
+and the fourth being a pointer to a <CODE>cmd_parms</CODE> structure.
 That structure contains a bunch of arguments which are frequently of
 use to some, but not all, commands, including a resource pool (from
 which memory can be allocated, and to which cleanups should be tied),
 and the (virtual) server being configured, from which the module's
-per-server configuration data can be obtained if required.<p>
+per-server configuration data can be obtained if required.<P>
 
 Another way in which this particular command handler is unusually
 simple is that there are no error conditions which it can encounter.
 If there were, it could return an error message instead of
-<code>NULL</code>; this causes an error to be printed out on the
-server's <code>stderr</code>, followed by a quick exit, if it is in
-the main config files; for a <code>.htaccess</code> file, the syntax
+<CODE>NULL</CODE>; this causes an error to be printed out on the
+server's <CODE>stderr</CODE>, followed by a quick exit, if it is in
+the main config files; for a <CODE>.htaccess</CODE> file, the syntax
 error is logged in the server error log (along with an indication of
 where it came from), and the request is bounced with a server error
-response (HTTP error status, code 500). <p>
+response (HTTP error status, code 500). <P>
 
 The MIME module's command table has entries for these commands, which
 look like this:
 
-<pre>
+<PRE>
 command_rec mime_cmds[] = {
 { "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
     "a mime type followed by a file extension" },
@@ -882,54 +882,54 @@ command_rec mime_cmds[] = {
     "an encoding (e.g., gzip), followed by a file extension" },
 { NULL }
 };
-</pre>
+</PRE>
 
 The entries in these tables are:
 
-<ul>
-  <li> The name of the command
-  <li> The function which handles it
-  <li> a <code>(void *)</code> pointer, which is passed in the
-       <code>cmd_parms</code> structure to the command handler ---
+<UL>
+  <LI> The name of the command
+  <LI> The function which handles it
+  <LI> a <CODE>(void *)</CODE> pointer, which is passed in the
+       <CODE>cmd_parms</CODE> structure to the command handler ---
        this is useful in case many similar commands are handled by the
        same function.
-  <li> A bit mask indicating where the command may appear.  There are
-       mask bits corresponding to each <code>AllowOverride</code>
-       option, and an additional mask bit, <code>RSRC_CONF</code>,
+  <LI> A bit mask indicating where the command may appear.  There are
+       mask bits corresponding to each <CODE>AllowOverride</CODE>
+       option, and an additional mask bit, <CODE>RSRC_CONF</CODE>,
        indicating that the command may appear in the server's own
-       config files, but <em>not</em> in any <code>.htaccess</code>
+       config files, but <EM>not</EM> in any <CODE>.htaccess</CODE>
        file.
-  <li> A flag indicating how many arguments the command handler wants
+  <LI> A flag indicating how many arguments the command handler wants
        pre-parsed, and how they should be passed in.
-       <code>TAKE2</code> indicates two pre-parsed arguments.  Other
-       options are <code>TAKE1</code>, which indicates one pre-parsed
-       argument, <code>FLAG</code>, which indicates that the argument
-       should be <code>On</code> or <code>Off</code>, and is passed in
-       as a boolean flag, <code>RAW_ARGS</code>, which causes the
+       <CODE>TAKE2</CODE> indicates two pre-parsed arguments.  Other
+       options are <CODE>TAKE1</CODE>, which indicates one pre-parsed
+       argument, <CODE>FLAG</CODE>, which indicates that the argument
+       should be <CODE>On</CODE> or <CODE>Off</CODE>, and is passed in
+       as a boolean flag, <CODE>RAW_ARGS</CODE>, which causes the
        server to give the command the raw, unparsed arguments
        (everything but the command name itself).  There is also
-       <code>ITERATE</code>, which means that the handler looks the
-       same as <code>TAKE1</code>, but that if multiple arguments are
+       <CODE>ITERATE</CODE>, which means that the handler looks the
+       same as <CODE>TAKE1</CODE>, but that if multiple arguments are
        present, it should be called multiple times, and finally
-       <code>ITERATE2</code>, which indicates that the command handler
-       looks like a <code>TAKE2</code>, but if more arguments are
+       <CODE>ITERATE2</CODE>, which indicates that the command handler
+       looks like a <CODE>TAKE2</CODE>, but if more arguments are
        present, then it should be called multiple times, holding the
        first argument constant.
-  <li> Finally, we have a string which describes the arguments that
+  <LI> Finally, we have a string which describes the arguments that
        should be present.  If the arguments in the actual config file
        are not as required, this string will be used to help give a
        more specific error message.  (You can safely leave this
-       <code>NULL</code>).
-</ul>
+       <CODE>NULL</CODE>).
+</UL>
 
 Finally, having set this all up, we have to use it.  This is
 ultimately done in the module's handlers, specifically for its
 file-typing handler, which looks more or less like this; note that the
 per-directory configuration structure is extracted from the
-<code>request_rec</code>'s per-directory configuration vector by using
-the <code>get_module_config</code> function.
+<CODE>request_rec</CODE>'s per-directory configuration vector by using
+the <CODE>get_module_config</CODE> function.
 
-<pre>
+<PRE>
 int find_ct(request_rec *r)
 {
     int i;
@@ -965,9 +965,9 @@ int find_ct(request_rec *r)
     return OK;
 }
 
-</pre>
+</PRE>
 
-<h3><a name="servconf">Side notes --- per-server configuration, virtual servers, etc.</a></h3>
+<h3><A name="servconf">Side notes --- per-server configuration, virtual servers, etc.</A></h3>
 
 The basic ideas behind per-server module configuration are basically
 the same as those for per-directory configuration; there is a creation
@@ -976,17 +976,17 @@ virtual server has partially overridden the base server configuration,
 and a combined structure must be computed.  (As with per-directory
 configuration, the default if no merge function is specified, and a
 module is configured in some virtual server, is that the base
-configuration is simply ignored). <p>
+configuration is simply ignored). <P>
 
 The only substantial difference is that when a command needs to
 configure the per-server private module data, it needs to go to the
-<code>cmd_parms</code> data to get at it.  Here's an example, from the
+<CODE>cmd_parms</CODE> data to get at it.  Here's an example, from the
 alias module, which also indicates how a syntax error can be returned
 (note that the per-directory configuration argument to the command
 handler is declared as a dummy, since the module doesn't actually have
 per-directory config data):
 
-<pre>
+<PRE>
 char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
 {
     server_rec *s = cmd-&gt;server;
@@ -999,6 +999,6 @@ char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
     new-&gt;fake = f; new-&gt;real = url;
     return NULL;
 }
-</pre>
+</PRE>
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
index 95bd6c1966811f186433159014d645c3fa0093b0..f5284247a3dc124030b6a82518118ddd1b7614f5 100644 (file)
@@ -15,7 +15,7 @@
   <!--#include virtual="header.html" -->
   <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
   <P>
-  $Revision: 1.103 $ ($Date: 1998/01/26 07:09:13 $)
+  $Revision: 1.104 $ ($Date: 1998/01/26 16:53:48 $)
   </P>
   <P>
   The latest version of this FAQ is always available from the main
      </A>
   <P>
   Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful
-  module which can help you in really <b>all</b> aspects of URL rewriting, so
+  module which can help you in really <STRONG>all</STRONG> aspects of URL rewriting, so
   it can be no trivial module per definition. To accomplish its hard job it
   uses software leverage and makes use of a powerful regular expression
   library by Henry Spencer which is an integral part of Apache since its
   <P>
   On the other hand mod_rewrite has to work inside the Apache API environment
   and needs to do some tricks to fit there. For instance the Apache API as of
-  1.x really was not designed for URL rewriting at the <tt>.htaccess</tt>
+  1.x really was not designed for URL rewriting at the <TT>.htaccess</TT>
   level of processing. Or the problem of multiple rewrites in sequence, which
   is also not handled by the API per design. To provide this features
   mod_rewrite has to do some special (but API compliant!) handling which leads
index ea7896b46abf50e41cda911e3aaf3dea70c24797..4f65341af64a4c3434d962a31807dba81da22485 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Reading Client Input in Apache 1.2</h1>
+<H1 ALIGN="CENTER">Reading Client Input in Apache 1.2</H1>
 
-<hr>
+<HR>
 
-<p>Apache 1.1 and earlier let modules handle POST and PUT requests by
+<P>Apache 1.1 and earlier let modules handle POST and PUT requests by
 themselves. The module would, on its own, determine whether the
 request had an entity, how many bytes it was, and then called a
-function (<code>read_client_block</code>) to get the data.
+function (<CODE>read_client_block</CODE>) to get the data.
 
-<p>However, HTTP/1.1 requires several things of POST and PUT request
+<P>However, HTTP/1.1 requires several things of POST and PUT request
 handlers that did not fit into this module, and all existing modules
 have to be rewritten. The API calls for handling this have been
 further abstracted, so that future HTTP protocol changes can be
-accomplished while remaining backwards-compatible.</p>
+accomplished while remaining backwards-compatible.</P>
 
-<hr>
+<HR>
 
 <h3>The New API Functions</h3>
 
-<pre>
+<PRE>
    int setup_client_block (request_rec *, int read_policy);
    int should_client_block (request_rec *);
    long get_client_block (request_rec *, char *buffer, int buffer_size);
-</pre>
+</PRE>
 
-<ol>
-<li>Call <code>setup_client_block()</code> near the beginning of the request
+<OL>
+<LI>Call <CODE>setup_client_block()</CODE> near the beginning of the request
     handler. This will set up all the necessary properties, and
     will return either OK, or an error code. If the latter,
     the module should return that error code. The second parameter
     selects the policy to apply if the request message indicates a
     body, and how a chunked
     transfer-coding should be interpreted. Choose one of
-<pre>
+<PRE>
     REQUEST_NO_BODY          Send 413 error if message has any body
     REQUEST_CHUNKED_ERROR    Send 411 error if body without Content-Length
     REQUEST_CHUNKED_DECHUNK  If chunked, remove the chunks for me.
     REQUEST_CHUNKED_PASS     Pass the chunks to me without removal.
-</pre>
+</PRE>
     In order to use the last two options, the caller MUST provide a buffer
     large enough to hold a chunk-size line, including any extensions.
 
 
 
-<li>When you are ready to possibly accept input, call
-    <code>should_client_block()</code>.
+<LI>When you are ready to possibly accept input, call
+    <CODE>should_client_block()</CODE>.
     This will tell the module whether or not to read input. If it is 0,
     the module should assume that the input is of a non-entity type
     (e.g. a GET request). A nonzero response indicates that the module
     should proceed (to step 3).
     This step also sends a 100 Continue response
     to HTTP/1.1 clients, so should not be called until the module
-    is <strong>*definitely*</strong> ready to read content. (otherwise, the point of the
+    is <STRONG>*definitely*</STRONG> ready to read content. (otherwise, the point of the
     100 response is defeated). Never call this function more than once.
 
-<li>Finally, call <code>get_client_block</code> in a loop. Pass it a
+<LI>Finally, call <CODE>get_client_block</CODE> in a loop. Pass it a
     buffer and its
     size. It will put data into the buffer (not necessarily the full
     buffer, in the case of chunked inputs), and return the length of
     the input block. When it is done reading, it will
     return 0 if EOF, or -1 if there was an error.
 
-</ol>
+</OL>
 
-<p>As an example, please look at the code in
-<code>mod_cgi.c</code>. This is properly written to the new API
-guidelines.</p>
+<P>As an example, please look at the code in
+<CODE>mod_cgi.c</CODE>. This is properly written to the new API
+guidelines.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 64abbbe18b2979c751188c09e0cce4b956c405b7..213fc302f4c43403405b230f7dff948b4b199421 100644 (file)
@@ -21,8 +21,8 @@ a couple gotcha's to watch out for.  These are mostly due to the fact
 that the parser for config and access control files was rewritten from
 scratch, so certain liberties the earlier servers took may not be
 available here.  These are all easily fixable.  If you know of other
-non-fatal problems that belong here, <a
-href="http://www.apache.org/bugdb.cgi">let us know.</a>
+non-fatal problems that belong here, <A
+HREF="http://www.apache.org/bugdb.cgi">let us know.</A>
 
 <P>Please also check the <A HREF="known_bugs.html">known bugs</A>
 page, and the <A HREF="known_client_problems.html">known client
@@ -34,13 +34,13 @@ problems</A> page.</P>
 
 <LI>The basic mod_auth <CODE>AuthGroupFile</CODE>-specified group file
     format allows commas between user names - Apache does not.<BR>
-    <I>- added 12/1/96</I>
+    <EM>- added 12/1/96</EM>
 </LI>
 
   <LI><P>If you follow the NCSA guidelines for setting up access restrictions
   based on client domain, you may well have added entries for,
   <CODE>AuthType, AuthName, AuthUserFile</CODE> or <CODE>AuthGroupFile</CODE>.
-  <B>None</B> of these are needed (or appropriate) for restricting access
+  <STRONG>None</STRONG> of these are needed (or appropriate) for restricting access
   based on client domain.
 
   <P>When Apache sees <CODE>AuthType</CODE> it (reasonably) assumes you
@@ -63,7 +63,7 @@ problems</A> page.</P>
 
   <P>
 
-  <LI><CODE>exec cgi=""</CODE> produces reasonable <B>malformed header</B>
+  <LI><CODE>exec cgi=""</CODE> produces reasonable <STRONG>malformed header</STRONG>
   responses when used to invoke non-CGI scripts.<BR>
   The NCSA code ignores the missing header. (bad idea)<BR>
   Solution: write CGI to the CGI spec or use <CODE>exec cmd=""</CODE> instead.
@@ -83,8 +83,8 @@ problems</A> page.</P>
   <LI>Icons for FancyIndexing broken - well, no, they're not broken,
   we've just upgraded the
   icons from flat .xbm files to pretty and much smaller .gif files, courtesy of
-<a href="mailto:kevinh@eit.com">Kevin Hughes</a> at
-<a href="http://www.eit.com/">EIT</a>.
+<A HREF="mailto:kevinh@eit.com">Kevin Hughes</A> at
+<A HREF="http://www.eit.com/">EIT</A>.
   If you are using the same srm.conf from an old distribution, make sure
   you add the new
   <A
@@ -105,11 +105,11 @@ problems</A> page.</P>
   valid group name
   (<EM>i.e.</EM>, "nogroup") not the numeric group ID.  The distribution
   httpd.conf, and earlier  ones, had the default Group be "#-1", which
-  was causing silent exits at startup.<p>
+  was causing silent exits at startup.<P>
 
-<li><code>.asis</code> files: Apache 0.6.5 did not require a Status header;
+<LI><CODE>.asis</CODE> files: Apache 0.6.5 did not require a Status header;
 it added one automatically if the .asis file contained a Location header.
-0.8.14 requires a Status header. <p>
+0.8.14 requires a Status header. <P>
 
   <P>
   <LI>Apache versions before 1.2b1 will ignore the last line of configuration
@@ -123,16 +123,16 @@ it added one automatically if the .asis file contained a Location header.
   <LI>Apache's <CODE>&lt;VirtualHost&gt;</CODE> treats all addresses as
   "optional" (i.e. the server should continue booting if it can't resolve
   the address).  Whereas in NCSA the default is to fail booting unless
-  an added <code>optional</code> keyword is included.
+  an added <CODE>optional</CODE> keyword is included.
 
   <LI>Apache does not implement <CODE>OnDeny</CODE> use
-  <a href="../mod/core.html#errordocument"><code>ErrorDocument</code></a>
+  <A HREF="../mod/core.html#errordocument"><CODE>ErrorDocument</CODE></A>
   instead.
 
   <LI>Apache (as of 1.3) always performs the equivalent of
-  <CODE>HostnameLookups minimal</CODE>.  <code>minimal</code> is not an
-  option to <a href="../mod/core.html#hostnamelookups"><code>
-  HostnameLookups</code></a>.
+  <CODE>HostnameLookups minimal</CODE>.  <CODE>minimal</CODE> is not an
+  option to <A HREF="../mod/core.html#hostnamelookups"><CODE>
+  HostnameLookups</CODE></A>.
 
   <LI>To embed spaces in directive arguments NCSA used a backslash
   before the space. Apache treats backslashes as normal characters. To
index db028bf907b4842dfbee88f7cf27c1fa9ee7986b..5841e10e1e2dd9c99f779c7347475014a380fe71 100644 (file)
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Descriptors and Apache</H1>
 
-<p>A <EM>descriptor</EM>, also commonly called a <EM>file handle</EM> is
+<P>A <EM>descriptor</EM>, also commonly called a <EM>file handle</EM> is
 an object that a program uses to read or write an open file, or open
 network socket, or a variety of other devices.  It is represented
-by an integer, and you may be familiar with <code>stdin</code>,
-<code>stdout</code>, and <code>stderr</code> which are descriptors 0,
+by an integer, and you may be familiar with <CODE>stdin</CODE>,
+<CODE>stdout</CODE>, and <CODE>stderr</CODE> which are descriptors 0,
 1, and 2 respectively.
 Apache needs a descriptor for each log file, plus one for each
 network socket that it listens on, plus a handful of others.  Libraries
@@ -28,7 +28,7 @@ open up many descriptors at all, and so there are some latent problems
 that you may experience should you start running Apache with many
 descriptors (i.e. with many virtual hosts).
 
-<p>The operating system enforces a limit on the number of descriptors
+<P>The operating system enforces a limit on the number of descriptors
 that a program can have open at a time.  There are typically three limits
 involved here.  One is a kernel limitation, depending on your operating
 system you will either be able to tune the number of descriptors available
@@ -44,49 +44,49 @@ Root can raise the hard limit up to the system maximum limit.  The soft
 limit is the actual limit that is used when enforcing the maximum number
 of files a process can have open.
 
-<p>To summarize:
+<P>To summarize:
 
-<center><pre>
+<CENTER><PRE>
   #open files  &lt;=  soft limit  &lt;=  hard limit  &lt;=  kernel limit
-</pre></center>
+</PRE></CENTER>
 
-<p>You control the hard and soft limits using the <code>limit</code> (csh)
-or <code>ulimit</code> (sh) directives.  See the respective man pages
+<P>You control the hard and soft limits using the <CODE>limit</CODE> (csh)
+or <CODE>ulimit</CODE> (sh) directives.  See the respective man pages
 for more information.  For example you can probably use
-<code>ulimit -n unlimited</code> to raise your soft limit up to the
+<CODE>ulimit -n unlimited</CODE> to raise your soft limit up to the
 hard limit.  You should include this command in a shell script which
 starts your webserver.
 
-<p>Unfortunately, it's not always this simple.  As mentioned above,
+<P>Unfortunately, it's not always this simple.  As mentioned above,
 you will probably run into some system limitations that will need to be
 worked around somehow.  Work was done in version 1.2.1 to improve the
 situation somewhat.  Here is a partial list of systems and workarounds
 (assuming you are using 1.2.1 or later):
 
-<dl>
+<DL>
 
-    <dt><STRONG>BSDI 2.0</STRONG>
-    <dd>Under BSDI 2.0 you can build Apache to support more descriptors
-        by adding <code>-DFD_SETSIZE=nnn</code> to
-        <code>EXTRA_CFLAGS</code> (where nnn is the number of descriptors
+    <DT><STRONG>BSDI 2.0</STRONG>
+    <DD>Under BSDI 2.0 you can build Apache to support more descriptors
+        by adding <CODE>-DFD_SETSIZE=nnn</CODE> to
+        <CODE>EXTRA_CFLAGS</CODE> (where nnn is the number of descriptors
         you wish to support, keep it less than the hard limit).  But it
         will run into trouble if more than approximately 240 Listen
         directives are used.  This may be cured by rebuilding your kernel
         with a higher FD_SETSIZE.
-    <p>
+    <P>
 
-    <dt><STRONG>FreeBSD 2.2, BSDI 2.1+</STRONG>
-    <dd>Similar to the BSDI 2.0 case, you should define
-        <code>FD_SETSIZE</code> and rebuild.  But the extra
+    <DT><STRONG>FreeBSD 2.2, BSDI 2.1+</STRONG>
+    <DD>Similar to the BSDI 2.0 case, you should define
+        <CODE>FD_SETSIZE</CODE> and rebuild.  But the extra
         Listen limitation doesn't exist.
-    <p>
+    <P>
 
-    <dt><STRONG>Linux</STRONG>
-    <dd>By default Linux has a kernel maximum of 256 open descriptors
+    <DT><STRONG>Linux</STRONG>
+    <DD>By default Linux has a kernel maximum of 256 open descriptors
         per process.  There are several patches available for the
         2.0.x series which raise this to 1024 and beyond, and you
-        can find them in the "unofficial patches" section of <a
-        href="http://www.linuxhq.com/">the Linux Information HQ</a>.
+        can find them in the "unofficial patches" section of <A
+        HREF="http://www.linuxhq.com/">the Linux Information HQ</A>.
         None of these patches are perfect, and an entirely different
         approach is likely to be taken during the 2.1.x development.
         Applying these patches will raise the FD_SETSIZE used to compile
@@ -95,34 +95,34 @@ situation somewhat.  Here is a partial list of systems and workarounds
         256.  As of this writing the patches available for increasing
         the number of descriptors do not take this into account.  On a
         dedicated webserver you probably won't run into trouble.
-    <p>
+    <P>
 
-    <dt><STRONG>Solaris through 2.5.1</STRONG>
-    <dd>Solaris has a kernel hard limit of 1024 (may be lower in earlier
+    <DT><STRONG>Solaris through 2.5.1</STRONG>
+    <DD>Solaris has a kernel hard limit of 1024 (may be lower in earlier
         versions).  But it has a limitation that files using
         the stdio library cannot have a descriptor above 255.
         Apache uses the stdio library for the ErrorLog directive.
         When you have more than approximately 110 virtual hosts
         (with an error log and an access log each) you will need to
-        build Apache with <code>-DHIGH_SLACK_LINE=256</code> added to
-        <code>EXTRA_CFLAGS</code>.  You will be limited to approximately
+        build Apache with <CODE>-DHIGH_SLACK_LINE=256</CODE> added to
+        <CODE>EXTRA_CFLAGS</CODE>.  You will be limited to approximately
         240 error logs if you do this.
-    <p>
+    <P>
 
-    <dt><STRONG>AIX</STRONG>
-    <dd>AIX version 3.2?? appears to have a hard limit of 128 descriptors.
+    <DT><STRONG>AIX</STRONG>
+    <DD>AIX version 3.2?? appears to have a hard limit of 128 descriptors.
        End of story.  Version 4.1.5 has a hard limit of 2000.
-    <p>
+    <P>
 
-    <dt><STRONG>Others</STRONG>
-    <dd>If you have details on another operating system, please submit
-        it through our <a href="http://www.apache.org/bug_report.html">Bug
-        Report Page</a>.
-    <p>
+    <DT><STRONG>Others</STRONG>
+    <DD>If you have details on another operating system, please submit
+        it through our <A HREF="http://www.apache.org/bug_report.html">Bug
+        Report Page</A>.
+    <P>
 
-</dl>
+</DL>
 
-<p>In addition to the problems described above there are problems with
+<P>In addition to the problems described above there are problems with
 many libraries that Apache uses.  The most common example is the bind
 DNS resolver library that is used by pretty much every unix, which
 fails if it ends up with a descriptor above 256.  We suspect there
@@ -131,23 +131,23 @@ takes a defensive stance and tries to save descriptors less than 16
 for use while processing each request.  This is called the <EM>low
 slack line</EM>.
 
-<p>Note that this shouldn't waste descriptors.  If you really are pushing
+<P>Note that this shouldn't waste descriptors.  If you really are pushing
 the limits and Apache can't get a descriptor above 16 when it wants
 it, it will settle for one below 16.
 
-<p>In extreme situations you may want to lower the low slack line,
+<P>In extreme situations you may want to lower the low slack line,
 but you shouldn't ever need to.  For example, lowering it can
 increase the limits 240 described above under Solaris and BSDI 2.0.
 But you'll play a delicate balancing game with the descriptors needed
 to serve a request.  Should you want to play this game, the compile
-time parameter is <code>LOW_SLACK_LINE</code> and there's a tiny
-bit of documentation in the header file <code>httpd.h</code>.
-
-<p>Finally, if you suspect that all this slack stuff is causing you
-problems, you can disable it.  Add <code>-DNO_SLACK</code> to
-<code>EXTRA_CFLAGS</code> and rebuild.  But please report it to
-our <a href="http://www.apache.org/bug_report.html">Bug
-Report Page</a> so that
+time parameter is <CODE>LOW_SLACK_LINE</CODE> and there's a tiny
+bit of documentation in the header file <CODE>httpd.h</CODE>.
+
+<P>Finally, if you suspect that all this slack stuff is causing you
+problems, you can disable it.  Add <CODE>-DNO_SLACK</CODE> to
+<CODE>EXTRA_CFLAGS</CODE> and rebuild.  But please report it to
+our <A HREF="http://www.apache.org/bug_report.html">Bug
+Report Page</A> so that
 we can investigate.
 
 <!--#include virtual="footer.html" -->
index 0027263f8e166b46a435edc2e59e3b15176f4ea1..135b8b06e076ae19b547c04775f559876414a601 100644 (file)
@@ -21,7 +21,7 @@
 <LI><H2>What is the FIN_WAIT_2 state?</H2>
 Starting with the Apache 1.2 betas, people are reporting many more
 connections in the FIN_WAIT_2 state (as reported by
-<code>netstat</code>) than they saw using older versions.  When the
+<CODE>netstat</CODE>) than they saw using older versions.  When the
 server closes a TCP connection, it sends a packet with the FIN bit
 sent to the client, which then responds with a packet with the ACK bit
 set.  The client then sends a packet with the FIN bit set to the
index a7d6b38c3c036c25d56df22485dcb8f61bb2b3c8..0fa77d96be8f552f59e63988ee0af3a47a64f0dc 100644 (file)
 <H1 ALIGN="CENTER">Apache HOWTO documentation</H1>
 
 How to:
-<ul>
-<li><A HREF="#redirect">redirect an entire server or directory to a single URL</A>
-<li><A HREF="#logreset">reset your log files</A>
-<li><A HREF="#stoprob">stop/restrict robots</A>
-</ul>
+<UL>
+<LI><A HREF="#redirect">redirect an entire server or directory to a single URL</A>
+<LI><A HREF="#logreset">reset your log files</A>
+<LI><A HREF="#stoprob">stop/restrict robots</A>
+</UL>
 
 <HR>
 <H2><A name="redirect">How to redirect an entire server or directory to a single URL</A></H2>
 
 <P>There are two chief ways to redirect all requests for an entire
 server to a single location: one which requires the use of
-<code>mod_rewrite</code>, and another which uses a CGI script.
+<CODE>mod_rewrite</CODE>, and another which uses a CGI script.
 
 <P>First: if all you need to do is migrate a server from one name to
-another, simply use the <code>Redirect</code> directive, as supplied
-by <code>mod_alias</code>:
+another, simply use the <CODE>Redirect</CODE> directive, as supplied
+by <CODE>mod_alias</CODE>:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
   Redirect / http://www.apache.org/
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<P>Since <code>Redirect</code> will forward along the complete path,
+<P>Since <CODE>Redirect</CODE> will forward along the complete path,
 however, it may not be appropriate - for example, when the directory
 structure has changed after the move, and you simply want to direct people
 to the home page.
 
-<P>The best option is to use the standard Apache module <code>mod_rewrite</code>.
+<P>The best option is to use the standard Apache module <CODE>mod_rewrite</CODE>.
 If that module is compiled in, the following lines:
 
-<blockquote><pre>RewriteEngine On
+<BLOCKQUOTE><PRE>RewriteEngine On
 RewriteRule /.* http://www.apache.org/ [R]
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 This will send an HTTP 302 Redirect back to the client, and no matter
 what they gave in the original URL, they'll be sent to
 "http://www.apache.org".
 
 The second option is to set up a <CODE>ScriptAlias</Code> pointing to
-a <B>cgi script</B> which outputs a 301 or 302 status and the location
+a <STRONG>cgi script</STRONG> which outputs a 301 or 302 status and the location
 of the other server.</P>
 
-<P>By using a <B>cgi-script</B> you can intercept various requests and
-treat them specially, e.g. you might want to intercept <B>POST</B>
+<P>By using a <STRONG>cgi-script</STRONG> you can intercept various requests and
+treat them specially, e.g. you might want to intercept <STRONG>POST</STRONG>
 requests, so that the client isn't redirected to a script on the other
 server which expects POST information (a redirect will lose the POST
 information.) You might also want to use a CGI script if you don't
@@ -68,17 +68,17 @@ want to compile mod_rewrite into your server.
 
 <P>Here's how to redirect all requests to a script... In the server
 configuration file,
-<blockquote><pre>ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script</pre></blockquote>
+<BLOCKQUOTE><PRE>ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script</PRE></BLOCKQUOTE>
 
 and here's a simple perl script to redirect requests:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 #!/usr/local/bin/perl
 
 print "Status: 302 Moved Temporarily\r
 Location: http://www.some.where.else.com/\r\n\r\n";
 
-</pre></blockquote></P>
+</PRE></BLOCKQUOTE></P>
 
 <HR>
 
@@ -100,14 +100,14 @@ characters.</P>
 
 <P>The correct procedure is to move the logfile, then signal Apache to tell it to reopen the logfiles.</P>
 
-<P>Apache is signaled using the <B>SIGHUP</B> (-1) signal. e.g.
-<blockquote><code>
+<P>Apache is signaled using the <STRONG>SIGHUP</STRONG> (-1) signal. e.g.
+<BLOCKQUOTE><CODE>
 mv access_log access_log.old<BR>
 kill -1 `cat httpd.pid`
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 </P>
 
-<P>Note: <code>httpd.pid</code> is a file containing the <B>p</B>rocess <B>id</B>
+<P>Note: <CODE>httpd.pid</CODE> is a file containing the <STRONG>p</STRONG>rocess <STRONG>id</STRONG>
 of the Apache httpd daemon, Apache saves this in the same directory as the log
 files.</P>
 
@@ -118,16 +118,16 @@ nightly or weekly basis.</P>
 <H2><A name="stoprob">How to stop or restrict robots</A></H2>
 
 <P>Ever wondered why so many clients are interested in a file called
-<code>robots.txt</code> which you don't have, and never did have?</P>
+<CODE>robots.txt</CODE> which you don't have, and never did have?</P>
 
-<P>These clients are called <B>robots</B> (also known as crawlers,
+<P>These clients are called <STRONG>robots</STRONG> (also known as crawlers,
 spiders and other cute name) - special automated clients which
 wander around the web looking for interesting resources.</P>
 
-<P>Most robots are used to generate some kind of <em>web index</em> which
-is then used by a <em>search engine</em> to help locate information.</P>
+<P>Most robots are used to generate some kind of <EM>web index</EM> which
+is then used by a <EM>search engine</EM> to help locate information.</P>
 
-<P><code>robots.txt</code> provides a means to request that robots limit their
+<P><CODE>robots.txt</CODE> provides a means to request that robots limit their
 activities at the site, or more often than not, to leave the site alone.</P>
 
 <P>When the first robots were developed, they had a bad reputation for
index b8a5608b32feae600ca10bd03865fef1785dc097..b9eb945cc358743695572eb1004d13979ed2235d 100644 (file)
@@ -13,7 +13,7 @@
   ALINK="#FF0000"
  >
   <!--#include virtual="header.html" -->
-  <H1 ALIGN="CENTER">Apache Miscellaneous Documentation</h1>
+  <H1 ALIGN="CENTER">Apache Miscellaneous Documentation</H1>
 
   <P>
   Below is a list of additional documentation pages that apply to the
index fddb1c25f880f2da1d2ca9d1dfe3aed453aeb717..59de0de7bb5f53a1bf00943808991de2f83abaa6 100644 (file)
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Known Problems in Clients</H1>
 
-<p>Over time the Apache Group has discovered or been notified of problems
+<P>Over time the Apache Group has discovered or been notified of problems
 with various clients which we have had to work around.  This document
 describes these problems and the workarounds available.  It's not arranged
 in any particular order.  Some familiarity with the standards is assumed,
 but not necessary.
 
-<p>For brevity, <i>Navigator</i> will refer to Netscape's Navigator
-product, and <i>MSIE</i> will refer to Microsoft's Internet Explorer
+<P>For brevity, <EM>Navigator</EM> will refer to Netscape's Navigator
+product, and <EM>MSIE</EM> will refer to Microsoft's Internet Explorer
 product.  All trademarks and copyrights belong to their respective
 companies.  We welcome input from the various client authors to correct
 inconsistencies in this paper, or to provide us with exact version
 numbers where things are broken/fixed.
 
-<p>For reference,
-<a href="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</a>
+<P>For reference,
+<A HREF="ftp://ds.internic.net/rfc/rfc1945.txt">RFC1945</A>
 defines HTTP/1.0, and
-<a href="ftp://ds.internic.net/rfc/rfc2068.txt">RFC2068</a>
+<A HREF="ftp://ds.internic.net/rfc/rfc2068.txt">RFC2068</A>
 defines HTTP/1.1.  Apache as of version 1.2 is an HTTP/1.1 server (with an 
 optional HTTP/1.0 proxy).
 
-<p>Various of these workarounds are triggered by environment variables.
+<P>Various of these workarounds are triggered by environment variables.
 The admin typically controls which are set, and for which clients, by using 
-<a href="../mod/mod_browser.html">mod_browser</a>.  Unless otherwise
+<A HREF="../mod/mod_browser.html">mod_browser</A>.  Unless otherwise
 noted all of these workarounds exist in versions 1.2 and later.
 
-<a name="trailing-crlf"><H3>Trailing CRLF on POSTs</H3></a>
+<A name="trailing-crlf"><H3>Trailing CRLF on POSTs</H3></A>
 
-<p>This is a legacy issue.  The CERN webserver required <code>POST</code>
-data to have an extra <code>CRLF</code> following it.  Thus many
-clients send an extra <code>CRLF</code> that
-is not included in the <code>Content-Length</code> of the request.
+<P>This is a legacy issue.  The CERN webserver required <CODE>POST</CODE>
+data to have an extra <CODE>CRLF</CODE> following it.  Thus many
+clients send an extra <CODE>CRLF</CODE> that
+is not included in the <CODE>Content-Length</CODE> of the request.
 Apache works around this problem by eating any empty lines which
 appear before a request.
 
-<a name="broken-keepalive"><h3>Broken keepalive</h3></a>
+<A name="broken-keepalive"><h3>Broken keepalive</h3></A>
 
-<p>Various clients have had broken implementations of <i>keepalive</i>
+<P>Various clients have had broken implementations of <EM>keepalive</EM>
 (persistent connections).  In particular the Windows versions of
 Navigator 2.0 get very confused when the server times out an
 idle connection.  The workaround is present in the default config files:
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 BrowserMatch Mozilla/2 nokeepalive
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 Note that this matches some earlier versions of MSIE, which began the
-practice of calling themselves <i>Mozilla</i> in their user-agent
+practice of calling themselves <EM>Mozilla</EM> in their user-agent
 strings just like Navigator.
 
-<p>MSIE 4.0b2, which claims to support HTTP/1.1, does not properly
+<P>MSIE 4.0b2, which claims to support HTTP/1.1, does not properly
 support keepalive when it is used on 301 or 302 (redirect)
-responses.  Unfortunately Apache's <code>nokeepalive</code> code
+responses.  Unfortunately Apache's <CODE>nokeepalive</CODE> code
 prior to 1.2.2 would not work with HTTP/1.1 clients.  You must apply
-<a href="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">this
-patch</a> to version 1.2.1.  Then add this to your config:
-<blockquote><code>
+<A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">this
+patch</A> to version 1.2.1.  Then add this to your config:
+<BLOCKQUOTE><CODE>
 BrowserMatch "MSIE 4\.0b2;" nokeepalive
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
-<a name="force-response-1.0"><h3>Incorrect interpretation of <code>HTTP/1.1</code> in response</h3></a>
+<A name="force-response-1.0"><h3>Incorrect interpretation of <CODE>HTTP/1.1</CODE> in response</h3></A>
 
-<p>To quote from section 3.1 of RFC1945:
-<blockquote>
-HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
+<P>To quote from section 3.1 of RFC1945:
+<BLOCKQUOTE>
+HTTP uses a "<MAJOR>.<MINOR>" numbering scheme to indicate versions
 of the protocol. The protocol versioning policy is intended to allow
 the sender to indicate the format of a message and its capacity for
 understanding further HTTP communication, rather than the features
 obtained via that communication.
-</blockquote>
+</BLOCKQUOTE>
 Since Apache is an HTTP/1.1 server, it indicates so as part of its
 response.  Many client authors mistakenly treat this part of the response
 as an indication of the protocol that the response is in, and then refuse
 to accept the response.
 
-<p>The first major indication of this problem was with AOL's proxy servers.
+<P>The first major indication of this problem was with AOL's proxy servers.
 When Apache 1.2 went into beta it was the first wide-spread HTTP/1.1
 server.  After some discussion, AOL fixed their proxies.  In
-anticipation of similar problems, the <code>force-response-1.0</code>
+anticipation of similar problems, the <CODE>force-response-1.0</CODE>
 environment variable was added to Apache.  When present Apache will
 indicate "HTTP/1.0" in response to an HTTP/1.0 client,
 but will not in any other way change the response.
 
-<p>The pre-1.1 Java Development Kit (JDK) that is used in many clients
+<P>The pre-1.1 Java Development Kit (JDK) that is used in many clients
 (including Navigator 3.x and MSIE 3.x) exhibits this problem.  As do some
 of the early pre-releases of the 1.1 JDK.  We think it is fixed in the
 1.1 JDK release.  In any event the workaround:
-<blockquote><code>
-BrowserMatch Java1.0 force-response-1.0 <br>
+<BLOCKQUOTE><CODE>
+BrowserMatch Java1.0 force-response-1.0 <BR>
 BrowserMatch JDK/1.0 force-response-1.0 
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
-<p>RealPlayer 4.0 from Progressive Networks also exhibits this problem.
+<P>RealPlayer 4.0 from Progressive Networks also exhibits this problem.
 However they have fixed it in version 4.01 of the player, but version
-4.01 uses the same <code>User-Agent</code> as version 4.0.  The
+4.01 uses the same <CODE>User-Agent</CODE> as version 4.0.  The
 workaround is still:
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 BrowserMatch "RealPlayer 4.0" force-response-1.0
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
-<a name="msie4.0b2"><h3>Requests use HTTP/1.1 but responses must be in HTTP/1.0</h3></a>
+<A name="msie4.0b2"><h3>Requests use HTTP/1.1 but responses must be in HTTP/1.0</h3></A>
 
-<p>MSIE 4.0b2 has this problem.  Its Java VM makes requests in HTTP/1.1
+<P>MSIE 4.0b2 has this problem.  Its Java VM makes requests in HTTP/1.1
 format but the responses must be in HTTP/1.0 format (in particular, it
-does not understand <i>chunked</i> responses).  The workaround
+does not understand <EM>chunked</EM> responses).  The workaround
 is to fool Apache into believing the request came in HTTP/1.0 format.
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 This workaround is available in 1.2.2, and in a
-<a href="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">patch
-</a> against 1.2.1.
+<A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">patch
+</A> against 1.2.1.
 
-<a name="257th-byte"><h3>Boundary problems with header parsing</h3></a>
+<A name="257th-byte"><h3>Boundary problems with header parsing</h3></A>
 
-<p>All versions of Navigator from 2.0 through 4.0b2 (and possibly later)
+<P>All versions of Navigator from 2.0 through 4.0b2 (and possibly later)
 have a problem if the trailing CRLF of the response header starts at
 offset 256, 257 or 258 of the response.  A BrowserMatch for this would
 match on nearly every hit, so the workaround is enabled automatically
@@ -135,18 +135,18 @@ on all responses.  The workaround is to detect when this condition would
 occur in a response and add extra padding to the header to push the
 trailing CRLF past offset 258 of the response.
 
-<a name="boundary-string"><h3>Multipart responses and Quoted Boundary Strings</h3></a>
+<A name="boundary-string"><h3>Multipart responses and Quoted Boundary Strings</h3></A>
 
-<p>On multipart responses some clients will not accept quotes (")
+<P>On multipart responses some clients will not accept quotes (")
 around the boundary string.  The MIME standard recommends that
 such quotes be used.  But the clients were probably written based
 on one of the examples in RFC2068, which does not include quotes.
 Apache does not include quotes on its boundary strings to workaround
 this problem.
 
-<a name="byterange-requests"><h3>Byterange requests</h3></a>
+<A name="byterange-requests"><h3>Byterange requests</h3></A>
 
-<p>A byterange request is used when the client wishes to retrieve a
+<P>A byterange request is used when the client wishes to retrieve a
 portion of an object, not necessarily the entire object.  There
 was a very old draft which included these byteranges in the URL.
 Old clients such as Navigator 2.0b1 and MSIE 3.0 for the MAC
@@ -155,66 +155,66 @@ it will appear in the servers' access logs as (failed) attempts to
 retrieve a URL with a trailing ";xxx-yyy".  Apache does not attempt
 to implement this at all.
 
-<p>A subsequent draft of this standard defines a header
-<code>Request-Range</code>, and a response type
-<code>multipart/x-byteranges</code>.  The HTTP/1.1 standard includes
+<P>A subsequent draft of this standard defines a header
+<CODE>Request-Range</CODE>, and a response type
+<CODE>multipart/x-byteranges</CODE>.  The HTTP/1.1 standard includes
 this draft with a few fixes, and it defines the header
-<code>Range</code> and type <code>multipart/byteranges</code>.
-
-<p>Navigator (versions 2 and 3) sends both <code>Range</code> and
-<code>Request-Range</code> headers (with the same value), but does not
-accept a <code>multipart/byteranges</code> response.  The response must
-be <code>multipart/x-byteranges</code>.  As a workaround, if Apache
-receives a <code>Request-Range</code> header it considers it "higher
-priority" than a <code>Range</code> header and in response uses
-<code>multipart/x-byteranges</code>.
-
-<p>The Adobe Acrobat Reader plugin makes extensive use of byteranges and
-prior to version 3.01 supports only the <code>multipart/x-byterange</code>
+<CODE>Range</CODE> and type <CODE>multipart/byteranges</CODE>.
+
+<P>Navigator (versions 2 and 3) sends both <CODE>Range</CODE> and
+<CODE>Request-Range</CODE> headers (with the same value), but does not
+accept a <CODE>multipart/byteranges</CODE> response.  The response must
+be <CODE>multipart/x-byteranges</CODE>.  As a workaround, if Apache
+receives a <CODE>Request-Range</CODE> header it considers it "higher
+priority" than a <CODE>Range</CODE> header and in response uses
+<CODE>multipart/x-byteranges</CODE>.
+
+<P>The Adobe Acrobat Reader plugin makes extensive use of byteranges and
+prior to version 3.01 supports only the <CODE>multipart/x-byterange</CODE>
 response.  Unfortunately there is no clue that it is the plugin
 making the request.  If the plugin is used with Navigator, the above
 workaround works fine.  But if the plugin is used with MSIE 3 (on
 Windows) the workaround won't work because MSIE 3 doesn't give the
-<code>Range-Request</code> clue that Navigator does.  To workaround this,
-Apache special cases "MSIE 3" in the <code>User-Agent</code> and serves
-<code>multipart/x-byteranges</code>.  Note that the necessity for this
+<CODE>Range-Request</CODE> clue that Navigator does.  To workaround this,
+Apache special cases "MSIE 3" in the <CODE>User-Agent</CODE> and serves
+<CODE>multipart/x-byteranges</CODE>.  Note that the necessity for this
 with MSIE 3 is actually due to the Acrobat plugin, not due to the browser.
 
-<p>Netscape Communicator appears to not issue the non-standard
-<code>Request-Range</code> header.  When an Acrobat plugin prior to
+<P>Netscape Communicator appears to not issue the non-standard
+<CODE>Request-Range</CODE> header.  When an Acrobat plugin prior to
 version 3.01 is used with it, it will not properly understand byteranges.
 The user must upgrade their Acrobat reader to 3.01.
 
-<a name="cookie-merge"><h3><code>Set-Cookie</code> header is unmergeable</h3></a>
+<A name="cookie-merge"><h3><CODE>Set-Cookie</CODE> header is unmergeable</h3></A>
 
-<p>The HTTP specifications say that it is legal to merge headers with
+<P>The HTTP specifications say that it is legal to merge headers with
 duplicate names into one (separated by semicolon).  Some browsers
 that support Cookies don't like merged headers and prefer that each
-<code>Set-Cookie</code> header is sent separately.  When parsing the
+<CODE>Set-Cookie</CODE> header is sent separately.  When parsing the
 headers returned by a CGI, Apache will explicitly avoid merging any
-<code>Set-Cookie</code> headers.
+<CODE>Set-Cookie</CODE> headers.
 
-<a name="gif89-expires"><h3><code>Expires</code> headers and GIF89A animations</h3></a>
+<A name="gif89-expires"><h3><CODE>Expires</CODE> headers and GIF89A animations</h3></A>
 
-<p>Navigator versions 2 through 4 will erroneously re-request
+<P>Navigator versions 2 through 4 will erroneously re-request
 GIF89A animations on each loop of the animation if the first
-response included an <code>Expires</code> header.  This happens
+response included an <CODE>Expires</CODE> header.  This happens
 regardless of how far in the future the expiry time is set.  There
-is no workaround supplied with Apache, however there are hacks for <a
-href="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch">1.2</a>
-and for <a
-href="http://www.arctic.org/~dgaudet/patches/apache-1.3-gif89-expires-hack.patch">1.3</a>.
+is no workaround supplied with Apache, however there are hacks for <A
+HREF="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch">1.2</A>
+and for <A
+HREF="http://www.arctic.org/~dgaudet/patches/apache-1.3-gif89-expires-hack.patch">1.3</A>.
 
-<a name="no-content-length"><h3><code>POST</code> without <code>Content-Length</code></h3></a>
+<A name="no-content-length"><h3><CODE>POST</CODE> without <CODE>Content-Length</CODE></h3></A>
 
-<p>In certain situations Navigator 3.01 through 3.03 appear to incorrectly
+<P>In certain situations Navigator 3.01 through 3.03 appear to incorrectly
 issue a POST without the request body.  There is no
 known workaround.  It has been fixed in Navigator 3.04, Netscapes
 provides some
-<a href="http://help.netscape.com/kb/client/971014-42.html">information</a>.
+<A HREF="http://help.netscape.com/kb/client/971014-42.html">information</A>.
 There's also
-<a href="http://www.arctic.org/~dgaudet/apache/no-content-length/">
-some information</a> about the actual problem.
+<A HREF="http://www.arctic.org/~dgaudet/apache/no-content-length/">
+some information</A> about the actual problem.
 
 <!--#include virtual="footer.html" -->
 </BODY>
index f75fbf926b1da09c70c81539c5651fe3ec5a59d3..33aab731a6d26e3cc90c21dc248f08868f7844cd 100644 (file)
@@ -1,15 +1,15 @@
-<html>
-<head>
-<title>Apache Performance Notes</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache Performance Notes</TITLE>
+</HEAD>
 <body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#000080" alink="#ff0000">
 
-<h1>Apache Performance Notes</h1>
+<H1>Apache Performance Notes</H1>
 
-<p>Author: Dean Gaudet
+<P>Author: Dean Gaudet
 
 <h3>Introduction</h3>
-<p>Apache is a general webserver, which is designed to be correct first, and
+<P>Apache is a general webserver, which is designed to be correct first, and
 fast second.  Even so, it's performance is quite satisfactory.  Most
 sites have less than 10Mbits of outgoing bandwidth, which Apache can
 fill using only a low end Pentium-based webserver.  In practice sites
@@ -18,7 +18,7 @@ due to other constraints (such as CGI or database transaction overhead).
 For these reasons the development focus has been mostly on correctness
 and configurability.
 
-<p>Unfortunately many folks overlook these facts and cite raw performance
+<P>Unfortunately many folks overlook these facts and cite raw performance
 numbers as if they are some indication of the quality of a web server
 product.  There is a bare minimum performance that is acceptable, beyond
 that extra speed only caters to a much smaller segment of the market.
@@ -26,32 +26,32 @@ But in order to avoid this hurdle to the acceptance of Apache in some
 markets, effort was put into Apache 1.3 to bring performance up to a
 point where the difference with other high-end webservers is minimal.
 
-<p>Finally there are the folks who just plain want to see how fast something
+<P>Finally there are the folks who just plain want to see how fast something
 can go.  The author falls into this category.  The rest of this document
 is dedicated to these folks who want to squeeze every last bit of
 performance out of Apache's current model, and want to understand why
 it does some things which slow it down.
 
-<p>Note that this is tailored towards Apache 1.3 on Unix.  Some of it applies
+<P>Note that this is tailored towards Apache 1.3 on Unix.  Some of it applies
 to Apache on NT.  Apache on NT has not been tuned for performance yet,
 in fact it probably performs very poorly because NT performance requires
 a different programming model.
 
 <h3>Hardware and Operating System Issues</h3>
 
-<p>The single biggest hardware issue affecting webserver performance
+<P>The single biggest hardware issue affecting webserver performance
 is RAM.  A webserver should never ever have to swap, swapping increases
 the latency of each request beyond a point that users consider "fast
 enough".  This causes users to hit stop and reload, further increasing
-the load.  You can, and should, control the <code>MaxClients</code>
+the load.  You can, and should, control the <CODE>MaxClients</CODE>
 setting so that your server does not spawn so many children it starts
 swapping.
 
-<p>Beyond that the rest is mundane:  get a fast enough CPU, a fast enough
+<P>Beyond that the rest is mundane:  get a fast enough CPU, a fast enough
 network card, and fast enough disks, where "fast enough" is something
 that needs to be determined by experimentation.
 
-<p>Operating system choice is largely a matter of local concerns.  But
+<P>Operating system choice is largely a matter of local concerns.  But
 a general guideline is to always apply the latest vendor TCP/IP patches.
 HTTP serving completely breaks many of the assumptions built into Unix
 kernels up through 1994 and even 1995.  Good choices include
@@ -60,56 +60,56 @@ recent FreeBSD, and Linux.
 <h3>Run-Time Configuration Issues</h3>
 
 <h4>HostnameLookups</h4>
-<p>Prior to Apache 1.3, <code>HostnameLookups</code> defaulted to On.
+<P>Prior to Apache 1.3, <CODE>HostnameLookups</CODE> defaulted to On.
 This adds latency
 to every request because it requires a DNS lookup to complete before
 the request is finished.  In Apache 1.3 this setting defaults to Off.
-However (1.3 or later), if you use any <code>allow from domain</code> or
-<code>deny from domain</code> directives then you will pay for a
+However (1.3 or later), if you use any <CODE>allow from domain</CODE> or
+<CODE>deny from domain</CODE> directives then you will pay for a
 double reverse DNS lookup (a reverse, followed by a forward to make sure
 that the reverse is not being spoofed).  So for the highest performance
 avoid using these directives (it's fine to use IP addresses rather than
 domain names).
 
-<p>Note that it's possible to scope the directives, such as within
-a <code>&lt;Location /server-status&gt;</code> section.  In this
+<P>Note that it's possible to scope the directives, such as within
+a <CODE>&lt;Location /server-status&gt;</CODE> section.  In this
 case the DNS lookups are only performed on requests matching the
 criteria.  Here's an example which disables
 lookups except for .html and .cgi files:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 HostnameLookups off
 &lt;Files ~ "\.(html|cgi)$&gt;
     HostnameLookups on
 &lt;/Files&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 But even still, if you just need DNS names
 in some CGIs you could consider doing the
-<code>gethostbyname</code> call in the specific CGIs that need it.
+<CODE>gethostbyname</CODE> call in the specific CGIs that need it.
 
 <h4>FollowSymLinks and SymLinksIfOwnerMatch</h4>
-<p>Wherever in your URL-space you do not have an
-<code>Options FollowSymLinks</code>, or you do have an
-<code>Options SymLinksIfOwnerMatch</code> Apache will have to
+<P>Wherever in your URL-space you do not have an
+<CODE>Options FollowSymLinks</CODE>, or you do have an
+<CODE>Options SymLinksIfOwnerMatch</CODE> Apache will have to
 issue extra system calls to check up on symlinks.  One extra call per
 filename component.  For example, if you had:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 DocumentRoot /www/htdocs
 &lt;Directory /&gt;
     Options SymLinksIfOwnerMatch
 &lt;/Directory&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-and a request is made for the URI <code>/index.html</code>.
-Then Apache will perform <code>lstat(2)</code> on <code>/www</code>,
-<code>/www/htdocs</code>, and <code>/www/htdocs/index.html</code>.  The
-results of these <code>lstats</code> are never cached,
+and a request is made for the URI <CODE>/index.html</CODE>.
+Then Apache will perform <CODE>lstat(2)</CODE> on <CODE>/www</CODE>,
+<CODE>/www/htdocs</CODE>, and <CODE>/www/htdocs/index.html</CODE>.  The
+results of these <CODE>lstats</CODE> are never cached,
 so they will occur on every single request.  If you really desire the
 symlinks security checking you can do something like this:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 DocumentRoot /www/htdocs
 &lt;Directory /&gt;
     Options FollowSymLinks
@@ -117,72 +117,72 @@ DocumentRoot /www/htdocs
 &lt;Directory /www/htdocs&gt;
     Options -FollowSymLinks +SymLinksIfOwnerMatch
 &lt;/Directory&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-This at least avoids the extra checks for the <code>DocumentRoot</code>
+This at least avoids the extra checks for the <CODE>DocumentRoot</CODE>
 path.  Note that you'll need to add similar sections if you have any
-<code>Alias</code> or <code>RewriteRule</code> paths outside of your
+<CODE>Alias</CODE> or <CODE>RewriteRule</CODE> paths outside of your
 document root.  For highest performance, and no symlink protection,
-set <code>FollowSymLinks</code> everywhere, and never set
-<code>SymLinksIfOwnerMatch</code>.
+set <CODE>FollowSymLinks</CODE> everywhere, and never set
+<CODE>SymLinksIfOwnerMatch</CODE>.
 
 <h4>AllowOverride</h4>
 
-<p>Wherever in your URL-space you allow overrides (typically
-<code>.htaccess</code> files) Apache will attempt to open
-<code>.htaccess</code> for each filename component.  For example,
+<P>Wherever in your URL-space you allow overrides (typically
+<CODE>.htaccess</CODE> files) Apache will attempt to open
+<CODE>.htaccess</CODE> for each filename component.  For example,
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 DocumentRoot /www/htdocs
 &lt;Directory /&gt;
     AllowOverride all
 &lt;/Directory&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-and a request is made for the URI <code>/index.html</code>.  Then
-Apache will attempt to open <code>/.htaccess</code>,
-<code>/www/.htaccess</code>, and <code>/www/htdocs/.htaccess</code>.
-The solutions are similar to the previous case of <code>Options
-FollowSymLinks</code>.  For highest performance use
-<code>AllowOverride None</code> everywhere in your filesystem.
+and a request is made for the URI <CODE>/index.html</CODE>.  Then
+Apache will attempt to open <CODE>/.htaccess</CODE>,
+<CODE>/www/.htaccess</CODE>, and <CODE>/www/htdocs/.htaccess</CODE>.
+The solutions are similar to the previous case of <CODE>Options
+FollowSymLinks</CODE>.  For highest performance use
+<CODE>AllowOverride None</CODE> everywhere in your filesystem.
 
 <h4>Negotiation</h4>
 
-<p>If at all possible, avoid content-negotiation if you're really
+<P>If at all possible, avoid content-negotiation if you're really
 interested in every last ounce of performance.  In practice the
 benefits of negotiation outweigh the performance penalties.  There's
 one case where you can speed up the server.  Instead of using
 a wildcard such as:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 DirectoryIndex index
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 Use a complete list of options:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 DirectoryIndex index.cgi index.pl index.shtml index.html
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 where you list the most common choice first.
 
 <h4>Process Creation</h4>
 
-<p>Prior to Apache 1.3 the <code>MinSpareServers</code>,
-<code>MaxSpareServers</code>, and <code>StartServers</code> settings
+<P>Prior to Apache 1.3 the <CODE>MinSpareServers</CODE>,
+<CODE>MaxSpareServers</CODE>, and <CODE>StartServers</CODE> settings
 all had drastic effects on benchmark results.  In particular, Apache
 required a "ramp-up" period in order to reach a number of children
 sufficient to serve the load being applied.  After the initial
-spawning of <code>StartServers</code> children, only one child per
-second would be created to satisfy the <code>MinSpareServers</code>
+spawning of <CODE>StartServers</CODE> children, only one child per
+second would be created to satisfy the <CODE>MinSpareServers</CODE>
 setting.  So a server being accessed by 100 simultaneous clients,
-using the default <code>StartServers</code> of 5 would take on
+using the default <CODE>StartServers</CODE> of 5 would take on
 the order 95 seconds to spawn enough children to handle the load.  This
 works fine in practice on real-life servers, because they aren't restarted
 frequently.  But does really poorly on benchmarks which might only run
 for ten minutes.
 
-<p>The one-per-second rule was implemented in an effort to avoid
+<P>The one-per-second rule was implemented in an effort to avoid
 swamping the machine with the startup of new children.  If the machine
 is busy spawning children it can't service requests.  But it has such
 a drastic effect on the perceived performance of Apache that it had
@@ -191,61 +191,61 @@ the code will relax the one-per-second rule.  It
 will spawn one, wait a second, then spawn two, wait a second, then spawn
 four, and it will continue exponentially until it is spawning 32 children
 per second.  It will stop whenever it satisfies the
-<code>MinSpareServers</code> setting.
+<CODE>MinSpareServers</CODE> setting.
 
-<p>This appears to be responsive enough that it's
-almost unnecessary to twiddle the <code>MinSpareServers</code>,
-<code>MaxSpareServers</code> and <code>StartServers</code> knobs.  When
+<P>This appears to be responsive enough that it's
+almost unnecessary to twiddle the <CODE>MinSpareServers</CODE>,
+<CODE>MaxSpareServers</CODE> and <CODE>StartServers</CODE> knobs.  When
 more than 4 children are spawned per second, a message will be emitted
-to the <code>ErrorLog</code>.  If you see a lot of these errors then
-consider tuning these settings.  Use the <code>mod_status</code> output
+to the <CODE>ErrorLog</CODE>.  If you see a lot of these errors then
+consider tuning these settings.  Use the <CODE>mod_status</CODE> output
 as a guide.
 
-<p>Related to process creation is process death induced by the
-<code>MaxRequestsPerChild</code> setting.  By default this is 30, which
+<P>Related to process creation is process death induced by the
+<CODE>MaxRequestsPerChild</CODE> setting.  By default this is 30, which
 is probably far too low unless your server is using a module such as
-<code>mod_perl</code> which causes children to have bloated memory
+<CODE>mod_perl</CODE> which causes children to have bloated memory
 images.  If your server is serving mostly static pages then consider
 raising this value to something like 10000.  The code is robust enough
 that this shouldn't be a problem.
 
-<p>When keep-alives are in use, children will be kept busy
+<P>When keep-alives are in use, children will be kept busy
 doing nothing waiting for more requests on the already open
-connection.  The default <code>KeepAliveTimeout</code> of
+connection.  The default <CODE>KeepAliveTimeout</CODE> of
 15 seconds attempts to minimize this effect.  The tradeoff
 here is between network bandwidth and server resources.
 In no event should you raise this above about 60 seconds, as
-<a href="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html">
-most of the benefits are lost</a>.
+<A HREF="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html">
+most of the benefits are lost</A>.
 
 <h3>Compile-Time Configuration Issues</h3>
 
 <h4>mod_status and Rule STATUS=yes</h4>
 
-<p>If you include <code>mod_status</code>
-and you also set <code>Rule STATUS=yes</code> when building
+<P>If you include <CODE>mod_status</CODE>
+and you also set <CODE>Rule STATUS=yes</CODE> when building
 Apache, then on every request Apache will perform two calls to
-<code>gettimeofday(2)</code> (or <code>times(2)</code> depending
+<CODE>gettimeofday(2)</CODE> (or <CODE>times(2)</CODE> depending
 on your operating system), and (pre-1.3) several extra calls to
-<code>time(2)</code>.  This is all done so that the status report
-contains timing indications.  For highest performance, set <code>Rule
-STATUS=no</code>.
+<CODE>time(2)</CODE>.  This is all done so that the status report
+contains timing indications.  For highest performance, set <CODE>Rule
+STATUS=no</CODE>.
 
 <h4>accept Serialization - multiple sockets</h4>
 
-<p>This discusses a shortcoming in the Unix socket API.
+<P>This discusses a shortcoming in the Unix socket API.
 Suppose your
-web server uses multiple <code>Listen</code> statements to listen on
+web server uses multiple <CODE>Listen</CODE> statements to listen on
 either multiple ports or multiple addresses.  In order to test each
-socket to see if a connection is ready Apache uses <code>select(2)</code>.
-<code>select(2)</code> indicates that a socket has <i>none</i> or
-<i>at least one</i> connection waiting on it.  Apache's model includes
+socket to see if a connection is ready Apache uses <CODE>select(2)</CODE>.
+<CODE>select(2)</CODE> indicates that a socket has <EM>none</EM> or
+<EM>at least one</EM> connection waiting on it.  Apache's model includes
 multiple children, and all the idle ones test for new connections at the
 same time.  A naive implementation looks something like this
 (these examples do not match the code, they're contrived for
 pedagogical purposes):
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     for (;;) {
        for (;;) {
            fd_set accept_fds;
@@ -267,43 +267,43 @@ pedagogical purposes):
        }
        process the new_connection;
     }
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 But this naive implementation has a serious starvation problem.  Recall
 that multiple children execute this loop at the same time, and so multiple
-children will block at <code>select</code> when they are in between
+children will block at <CODE>select</CODE> when they are in between
 requests.  All those blocked children will awaken and return from
-<code>select</code> when a single request appears on any socket
+<CODE>select</CODE> when a single request appears on any socket
 (the number of children which awaken varies depending on the operating
 system and timing issues).
-They will all then fall down into the loop and try to <code>accept</code>
+They will all then fall down into the loop and try to <CODE>accept</CODE>
 the connection.  But only one will succeed (assuming there's still only
-one connection ready), the rest will be <i>blocked</i> in <code>accept</code>.
+one connection ready), the rest will be <EM>blocked</EM> in <CODE>accept</CODE>.
 This effectively locks those children into serving requests from that
 one socket and no other sockets, and they'll be stuck there until enough
 new requests appear on that socket to wake them all up.
 This starvation problem was first documented in
-<a href="http://bugs.apache.org/index/full/467">PR#467</a>.  There
+<A HREF="http://bugs.apache.org/index/full/467">PR#467</A>.  There
 are at least two solutions.
 
-<p>One solution is to make the sockets non-blocking.  In this case the
-<code>accept</code> won't block the children, and they will be allowed
+<P>One solution is to make the sockets non-blocking.  In this case the
+<CODE>accept</CODE> won't block the children, and they will be allowed
 to continue immediately.  But this wastes CPU time.  Suppose you have
-ten idle children in <code>select</code>, and one connection arrives.
-Then nine of those children will wake up, try to <code>accept</code> the
-connection, fail, and loop back into <code>select</code>, accomplishing
+ten idle children in <CODE>select</CODE>, and one connection arrives.
+Then nine of those children will wake up, try to <CODE>accept</CODE> the
+connection, fail, and loop back into <CODE>select</CODE>, accomplishing
 nothing.  Meanwhile none of those children are servicing requests that
-occurred on other sockets until they get back up to the <code>select</code>
+occurred on other sockets until they get back up to the <CODE>select</CODE>
 again.  Overall this solution does not seem very fruitful unless you
 have as many idle CPUs (in a multiprocessor box) as you have idle children,
 not a very likely situation.
 
-<p>Another solution, the one used by Apache, is to serialize entry into
+<P>Another solution, the one used by Apache, is to serialize entry into
 the inner loop.  The loop looks like this (differences highlighted):
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     for (;;) {
-       <b>accept_mutex_on ();</b>
+       <STRONG>accept_mutex_on ();</STRONG>
        for (;;) {
            fd_set accept_fds;
 
@@ -322,64 +322,64 @@ the inner loop.  The loop looks like this (differences highlighted):
            }
            if (new_connection != -1) break;
        }
-       <b>accept_mutex_off ();</b>
+       <STRONG>accept_mutex_off ();</STRONG>
        process the new_connection;
     }
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<a name="serialize"></a>
-The functions <code>accept_mutex_on</code> and <code>accept_mutex_off</code>
+<A name="serialize"></A>
+The functions <CODE>accept_mutex_on</CODE> and <CODE>accept_mutex_off</CODE>
 implement a mutual exclusion semaphore.  Only one child can have the
 mutex at any time.  There are several choices for implementing these
-mutexes.  The choice is defined in <code>src/conf.h</code> (pre-1.3) or
-<code>src/main/conf.h</code> (1.3 or later).  Some architectures
+mutexes.  The choice is defined in <CODE>src/conf.h</CODE> (pre-1.3) or
+<CODE>src/main/conf.h</CODE> (1.3 or later).  Some architectures
 do not have any locking choice made, on these architectures it is unsafe
-to use multiple <code>Listen</code> directives.
+to use multiple <CODE>Listen</CODE> directives.
 
-<dl>
-<dt><code>USE_FLOCK_SERIALIZED_ACCEPT</code>
-<dd>This method uses the <code>flock(2)</code> system call to lock a
-lock file (located by the <code>LockFile</code> directive).
+<DL>
+<DT><CODE>USE_FLOCK_SERIALIZED_ACCEPT</CODE>
+<DD>This method uses the <CODE>flock(2)</CODE> system call to lock a
+lock file (located by the <CODE>LockFile</CODE> directive).
 
-<dt><code>USE_FCNTL_SERIALIZED_ACCEPT</code>
-<dd>This method uses the <code>fcntl(2)</code> system call to lock a
-lock file (located by the <code>LockFile</code> directive).
+<DT><CODE>USE_FCNTL_SERIALIZED_ACCEPT</CODE>
+<DD>This method uses the <CODE>fcntl(2)</CODE> system call to lock a
+lock file (located by the <CODE>LockFile</CODE> directive).
 
-<dt><code>USE_SYSVSEM_SERIALIZED_ACCEPT</code>
-<dd>(1.3 or later) This method uses SysV-style semaphores to implement the
+<DT><CODE>USE_SYSVSEM_SERIALIZED_ACCEPT</CODE>
+<DD>(1.3 or later) This method uses SysV-style semaphores to implement the
 mutex.  Unfortunately SysV-style semaphores have some bad side-effects.
 One is that it's possible Apache will die without cleaning up the semaphore
-(see the <code>ipcs(8)</code> man page).  The other is that the semaphore
+(see the <CODE>ipcs(8)</CODE> man page).  The other is that the semaphore
 API allows for a denial of service attack by any CGIs running under the
 same uid as the webserver (i.e. all CGIs unless you use something
 like suexec or cgiwrapper).  For these reasons this method is not used
 on any architecture except IRIX (where the previous two are prohibitively
 expensive on most IRIX boxes).
 
-<dt><code>USE_USLOCK_SERIALIZED_ACCEPT</code>
-<dd>(1.3 or later) This method is only available on IRIX, and uses
-<code>usconfig(2)</code> to create a mutex.  While this method avoids
+<DT><CODE>USE_USLOCK_SERIALIZED_ACCEPT</CODE>
+<DD>(1.3 or later) This method is only available on IRIX, and uses
+<CODE>usconfig(2)</CODE> to create a mutex.  While this method avoids
 the hassles of SysV-style semaphores, it is not the default for IRIX.
 This is because on single processor IRIX boxes (5.3 or 6.2) the
 uslock code is two orders of magnitude slower than the SysV-semaphore
 code.  On multi-processor IRIX boxes the uslock code is an order of magnitude
 faster than the SysV-semaphore code.  Kind of a messed up situation.
 So if you're using a multiprocessor IRIX box then you should rebuild your
-webserver with <code>-DUSE_USLOCK_SERIALIZED_ACCEPT</code> on the
-<code>EXTRA_CFLAGS</code>.
+webserver with <CODE>-DUSE_USLOCK_SERIALIZED_ACCEPT</CODE> on the
+<CODE>EXTRA_CFLAGS</CODE>.
 
-<dt><code>USE_PTHREAD_SERIALIZED_ACCEPT</code>
-<dd>(1.3 or later) This method uses POSIX mutexes and should work on
+<DT><CODE>USE_PTHREAD_SERIALIZED_ACCEPT</CODE>
+<DD>(1.3 or later) This method uses POSIX mutexes and should work on
 any architecture implementing the full POSIX threads specification,
 however appears to only work on Solaris (2.5 or later).  This is the
 default for Solaris 2.5 or later.
-</dl>
+</DL>
 
-<p>If your system has another method of serialization which isn't in the
+<P>If your system has another method of serialization which isn't in the
 above list then it may be worthwhile adding code for it (and submitting
 a patch back to Apache).
 
-<p>Another solution that has been considered but never implemented is
+<P>Another solution that has been considered but never implemented is
 to partially serialize the loop -- that is, let in a certain number
 of processes.  This would only be of interest on multiprocessor boxes
 where it's possible multiple children could run simultaneously, and the
@@ -387,26 +387,26 @@ serialization actually doesn't take advantage of the full bandwidth.
 This is a possible area of future investigation, but priority remains
 low because highly parallel web servers are not the norm.
 
-<p>Ideally you should run servers without multiple <code>Listen</code>
+<P>Ideally you should run servers without multiple <CODE>Listen</CODE>
 statements if you want the highest performance.  But read on.
 
 <h4>accept Serialization - single socket</h4>
 
-<p>The above is fine and dandy for multiple socket servers, but what
+<P>The above is fine and dandy for multiple socket servers, but what
 about single socket servers?  In theory they shouldn't experience
 any of these same problems because all children can just block in
-<code>accept(2)</code> until a connection arrives, and no starvation
+<CODE>accept(2)</CODE> until a connection arrives, and no starvation
 results.  In practice this hides almost the same "spinning" behaviour
 discussed above in the non-blocking solution.  The way that most TCP
 stacks are implemented, the kernel actually wakes up all processes blocked
-in <code>accept</code> when a single connection arrives.  One of those
+in <CODE>accept</CODE> when a single connection arrives.  One of those
 processes gets the connection and returns to user-space, the rest spin in
 the kernel and go back to sleep when they discover there's no connection
 for them.  This spinning is hidden from the user-land code, but it's
 there nonetheless.  This can result in the same load-spiking wasteful
 behaviour that a non-blocking solution to the multiple sockets case can.
 
-<p>For this reason we have found that many architectures behave more
+<P>For this reason we have found that many architectures behave more
 "nicely" if we serialize even the single socket case.  So this is
 actually the default in almost all cases.  Crude experiments under
 Linux (2.0.30 on a dual Pentium pro 166 w/128Mb RAM) have shown that
@@ -415,20 +415,20 @@ decrease in requests per second over unserialized single-socket.
 But unserialized single-socket showed an extra 100ms latency on
 each request.  This latency is probably a wash on long haul lines,
 and only an issue on LANs.  If you want to override the single socket
-serialization you can define <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code>
+serialization you can define <CODE>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</CODE>
 and then single-socket servers will not serialize at all.
 
 <h4>Lingering Close</h4>
 
-<p>As discussed in
-<a href="ftp://ds.internic.net/internet-drafts/draft-ietf-http-connection-00.txt">draft-ietf-http-connection-00.txt</a> section 8,
-in order for an HTTP server to <b>reliably</b> implement the protocol
+<P>As discussed in
+<A HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-http-connection-00.txt">draft-ietf-http-connection-00.txt</A> section 8,
+in order for an HTTP server to <STRONG>reliably</STRONG> implement the protocol
 it needs to shutdown each direction of the communication independently
 (recall that a TCP connection is bi-directional, each half is independent
 of the other).  This fact is often overlooked by other servers, but
 is correctly implemented in Apache as of 1.2.
 
-<p>When this feature was added to Apache it caused a flurry of
+<P>When this feature was added to Apache it caused a flurry of
 problems on various versions of Unix because of a shortsightedness.
 The TCP specification does not state that the FIN_WAIT_2 state has a
 timeout, but it doesn't prohibit it.  On systems without the timeout,
@@ -438,17 +438,17 @@ TCP/IP patches supplied by the vendor, in cases where the vendor has
 never released patches (i.e.  SunOS4 -- although folks with a source
 license can patch it themselves) we have decided to disable this feature.
 
-<p>There are two ways of accomplishing this.  One is the
-socket option <code>SO_LINGER</code>.  But as fate would have it,
+<P>There are two ways of accomplishing this.  One is the
+socket option <CODE>SO_LINGER</CODE>.  But as fate would have it,
 this has never been implemented properly in most TCP/IP stacks.  Even
 on those stacks with a proper implementation (i.e. Linux 2.0.31) this
 method proves to be more expensive (cputime) than the next solution.
 
-<p>For the most part, Apache implements this in a function called
-<code>lingering_close</code> (in <code>http_main.c</code>).  The
+<P>For the most part, Apache implements this in a function called
+<CODE>lingering_close</CODE> (in <CODE>http_main.c</CODE>).  The
 function looks roughly like this:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     void lingering_close (int s)
     {
        char junk_buffer[2048];
@@ -470,48 +470,48 @@ function looks roughly like this:
 
        close (s);
     }
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 This naturally adds some expense at the end of a connection, but it
 is required for a reliable implementation.  As HTTP/1.1 becomes more
 prevalent, and all connections are persistent, this expense will be
 amortized over more requests.  If you want to play with fire and
-disable this feature you can define <code>NO_LINGCLOSE</code>, but
+disable this feature you can define <CODE>NO_LINGCLOSE</CODE>, but
 this is not recommended at all.  In particular, as HTTP/1.1 pipelined
-persistent connections come into use <code>lingering_close</code>
+persistent connections come into use <CODE>lingering_close</CODE>
 is an absolute necessity (and
-<a href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
-pipelined connections are faster</a>, so you
+<A HREF="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">
+pipelined connections are faster</A>, so you
 want to support them).
 
 <h4>Scoreboard File</h4>
 
-<p>Apache's parent and children communicate with each other through
+<P>Apache's parent and children communicate with each other through
 something called the scoreboard.  Ideally this should be implemented
 in shared memory.  For those operating systems that we either have
 access to, or have been given detailed ports for, it typically is
 implemented using shared memory.  The rest default to using an
 on-disk file.  The on-disk file is not only slow, but it is unreliable
-(and less featured).  Peruse the <code>src/main/conf.h</code> file
-for your architecture and look for either <code>USE_MMAP_SCOREBOARD</code> or
-<code>USE_SHMGET_SCOREBOARD</code>.  Defining one of those two (as
-well as their companions <code>HAVE_MMAP</code> and <code>HAVE_SHMGET</code>
+(and less featured).  Peruse the <CODE>src/main/conf.h</CODE> file
+for your architecture and look for either <CODE>USE_MMAP_SCOREBOARD</CODE> or
+<CODE>USE_SHMGET_SCOREBOARD</CODE>.  Defining one of those two (as
+well as their companions <CODE>HAVE_MMAP</CODE> and <CODE>HAVE_SHMGET</CODE>
 respectively) enables the supplied shared memory code.  If your system has
-another type of shared memory, edit the file <code>src/main/http_main.c</code>
+another type of shared memory, edit the file <CODE>src/main/http_main.c</CODE>
 and add the hooks necessary to use it in Apache.  (Send us back a patch
 too please.)
 
-<p>Historical note:  The Linux port of Apache didn't start to use
+<P>Historical note:  The Linux port of Apache didn't start to use
 shared memory until version 1.2 of Apache.  This oversight resulted
 in really poor and unreliable behaviour of earlier versions of Apache
 on Linux.
 
-<h4><code>DYNAMIC_MODULE_LIMIT</code></h4>
+<h4><CODE>DYNAMIC_MODULE_LIMIT</CODE></h4>
 
-<p>If you have no intention of using dynamically loaded modules
+<P>If you have no intention of using dynamically loaded modules
 (you probably don't if you're reading this and tuning your
 server for every last ounce of performance) then you should add
-<code>-DDYNAMIC_MODULE_LIMIT=0</code> when building your server.
+<CODE>-DDYNAMIC_MODULE_LIMIT=0</CODE> when building your server.
 This will save RAM that's allocated only for supporting dynamically
 loaded modules.
 
@@ -520,21 +520,21 @@ loaded modules.
 Here is a system call trace of Apache 1.3 running on Linux.  The run-time
 configuration file is essentially the default plus:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 &lt;Directory /&gt;
     AllowOverride none
     Options FollowSymLinks
 &lt;/Directory&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 The file being requested is a static 6K file of no particular content.
 Traces of non-static requests or requests with content negotiation
 look wildly different (and quite ugly in some cases).  First the
 entire trace, then we'll examine details.  (This was generated by
-the <code>strace</code> program, other similar programs include
-<code>truss</code>, <code>ktrace</code>, and <code>par</code>.)
+the <CODE>strace</CODE> program, other similar programs include
+<CODE>truss</CODE>, <CODE>ktrace</CODE>, and <CODE>par</CODE>.)
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 accept(15, {sin_family=AF_INET, sin_port=htons(22283), sin_addr=inet_addr("127.0.0.1")}, [16]) = 3
 flock(18, LOCK_UN)                      = 0
 sigaction(SIGUSR1, {SIG_IGN}, {0x8059954, [], SA_INTERRUPT}) = 0
@@ -560,31 +560,31 @@ close(3)                                = 0
 sigaction(SIGUSR1, {0x8059954, [], SA_INTERRUPT}, {SIG_IGN}) = 0
 munmap(0x400ee000, 6144)                = 0
 flock(18, LOCK_EX)                      = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<p>Notice the accept serialization:
+<P>Notice the accept serialization:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 flock(18, LOCK_UN)                      = 0
 ...
 flock(18, LOCK_EX)                      = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 These two calls can be removed by defining
-<code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code> as described earlier.
+<CODE>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</CODE> as described earlier.
 
-<p>Notice the <code>SIGUSR1</code> manipulation:
+<P>Notice the <CODE>SIGUSR1</CODE> manipulation:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 sigaction(SIGUSR1, {SIG_IGN}, {0x8059954, [], SA_INTERRUPT}) = 0
 ...
 sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}) = 0
 ...
 sigaction(SIGUSR1, {0x8059954, [], SA_INTERRUPT}, {SIG_IGN}) = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 This is caused by the implementation of graceful restarts.  When the
-parent receives a <code>SIGUSR1</code> it sends a <code>SIGUSR1</code>
+parent receives a <CODE>SIGUSR1</CODE> it sends a <CODE>SIGUSR1</CODE>
 to all of its children (and it also increments a "generation counter"
 in shared memory).  Any children that are idle (between connections)
 will immediately die
@@ -593,7 +593,7 @@ connections, but are in between requests will die off immediately.  But
 any children that have a connection and are still waiting for the first
 request will not die off immediately.
 
-<p>To see why this is necessary, consider how a browser reacts to a closed
+<P>To see why this is necessary, consider how a browser reacts to a closed
 connection.  If the connection was a keep-alive connection and the request
 being serviced was not the first request then the browser will quietly
 reissue the request on a new connection.  It has to do this because the
@@ -605,40 +605,40 @@ dialogue (or a broken image icon).  This is done on the assumption that
 the server is broken in some way (or maybe too overloaded to respond
 at all).  So Apache tries to avoid ever deliberately closing the connection
 before it has sent a single response.  This is the cause of those
-<code>SIGUSR1</code> manipulations.
+<CODE>SIGUSR1</CODE> manipulations.
 
-<p>Note that it is theoretically possible to eliminate all three of
+<P>Note that it is theoretically possible to eliminate all three of
 these calls.  But in rough tests the gain proved to be almost unnoticeable.
 
-<p>In order to implement virtual hosts, Apache needs to know the
+<P>In order to implement virtual hosts, Apache needs to know the
 local socket address used to accept the connection:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 getsockname(3, {sin_family=AF_INET, sin_port=htons(8080), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 It is possible to eliminate this call in many situations (such as when
-there are no virtual hosts, or when <code>Listen</code> directives are
+there are no virtual hosts, or when <CODE>Listen</CODE> directives are
 used which do not have wildcard addresses).  But no effort has yet been
 made to do these optimizations.
 
-<p>Apache turns off the Nagle algorithm:
+<P>Apache turns off the Nagle algorithm:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 setsockopt(3, IPPROTO_TCP1, [1], 4)     = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 because of problems described in 
-<a href="http://www.isi.edu/~johnh/PAPERS/Heidemann97a.html">a
-paper by John Heidemann</a>.
+<A HREF="http://www.isi.edu/~johnh/PAPERS/Heidemann97a.html">a
+paper by John Heidemann</A>.
 
-<p>Notice the two <code>time</code> calls:
+<P>Notice the two <CODE>time</CODE> calls:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 time(NULL)                              = 873959960
 ...
 time(NULL)                              = 873959960
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 One of these occurs at the beginning of the request, and the other occurs
 as a result of writing the log.  At least one of these is required to
@@ -647,115 +647,115 @@ Common Log Format dictates that the log record include a timestamp of the
 end of the request.  A custom logging module could eliminate one of the
 calls.
 
-<p>As described earlier, <code>Rule STATUS=yes</code> causes two
-<code>gettimeofday</code> calls and a call to <code>times</code>:
+<P>As described earlier, <CODE>Rule STATUS=yes</CODE> causes two
+<CODE>gettimeofday</CODE> calls and a call to <CODE>times</CODE>:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 gettimeofday({873959960, 404935}, NULL) = 0
 ...
 gettimeofday({873959960, 417742}, NULL) = 0
 times({tms_utime=5, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 446747
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-These can be removed by either removing <code>mod_status</code> or
-setting <code>Rule STATUS=no</code>.
+These can be removed by either removing <CODE>mod_status</CODE> or
+setting <CODE>Rule STATUS=no</CODE>.
 
-<p>It might seem odd to call <code>stat</code>:
+<P>It might seem odd to call <CODE>stat</CODE>:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 stat("/home/dgaudet/ap/apachen/htdocs/6k", {st_mode=S_IFREG|0644, st_size=6144, ...}) = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 This is part of the algorithm which calculates the
-<code>PATH_INFO</code> for use by CGIs.  In fact if the request had been
-for the URI <code>/cgi-bin/printenv/foobar</code> then there would be
-two calls to <code>stat</code>.  The first for
-<code>/home/dgaudet/ap/apachen/cgi-bin/printenv/foobar</code>
+<CODE>PATH_INFO</CODE> for use by CGIs.  In fact if the request had been
+for the URI <CODE>/cgi-bin/printenv/foobar</CODE> then there would be
+two calls to <CODE>stat</CODE>.  The first for
+<CODE>/home/dgaudet/ap/apachen/cgi-bin/printenv/foobar</CODE>
 which does not exist, and the second for
-<code>/home/dgaudet/ap/apachen/cgi-bin/printenv</code>, which does exist.
-Regardless, at least one <code>stat</code> call is necessary when
+<CODE>/home/dgaudet/ap/apachen/cgi-bin/printenv</CODE>, which does exist.
+Regardless, at least one <CODE>stat</CODE> call is necessary when
 serving static files because the file size and modification times are
-used to generate HTTP headers (such as <code>Content-Length</code>,
-<code>Last-Modified</code>) and implement protocol features (such
-as <code>If-Modified-Since</code>).  A somewhat more clever server
-could avoid the <code>stat</code> when serving non-static files,
+used to generate HTTP headers (such as <CODE>Content-Length</CODE>,
+<CODE>Last-Modified</CODE>) and implement protocol features (such
+as <CODE>If-Modified-Since</CODE>).  A somewhat more clever server
+could avoid the <CODE>stat</CODE> when serving non-static files,
 however doing so in Apache is very difficult given the modular structure.
 
-<p>All static files are served using <code>mmap</code>:
+<P>All static files are served using <CODE>mmap</CODE>:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 mmap(0, 6144, PROT_READ, MAP_PRIVATE, 4, 0) = 0x400ee000
 ...
 munmap(0x400ee000, 6144)                = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-On some architectures it's slower to <code>mmap</code> small
-files than it is to simply <code>read</code> them.  The define
-<code>MMAP_THRESHOLD</code> can be set to the minimum
-size required before using <code>mmap</code>.  By default
+On some architectures it's slower to <CODE>mmap</CODE> small
+files than it is to simply <CODE>read</CODE> them.  The define
+<CODE>MMAP_THRESHOLD</CODE> can be set to the minimum
+size required before using <CODE>mmap</CODE>.  By default
 it's set to 0 (except on SunOS4 where experimentation has
-shown 8192 to be a better value).  Using a tool such as <a
-href="http://reality.sgi.com/lm_engr/lmbench/lmbench.html">lmbench</a> you
+shown 8192 to be a better value).  Using a tool such as <A
+HREF="http://reality.sgi.com/lm_engr/lmbench/lmbench.html">lmbench</A> you
 can determine the optimal setting for your environment.
 
-<p>You may also wish to experiment with <code>MMAP_SEGMENT_SIZE</code>
+<P>You may also wish to experiment with <CODE>MMAP_SEGMENT_SIZE</CODE>
 (default 32768) which determines the maximum number of bytes that
 will be written at a time from mmap()d files.  Apache only resets the
-client's <code>Timeout</code> in between write()s.  So setting this
+client's <CODE>Timeout</CODE> in between write()s.  So setting this
 large may lock out low bandwidth clients unless you also increase the
-<code>Timeout</code>.
+<CODE>Timeout</CODE>.
 
-<p>It may even be the case that <code>mmap</code> isn't
-used on your architecture, if so then defining <code>USE_MMAP_FILES</code>
-and <code>HAVE_MMAP</code> might work (if it works then report back to us).
+<P>It may even be the case that <CODE>mmap</CODE> isn't
+used on your architecture, if so then defining <CODE>USE_MMAP_FILES</CODE>
+and <CODE>HAVE_MMAP</CODE> might work (if it works then report back to us).
 
-<p>Apache does its best to avoid copying bytes around in memory.  The
-first write of any request typically is turned into a <code>writev</code>
+<P>Apache does its best to avoid copying bytes around in memory.  The
+first write of any request typically is turned into a <CODE>writev</CODE>
 which combines both the headers and the first hunk of data:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 writev(3, [{"HTTP/1.1 200 OK\r\nDate: Thu, 11"..., 245}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 6144}], 2) = 6389
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 When doing HTTP/1.1 chunked encoding Apache will generate up to four
-element <code>writev</code>s.  The goal is to push the byte copying
+element <CODE>writev</CODE>s.  The goal is to push the byte copying
 into the kernel, where it typically has to happen anyhow (to assemble
 network packets).  On testing, various Unixes (BSDI 2.x, Solaris 2.5,
 Linux 2.0.31+) properly combine the elements into network packets.
 Pre-2.0.31 Linux will not combine, and will create a packet for
-each element, so upgrading is a good idea.  Defining <code>NO_WRITEV</code>
+each element, so upgrading is a good idea.  Defining <CODE>NO_WRITEV</CODE>
 will disable this combining, but result in very poor chunked encoding
 performance.
 
-<p>The log write:
+<P>The log write:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 write(17, "127.0.0.1 - - [10/Sep/1997:23:39"..., 71) = 71
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-can be deferred by defining <code>BUFFERED_LOGS</code>.  In this case
-up to <code>PIPE_BUF</code> bytes (a POSIX defined constant) of log entries
+can be deferred by defining <CODE>BUFFERED_LOGS</CODE>.  In this case
+up to <CODE>PIPE_BUF</CODE> bytes (a POSIX defined constant) of log entries
 are buffered before writing.  At no time does it split a log entry
-across a <code>PIPE_BUF</code> boundary because those writes may not
+across a <CODE>PIPE_BUF</CODE> boundary because those writes may not
 be atomic.  (i.e. entries from multiple children could become mixed together).
 The code does it best to flush this buffer when a child dies.
 
-<p>The lingering close code causes four system calls:
+<P>The lingering close code causes four system calls:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 shutdown(3, 1 /* send */)               = 0
 oldselect(4, [3], NULL, [3], {2, 0})    = 1 (in [3], left {2, 0})
 read(3, "", 2048)                       = 0
 close(3)                                = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 which were described earlier.
 
-<p>Let's apply some of these optimizations:
-<code>-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT -DBUFFERED_LOGS</code> and
-<code>Rule STATUS=no</code>.  Here's the final trace:
+<P>Let's apply some of these optimizations:
+<CODE>-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT -DBUFFERED_LOGS</CODE> and
+<CODE>Rule STATUS=no</CODE>.  Here's the final trace:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 accept(15, {sin_family=AF_INET, sin_port=htons(22286), sin_addr=inet_addr("127.0.0.1")}, [16]) = 3
 sigaction(SIGUSR1, {SIG_IGN}, {0x8058c98, [], SA_INTERRUPT}) = 0
 getsockname(3, {sin_family=AF_INET, sin_port=htons(8080), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
@@ -775,15 +775,15 @@ read(3, "", 2048)                       = 0
 close(3)                                = 0
 sigaction(SIGUSR1, {0x8058c98, [], SA_INTERRUPT}, {SIG_IGN}) = 0
 munmap(0x400e3000, 6144)                = 0
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 That's 19 system calls, of which 4 remain relatively easy to remove,
 but don't seem worth the effort.
 
 <h3>Appendix: The Pre-Forking Model</h3>
 
-<p>Apache (on Unix) is a <i>pre-forking</i> model server.  The
-<i>parent</i> process is responsible only for forking <i>child</i>
+<P>Apache (on Unix) is a <EM>pre-forking</EM> model server.  The
+<EM>parent</EM> process is responsible only for forking <EM>child</EM>
 processes, it does not serve any requests or service any network
 sockets.  The child processes actually process connections, they serve
 multiple connections (one at a time) before dying.
@@ -791,7 +791,7 @@ The parent spawns new or kills off old
 children in response to changes in the load on the server (it does so
 by monitoring a scoreboard which the children keep up to date).
 
-<p>This model for servers offers a robustness that other models do
+<P>This model for servers offers a robustness that other models do
 not.  In particular, the parent code is very simple, and with a high
 degree of confidence the parent will continue to do its job without
 error.  The children are complex, and when you add in third party
@@ -800,22 +800,22 @@ corruption.  Even should such a thing happen, it only affects one
 connection and the server continues serving requests.  The parent
 quickly replaces the dead child.
 
-<p>Pre-forking is also very portable across dialects of Unix.
+<P>Pre-forking is also very portable across dialects of Unix.
 Historically this has been an important goal for Apache, and it continues
 to remain so.
 
-<p>The pre-forking model comes under criticism for various
+<P>The pre-forking model comes under criticism for various
 performance aspects.  Of particular concern are the overhead
 of forking a process, the overhead of context switches between
 processes, and the memory overhead of having multiple processes.
 Furthermore it does not offer as many opportunities for data-caching
-between requests (such as a pool of <code>mmapped</code> files).
+between requests (such as a pool of <CODE>mmapped</CODE> files).
 Various other models exist and extensive analysis can be found in the
-<a href="http://www.cs.wustl.edu/~jxh/research/research.html"> papers
-of the JAWS project</a>.  In practice all of these costs vary drastically
+<A HREF="http://www.cs.wustl.edu/~jxh/research/research.html"> papers
+of the JAWS project</A>.  In practice all of these costs vary drastically
 depending on the operating system.
 
-<p>Apache's core code is already multithread aware, and Apache version
+<P>Apache's core code is already multithread aware, and Apache version
 1.3 is multithreaded on NT.  There have been at least two other experimental
 implementations of threaded Apache (one using the 1.3 code base on DCE,
 and one using a custom user-level threads package and the 1.0 code base,
@@ -824,5 +824,5 @@ of Apache will include abstractions of the server model so that we
 can continue to support the pre-forking model, and also support various
 threaded models.
 
-</body>
-</html>
+</BODY>
+</HTML>
index 715ccb90d7c7d2e0b431267ae2bdbe81f2012d63..d454122ebc88d41a2c9458a7c376ca00074c73d8 100644 (file)
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Security Tips for Server Configuration</H1>
 
-<hr>
+<HR>
 
 <P>Some hints and tips on security issues in setting up a web server. Some of
 the suggestions will be general, others specific to Apache.
 
 <HR>
 
-<a name="serverroot">
-<H2>Permissions on ServerRoot Directories</H2></a>
+<A name="serverroot">
+<H2>Permissions on ServerRoot Directories</H2></A>
 <P>In typical operation, Apache is started by the root
-user, and it switches to the user defined by the <a
-href="../mod/core.html#user"><b>User</b></a> directive to serve hits.
+user, and it switches to the user defined by the <A
+HREF="../mod/core.html#user"><STRONG>User</STRONG></A> directive to serve hits.
 As is the case with any command that root executes, you must take care
 that it is protected from modification by non-root users.  Not only
 must the files themselves be writeable only by root, but so must the
 directories, and parents of all directories.  For example, if you
-choose to place ServerRoot in <code>/usr/local/apache</code> then it is
+choose to place ServerRoot in <CODE>/usr/local/apache</CODE> then it is
 suggested that you create that directory as root, with commands
 like these:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     mkdir /usr/local/apache
     cd /usr/local/apache
     mkdir bin conf logs
     chown 0 . bin conf logs
     chgrp 0 . bin conf logs
     chmod 755 . bin conf logs
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 It is assumed that /, /usr, and /usr/local are only modifiable by root.
 When you install the httpd executable, you should ensure that it is
 similarly protected:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     cp httpd /usr/local/apache/bin
     chown 0 /usr/local/apache/bin/httpd
     chgrp 0 /usr/local/apache/bin/httpd
     chmod 511 /usr/local/apache/bin/httpd
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
-<p>You can create an htdocs subdirectory which is modifiable by other
+<P>You can create an htdocs subdirectory which is modifiable by other
 users -- since root never executes any files out of there, and shouldn't
 be creating files in there.
 
-<p>If you allow non-root users to modify any files that root either
+<P>If you allow non-root users to modify any files that root either
 executes or writes on then you open your system to root compromises.
 For example, someone could replace the httpd binary so that the next
 time you start it, it will execute some arbitrary code.  If the logs
@@ -73,16 +73,16 @@ may be able to overwrite the log itself with bogus data.
 <H2>Server Side Includes</H2>
 <P>Server side includes (SSI) can be configured so that users can execute
 arbitrary programs on the server. That thought alone should send a shiver
-down the spine of any sys-admin.<p>
+down the spine of any sys-admin.<P>
 
 One solution is to disable that part of SSI. To do that you use the
 IncludesNOEXEC option to the <A HREF="../mod/core.html#options">Options</A>
-directive.<p>
+directive.<P>
 
 <HR>
 
 <H2>Non Script Aliased CGI</H2>
-<P>Allowing users to execute <B>CGI</B> scripts in any directory should only
+<P>Allowing users to execute <STRONG>CGI</STRONG> scripts in any directory should only
 be considered if;
 <OL>
  <LI>You trust your users not to write scripts which will deliberately or
@@ -90,23 +90,23 @@ accidentally expose your system to an attack.
  <LI>You consider security at your site to be so feeble in other areas, as to
 make one more potential hole irrelevant.
  <LI>You have no users, and nobody ever visits your server.
-</OL><p>
+</OL><P>
 <HR>
 
 <H2>Script Alias'ed CGI</H2>
-<P>Limiting <B>CGI</B> to special directories gives the admin control over
+<P>Limiting <STRONG>CGI</STRONG> to special directories gives the admin control over
 what goes into those directories. This is inevitably more secure than
-non script aliased CGI, but <strong>only if users with write access to the
-directories are trusted</strong> or the admin is willing to test each new CGI
+non script aliased CGI, but <STRONG>only if users with write access to the
+directories are trusted</STRONG> or the admin is willing to test each new CGI
 script/program for potential security holes.<P>
 
-Most sites choose this option over the non script aliased CGI approach.<p>
+Most sites choose this option over the non script aliased CGI approach.<P>
 
 <HR>
 <H2>CGI in general</H2>
 <P>Always remember that you must trust the writers of the CGI script/programs
 or your ability to spot potential security holes in CGI, whether they were
-deliberate or accidental.<p>
+deliberate or accidental.<P>
 
 All the CGI scripts will run as the same user, so they have potential to
 conflict (accidentally or deliberately) with other scripts e.g.
@@ -123,21 +123,21 @@ the Apache server code.  Another popular way of doing this is with
 <H2>Stopping users overriding system wide settings...</H2>
 <P>To run a really tight ship, you'll want to stop users from setting
 up <CODE>.htaccess</CODE> files which can override security features
-you've configured. Here's one way to do it...<p>
+you've configured. Here's one way to do it...<P>
 
 In the server configuration file, put
-<blockquote><code>
-&lt;Directory /&gt; <br>
-AllowOverride None <br>
-Options None <br>
-allow from all <br>
-&lt;/Directory&gt; <br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+&lt;Directory /&gt; <BR>
+AllowOverride None <BR>
+Options None <BR>
+allow from all <BR>
+&lt;/Directory&gt; <BR>
+</CODE></BLOCKQUOTE>
 
 Then setup for specific directories<P>
 
 This stops all overrides, Includes and accesses in all directories apart
-from those named.<p>
+from those named.<P>
 <HR>
 <H2>
  Protect server files by default
@@ -220,7 +220,7 @@ by filling out a
 <A HREF="http://www.apache.org/bugdb.cgi">problem report</A>, or by
 sending mail to
 <A HREF="mailto:apache-bugs@mail.apache.org">apache-bugs@mail.apache.org</A>
-<p>
+<P>
 <HR>
 
 <!--#include virtual="footer.html" -->
index e2b7232ad56bfacbcfaac6069df6e2429f96caf6..1c4d650726d1cc6cf417f84c1c654a754c7e3250 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Apache Core Features</h1>
+<H1 ALIGN="CENTER">Apache Core Features</H1>
 <P>
 These configuration parameters control the core Apache features, and are
 always available.
 </P>
 <H2>Directives</H2>
-<ul>
-<li><A HREF="#accessconfig">AccessConfig</A>
-<li><A HREF="#accessfilename">AccessFileName</A>
-<li><A HREF="#addmodule">AddModule</A>
-<li><A HREF="#allowoverride">AllowOverride</A>
-<li><A HREF="#authname">AuthName</A>
-<li><A HREF="#authtype">AuthType</A>
-<li><A HREF="#bindaddress">BindAddress</A>
-<li><A HREF="#clearmodulelist">ClearModuleList</A>
-<li><A HREF="#contentdigest">ContentDigest</A>
-<li><A HREF="#coredumpdirectory">CoreDumpDirectory</A>
-<li><A HREF="#defaulttype">DefaultType</A>
-<li><A HREF="#directory">&lt;Directory&gt;</A>
-<li><A HREF="#directorymatch">&lt;DirectoryMatch&gt;</A>
-<li><A HREF="#documentroot">DocumentRoot</A>
-<li><A HREF="#errordocument">ErrorDocument</A>
-<li><A HREF="#errorlog">ErrorLog</A>
-<li><A HREF="#files">&lt;Files&gt;</A>
-<li><A HREF="#filesmatch">&lt;FilesMatch&gt;</A>
-<li><A HREF="#group">Group</A>
-<li><A HREF="#hostnamelookups">HostNameLookups</A>
-<li><A HREF="#identitycheck">IdentityCheck</A>
-<li><A HREF="#ifmodule">&lt;IfModule&gt;</A>
-<li><A HREF="#include">Include</A>
-<li><A HREF="#keepalive">KeepAlive</A>
-<li><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
-<li><A HREF="#limit">&lt;Limit&gt;</A>
-<li><A HREF="#listen">Listen</A>
-<li><A HREF="#listenbacklog">ListenBacklog</A>
-<li><A HREF="#location">&lt;Location&gt;</A>
-<li><A HREF="#locationmatch">&lt;LocationMatch&gt;</A>
-<li><A HREF="#lockfile">LockFile</A>
-<li><A HREF="#maxclients">MaxClients</A>
-<li><A HREF="#maxkeepaliverequests">MaxKeepAliveRequests</a>
-<li><A HREF="#maxrequestsperchild">MaxRequestsPerChild</A>
-<li><A HREF="#maxspareservers">MaxSpareServers</A>
-<li><A HREF="#minspareservers">MinSpareServers</A>
-<li><A HREF="#namevirtualhost">NameVirtualHost</A>
-<li><A HREF="#options">Options</A>
-<li><A HREF="#pidfile">PidFile</A>
-<li><A HREF="#port">Port</A>
-<li><A HREF="#require">require</A>
-<li><A HREF="#resourceconfig">ResourceConfig</A>
-<li><A HREF="#rlimitcpu">RLimitCPU</A>
-<li><A HREF="#rlimitmem">RLimitMEM</A>
-<li><A HREF="#rlimitnproc">RLimitNPROC</A>
-<li><A HREF="#satisfy">Satisfy</A>
-<li><A HREF="#scoreboardfile">ScoreBoardFile</A>
-<li><A HREF="#sendbuffersize">SendBufferSize</A>
-<li><A HREF="#serveradmin">ServerAdmin</A>
-<li><A HREF="#serveralias">ServerAlias</A>
-<li><A HREF="#servername">ServerName</A>
-<li><A HREF="#serverpath">ServerPath</A>
-<li><A HREF="#serverroot">ServerRoot</A>
-<li><A HREF="#servertype">ServerType</A>
-<li><A HREF="#startservers">StartServers</A>
-<li><A HREF="#threadsperchild">ThreadsPerChild</a>
-<li><A HREF="#timeout">TimeOut</A>
-<li><A HREF="#user">User</A>
-<li><A HREF="#virtualhost">&lt;VirtualHost&gt;</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#accessconfig">AccessConfig</A>
+<LI><A HREF="#accessfilename">AccessFileName</A>
+<LI><A HREF="#addmodule">AddModule</A>
+<LI><A HREF="#allowoverride">AllowOverride</A>
+<LI><A HREF="#authname">AuthName</A>
+<LI><A HREF="#authtype">AuthType</A>
+<LI><A HREF="#bindaddress">BindAddress</A>
+<LI><A HREF="#clearmodulelist">ClearModuleList</A>
+<LI><A HREF="#contentdigest">ContentDigest</A>
+<LI><A HREF="#coredumpdirectory">CoreDumpDirectory</A>
+<LI><A HREF="#defaulttype">DefaultType</A>
+<LI><A HREF="#directory">&lt;Directory&gt;</A>
+<LI><A HREF="#directorymatch">&lt;DirectoryMatch&gt;</A>
+<LI><A HREF="#documentroot">DocumentRoot</A>
+<LI><A HREF="#errordocument">ErrorDocument</A>
+<LI><A HREF="#errorlog">ErrorLog</A>
+<LI><A HREF="#files">&lt;Files&gt;</A>
+<LI><A HREF="#filesmatch">&lt;FilesMatch&gt;</A>
+<LI><A HREF="#group">Group</A>
+<LI><A HREF="#hostnamelookups">HostNameLookups</A>
+<LI><A HREF="#identitycheck">IdentityCheck</A>
+<LI><A HREF="#ifmodule">&lt;IfModule&gt;</A>
+<LI><A HREF="#include">Include</A>
+<LI><A HREF="#keepalive">KeepAlive</A>
+<LI><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
+<LI><A HREF="#limit">&lt;Limit&gt;</A>
+<LI><A HREF="#listen">Listen</A>
+<LI><A HREF="#listenbacklog">ListenBacklog</A>
+<LI><A HREF="#location">&lt;Location&gt;</A>
+<LI><A HREF="#locationmatch">&lt;LocationMatch&gt;</A>
+<LI><A HREF="#lockfile">LockFile</A>
+<LI><A HREF="#maxclients">MaxClients</A>
+<LI><A HREF="#maxkeepaliverequests">MaxKeepAliveRequests</A>
+<LI><A HREF="#maxrequestsperchild">MaxRequestsPerChild</A>
+<LI><A HREF="#maxspareservers">MaxSpareServers</A>
+<LI><A HREF="#minspareservers">MinSpareServers</A>
+<LI><A HREF="#namevirtualhost">NameVirtualHost</A>
+<LI><A HREF="#options">Options</A>
+<LI><A HREF="#pidfile">PidFile</A>
+<LI><A HREF="#port">Port</A>
+<LI><A HREF="#require">require</A>
+<LI><A HREF="#resourceconfig">ResourceConfig</A>
+<LI><A HREF="#rlimitcpu">RLimitCPU</A>
+<LI><A HREF="#rlimitmem">RLimitMEM</A>
+<LI><A HREF="#rlimitnproc">RLimitNPROC</A>
+<LI><A HREF="#satisfy">Satisfy</A>
+<LI><A HREF="#scoreboardfile">ScoreBoardFile</A>
+<LI><A HREF="#sendbuffersize">SendBufferSize</A>
+<LI><A HREF="#serveradmin">ServerAdmin</A>
+<LI><A HREF="#serveralias">ServerAlias</A>
+<LI><A HREF="#servername">ServerName</A>
+<LI><A HREF="#serverpath">ServerPath</A>
+<LI><A HREF="#serverroot">ServerRoot</A>
+<LI><A HREF="#servertype">ServerType</A>
+<LI><A HREF="#startservers">StartServers</A>
+<LI><A HREF="#threadsperchild">ThreadsPerChild</A>
+<LI><A HREF="#timeout">TimeOut</A>
+<LI><A HREF="#user">User</A>
+<LI><A HREF="#virtualhost">&lt;VirtualHost&gt;</A>
+</UL>
+<HR>
 
 <h2><A name="accessconfig">AccessConfig directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AccessConfig} directive&gt; -->
-<strong>Syntax:</strong> AccessConfig <em>filename</em><br>
-<strong>Default:</strong> <code>AccessConfig conf/access.conf</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> AccessConfig <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>AccessConfig conf/access.conf</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The server will read this file for more directives after reading the
-<A HREF="#resourceconfig">ResourceConfig</A> file. <em>Filename</em> is
+<A HREF="#resourceconfig">ResourceConfig</A> file. <EM>Filename</EM> is
 relative to the <A HREF="#serverroot">ServerRoot</A>.
 This feature can be disabled using:
-<blockquote><code>AccessConfig /dev/null</code></blockquote>
+<BLOCKQUOTE><CODE>AccessConfig /dev/null</CODE></BLOCKQUOTE>
 Historically, this file only contained
 <A HREF="#directory">&lt;Directory&gt;</A> sections; in fact it can now
-contain any server directive allowed in the <em>server config</em> context.
-<p><hr>
+contain any server directive allowed in the <EM>server config</EM> context.
+<P><HR>
 
 <h2><A name="accessfilename">AccessFileName directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AccessFileName} directive&gt; -->
-<strong>Syntax:</strong> AccessFileName <em>filename filename ...</em><br>
-<strong>Default:</strong> <code>AccessFileName .htaccess</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> AccessFileName can accept more than one filename only in Apache 1.3 and later<p>
+<STRONG>Syntax:</STRONG> AccessFileName <EM>filename filename ...</EM><BR>
+<STRONG>Default:</STRONG> <CODE>AccessFileName .htaccess</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> AccessFileName can accept more than one filename only in Apache 1.3 and later<P>
 
 When returning a document to the client the server looks for the first existing
 access control file from this list of names in every directory of the path to
 the document, if access control files are enabled for that directory.
 
 For example:
-<blockquote><code>AccessFileName .acl</code></blockquote>
+<BLOCKQUOTE><CODE>AccessFileName .acl</CODE></BLOCKQUOTE>
 before returning the document /usr/local/web/index.html, the
 server will read /.acl, /usr/.acl, /usr/local/.acl and /usr/local/web/.acl
 for directives, unless they have been disabled with
-<blockquote><code>
-&lt;Directory /&gt;<br>
-AllowOverride None<br>
-&lt;/Directory&gt;</code></blockquote><p><hr>
+<BLOCKQUOTE><CODE>
+&lt;Directory /&gt;<BR>
+AllowOverride None<BR>
+&lt;/Directory&gt;</CODE></BLOCKQUOTE><P><HR>
 
 <h2><A name="addmodule">AddModule directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AddModule} directive&gt; -->
-<strong>Syntax:</strong> AddModule <em>module module ...</em><br>
-<strong>Context:</strong> server config <br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> AddModule is only available in Apache 1.2 and later<p>
+<STRONG>Syntax:</STRONG> AddModule <EM>module module ...</EM><BR>
+<STRONG>Context:</STRONG> server config <BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> AddModule is only available in Apache 1.2 and later<P>
 
 The server can have modules compiled in which are not actively in use.
 This directive can be used to enable the use of those modules.  The
 server comes with a pre-loaded list of active modules; this list can
 be cleared with the <A HREF="#clearmodulelist">ClearModuleList</A>
-directive.<p><hr>
+directive.<P><HR>
 
 <h2><A name="allowoverride">AllowOverride directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AllowOverride} directive&gt; -->
-<strong>Syntax:</strong> AllowOverride <em>override override ...</em><br>
-<strong>Default:</strong> <code>AllowOverride All</code><br>
-<strong>Context:</strong> directory<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> AllowOverride <EM>override override ...</EM><BR>
+<STRONG>Default:</STRONG> <CODE>AllowOverride All</CODE><BR>
+<STRONG>Context:</STRONG> directory<BR>
+<STRONG>Status:</STRONG> core<P>
 
 When the server finds an .htaccess file (as specified by
 <A HREF="#accessfilename">AccessFileName</A>) it needs to know which
-directives declared in that file can override earlier access information.<p>
+directives declared in that file can override earlier access information.<P>
 
-<em>Override</em> can be set to <code>None</code>, in which case the server
-will not read the file, <code>All</code> in which case the server will
+<EM>Override</EM> can be set to <CODE>None</CODE>, in which case the server
+will not read the file, <CODE>All</CODE> in which case the server will
 allow all the directives, or one or more of the following:
-<dl>
-<dt>AuthConfig
-<dd>
+<DL>
+<DT>AuthConfig
+<DD>
 <!--%plaintext &lt;?INDEX {\tt AuthConfig} override&gt; -->
 Allow use of the authorization directives
 (<A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>,
@@ -160,8 +160,8 @@ Allow use of the authorization directives
 <A HREF="#authname">AuthName</A>, <A HREF="#authtype">AuthType</A>,
 <A HREF="mod_auth.html#authuserfile">AuthUserFile</A>,
 <A HREF="#require">require</A>, etc.).
-<dt>FileInfo
-<dd>
+<DT>FileInfo
+<DD>
 <!--%plaintext &lt;?INDEX {\tt FileInfo} override&gt; -->
 Allow use of the directives controlling document types
 (<A HREF="mod_mime.html#addencoding">AddEncoding</A>,
@@ -170,8 +170,8 @@ Allow use of the directives controlling document types
 <A HREF="#defaulttype">DefaultType</A>,
 <A HREF="#errordocument">ErrorDocument</A>,
 <A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>, etc.).
-<dt>Indexes
-<dd>
+<DT>Indexes
+<DD>
 <!--%plaintext &lt;?INDEX {\tt Indexes} override&gt; -->
 Allow use of the directives controlling directory indexing
 (<A HREF="mod_autoindex.html#adddescription">AddDescription</A>,
@@ -185,24 +185,24 @@ Allow use of the directives controlling directory indexing
 <A HREF="mod_autoindex.html#indexignore">IndexIgnore</A>,
 <A HREF="mod_autoindex.html#indexoptions">IndexOptions</A>,
 <A HREF="mod_autoindex.html#readmename">ReadmeName</A>, etc.).
-<dt>Limit
-<dd>
+<DT>Limit
+<DD>
 <!--%plaintext &lt;?INDEX {\tt Limit} override&gt; -->
 Allow use of the directives controlling host access (allow, deny and order).
-<dt>Options
-<dd>
+<DT>Options
+<DD>
 <!--%plaintext &lt;?INDEX {\tt Options} override&gt; -->
 Allow use of the directives controlling specific directory features
 (<A HREF="#options">Options</A> and
 <A HREF="mod_include.html#xbithack">XBitHack</A>).
-</dl><p><hr>
+</DL><P><HR>
 
 <h2><A name="authname">AuthName directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AuthName} directive&gt; -->
-<strong>Syntax:</strong> AuthName <em>auth-domain</em><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> AuthName <EM>auth-domain</EM><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> core<P>
 
 This directive sets the name of the authorization realm for a directory.
 This realm is given to the client so that the user knows which username and
@@ -210,81 +210,81 @@ password to send.
 It must be accompanied by <A HREF="#authtype">AuthType</A> and
 <A HREF="#require">require</A> directives, and directives such as
 <A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
-<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<p><hr>
+<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<P><HR>
 
 <h2><A name="authtype">AuthType directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AuthType} directive&gt; -->
-<strong>Syntax:</strong> AuthType <em>type</em><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> AuthType <EM>type</EM><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> core<P>
 
 This directive selects the type of user authentication for a directory.
-Only <code>Basic</code> is currently implemented.
+Only <CODE>Basic</CODE> is currently implemented.
 <!--%plaintext &lt;?INDEX {\tt Basic} authentication scheme&gt; -->
 It must be accompanied by <A HREF="#authname">AuthName</A> and
 <A HREF="#require">require</A> directives, and directives such as
 <A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
-<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<p><hr>
+<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<P><HR>
 
 <h2><A name="bindaddress">BindAddress directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt BindAddress} directive&gt; -->
-<strong>Syntax:</strong> BindAddress <em>saddr</em><br>
-<strong>Default:</strong> <code>BindAddress *</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> BindAddress <EM>saddr</EM><BR>
+<STRONG>Default:</STRONG> <CODE>BindAddress *</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 A Unix&#174; http server can either listen for connections to every
 IP address of the server machine, or just one IP address of the server
-machine. <em>Saddr</em> can be
+machine. <EM>Saddr</EM> can be
 
-<menu>
-<li>*
-<li>An IP address
-<li>A fully-qualified Internet domain name
-</menu>
+<MENU>
+<LI>*
+<LI>An IP address
+<LI>A fully-qualified Internet domain name
+</MENU>
 If the value is *, then the server will listen for connections on
 every IP address, otherwise it will only listen on the IP address
-specified. <p>
+specified. <P>
 
-Only one <code>BindAddress</code> directive can be used. For more
+Only one <CODE>BindAddress</CODE> directive can be used. For more
 control over which address and ports Apache listens to, use the
-<code><a href="#listen">Listen</a></code> directive instead of
-<code>BindAddress</code>.<p>
+<CODE><A HREF="#listen">Listen</A></CODE> directive instead of
+<CODE>BindAddress</CODE>.<P>
 
-<code>BindAddress</code> can be used as an alternative method for
+<CODE>BindAddress</CODE> can be used as an alternative method for
 supporting <A HREF="../vhosts/index.html">virtual hosts</A> using
-multiple independent servers, instead of using <code><A
-HREF="#virtualhost">&lt;VirtualHost&gt;</A></code> sections.
+multiple independent servers, instead of using <CODE><A
+HREF="#virtualhost">&lt;VirtualHost&gt;</A></CODE> sections.
 
-<p><strong>See Also:</strong>
-<a href="../dns-caveats.html">DNS Issues</a><br>
-<strong>See Also:</strong>
-<a href="../bind.html">Setting which addresses and ports Apache uses</a></p>
+<P><STRONG>See Also:</STRONG>
+<A HREF="../dns-caveats.html">DNS Issues</A><BR>
+<STRONG>See Also:</STRONG>
+<A HREF="../bind.html">Setting which addresses and ports Apache uses</A></P>
 
-<hr>
+<HR>
 
 <h2><A name="clearmodulelist">ClearModuleList directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ClearModuleList} directive&gt; -->
-<strong>Syntax:</strong> ClearModuleList<br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> ClearModuleList is only available in Apache 1.2 and later<p>
+<STRONG>Syntax:</STRONG> ClearModuleList<BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> ClearModuleList is only available in Apache 1.2 and later<P>
 
 The server comes with a built-in list of active modules.  This
 directive clears the list.  It is assumed that the list will then be
-re-populated using the <A HREF="#addmodule">AddModule</A> directive.<p><hr>
+re-populated using the <A HREF="#addmodule">AddModule</A> directive.<P><HR>
 
 <h2><A name="contentdigest">ContentDigest directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ContentDigest} directive&gt; -->
-<strong>Syntax:</strong> ContentDigest <em>on|off</em><br>
-<strong>Default:</strong> <code>ContentDigest off</code><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> experimental<p>
-<strong>Compatibility:</strong> ContentDigest is only available in Apache 1.1 and later<p>
-
-This directive enables the generation of <code>Content-MD5</code> headers
+<STRONG>Syntax:</STRONG> ContentDigest <EM>on|off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ContentDigest off</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> experimental<P>
+<STRONG>Compatibility:</STRONG> ContentDigest is only available in Apache 1.1 and later<P>
+
+This directive enables the generation of <CODE>Content-MD5</CODE> headers
 as defined in RFC1864 respectively RFC2068.<P>
 
 MD5 is an algorithm for computing a "message digest" (sometimes called
@@ -292,108 +292,108 @@ MD5 is an algorithm for computing a "message digest" (sometimes called
 that any alterations in the data will be reflected in alterations in the
 message digest.<P>
 
-The <code>Content-MD5</code> header provides an end-to-end message
+The <CODE>Content-MD5</CODE> header provides an end-to-end message
 integrity check (MIC) of the entity-body. A proxy or client may check this
 header for detecting accidental modification of the entity-body
 in transit.
 Example header:
-<pre>   Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==</pre><P>
+<PRE>   Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==</PRE><P>
 
 Note that this can cause performance problems on your server
 since the message digest is computed on every request
 (the values are not cached).<P>
 
-<code>Content-MD5</code> is only sent for documents served by the
+<CODE>Content-MD5</CODE> is only sent for documents served by the
 core, and not by any module.  For example, SSI documents, output from
 CGI scripts, and byte range responses do not have this header.
 
-<hr>
+<HR>
 
 <h2><A name="coredumpdirectory">CoreDumpDirectory directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt CoreDumpDirectory} directive&gt; -->
-<strong>Syntax:</strong> CoreDumpDirectory <em>directory</em><br>
-<strong>Default:</strong> the same location as ServerRoot<br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> CoreDumpDirectory <EM>directory</EM><BR>
+<STRONG>Default:</STRONG> the same location as ServerRoot<BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 This controls the directory to which Apache attempts to switch before
 dumping core.  The default is in the <A HREF="#serverroot">ServerRoot</A>
 directory, however since this should not be writable by the user
 the server runs as, core dumps won't normally get written.  If you
 want a core dump for debugging, you can use this directive to place
-it in a different location.<p><hr>
+it in a different location.<P><HR>
 
 <h2><A name="defaulttype">DefaultType directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt DefaultType} directive&gt; -->
-<strong>Syntax:</strong> DefaultType <em>mime-type</em><br>
-<strong>Default:</strong> <code>DefaultType text/html</code><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> DefaultType <EM>mime-type</EM><BR>
+<STRONG>Default:</STRONG> <CODE>DefaultType text/html</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> core<P>
 
 There will be times when the server is asked to provide a document
-whose type cannot be determined by its MIME types mappings.<p>
+whose type cannot be determined by its MIME types mappings.<P>
 
 The server must inform the client of the content-type of the document, so in
 the event of an unknown type it uses the <CODE>DefaultType</CODE>. For
 example:
-<blockquote><code>DefaultType image/gif</code></blockquote>
+<BLOCKQUOTE><CODE>DefaultType image/gif</CODE></BLOCKQUOTE>
 would be appropriate for a directory which contained many gif images
-with filenames missing the .gif extension.<p><hr>
+with filenames missing the .gif extension.<P><HR>
 
 <h2><A name="directory">&lt;Directory&gt; directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Directory} section directive&gt; -->
-<strong>Syntax:</strong> &lt;Directory <em>directory</em>&gt; ... &lt;/Directory&gt; <br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Core. <p>
+<STRONG>Syntax:</STRONG> &lt;Directory <EM>directory</EM>&gt; ... &lt;/Directory&gt; <BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Core. <P>
 
 &lt;Directory&gt; and &lt;/Directory&gt; are used to enclose a group of
 directives which will apply only to the named directory and sub-directories
 of that directory. Any directive which is allowed in a directory
-context may be used. <em>Directory</em> is either the full path to a directory,
+context may be used. <EM>Directory</EM> is either the full path to a directory,
 or a wild-card string. In a wild-card string, `?' matches any single character,
 and `*' matches any sequences of characters.  As of Apache 1.3, you
 may also use `[]' character ranges like in the shell.  Also as of Apache 1.3
 none of the wildcards match a `/' character, which more closely mimics the
 behaviour of Unix shells.
 Example:
-<pre>
+<PRE>
    &lt;Directory /usr/local/httpd/htdocs&gt;
    Options Indexes FollowSymLinks
    &lt;/Directory&gt;
-</pre>
+</PRE>
 
-<p><strong>Apache 1.2 and above:</strong>
+<P><STRONG>Apache 1.2 and above:</STRONG>
 Extended regular expressions can also be used, with the addition of the
-<code>~</code> character. For example:</p>
+<CODE>~</CODE> character. For example:</P>
 
-<pre>
+<PRE>
    &lt;Directory ~ &quot;^/www/.*/[0-9]{3}&quot;&gt;
-</pre>
+</PRE>
 
 would match directories in /www/ that consisted of three numbers.
 
-<p>If multiple (non-regular expression) directory sections match the
+<P>If multiple (non-regular expression) directory sections match the
 directory (or its parents) containing
 a document, then the directives are applied in the order of shortest match
 first, interspersed with the directives from the
 <A HREF="#accessfilename">.htaccess</A> files. For example, with
-<blockquote><code>
-&lt;Directory /&gt;<br>
-AllowOverride None<br>
-&lt;/Directory&gt;<br><br>
-&lt;Directory /home/*&gt;<br>
-AllowOverride FileInfo<br>
-&lt;/Directory&gt;</code></blockquote>
-for access to the document <code>/home/web/dir/doc.html</code> the
+<BLOCKQUOTE><CODE>
+&lt;Directory /&gt;<BR>
+AllowOverride None<BR>
+&lt;/Directory&gt;<BR><BR>
+&lt;Directory /home/*&gt;<BR>
+AllowOverride FileInfo<BR>
+&lt;/Directory&gt;</CODE></BLOCKQUOTE>
+for access to the document <CODE>/home/web/dir/doc.html</CODE> the
 steps are:
-<menu>
-<li>Apply directive <code>AllowOverride None</code> (disabling
-<code>.htaccess</code> files).
-<li>Apply directive <code>AllowOverride FileInfo</code> (for directory
-<code>/home/web</code>).
-<li>Apply any FileInfo directives in <code>/home/web/.htaccess</code>
-</menu>
+<MENU>
+<LI>Apply directive <CODE>AllowOverride None</CODE> (disabling
+<CODE>.htaccess</CODE> files).
+<LI>Apply directive <CODE>AllowOverride FileInfo</CODE> (for directory
+<CODE>/home/web</CODE>).
+<LI>Apply any FileInfo directives in <CODE>/home/web/.htaccess</CODE>
+</MENU>
 
 <P>
 Regular expression directory sections are handled slightly differently
@@ -404,22 +404,22 @@ possible occurs.  In Apache 1.3 regular expressions are not considered
 until after all of the normal sections have been applied.  Then all of
 the regular expressions are tested in the order they appeared in the
 configuration file.  For example, with
-<blockquote><code>
-&lt;Directory ~ abc$&gt;<br>
-... directives here ...<br>
-&lt;/Directory&gt;<br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+&lt;Directory ~ abc$&gt;<BR>
+... directives here ...<BR>
+&lt;/Directory&gt;<BR>
+</CODE></BLOCKQUOTE>
 Suppose that the filename being accessed is
-<code>/home/abc/public_html/abc/index.html</code>.  The server
-considers each of <code>/</code>, <code>/home</code>, <code>/home/abc</code>,
-<code>/home/abc/public_html</code>, and <code>/home/abc/public_html/abc</code>
+<CODE>/home/abc/public_html/abc/index.html</CODE>.  The server
+considers each of <CODE>/</CODE>, <CODE>/home</CODE>, <CODE>/home/abc</CODE>,
+<CODE>/home/abc/public_html</CODE>, and <CODE>/home/abc/public_html/abc</CODE>
 in that order.   In Apache 1.2, when
-<code>/home/abc</code> is considered, the regular expression will match
+<CODE>/home/abc</CODE> is considered, the regular expression will match
 and be applied.  In Apache 1.3 the regular expression isn't considered
 at all at that point in the tree.  It won't be considered until after
-all normal &lt;Directory&gt;s and <code>.htaccess</code> files have
+all normal &lt;Directory&gt;s and <CODE>.htaccess</CODE> files have
 been applied.  Then the regular expression will
-match on <code>/home/abc/public_html/abc</code> and be applied.
+match on <CODE>/home/abc/public_html/abc</CODE> and be applied.
 
 <P>
 
@@ -449,72 +449,72 @@ page for more details.
 The directory sections typically occur in the access.conf file, but they
 may appear in any configuration file. &lt;Directory&gt; directives cannot
 nest, and cannot appear in a <A HREF="#limit">&lt;Limit&gt;</A> section.
-<p>
+<P>
 
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
 
-<hr>
+<HR>
 
 <h2><A name="directorymatch">&lt;DirectoryMatch&gt;</A></h2>
-<strong>Syntax:</strong> &lt;DirectoryMatch <em>regex</em>&gt; ... &lt;/DirectoryMatch&gt; <br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Core.<br>
-<strong>Compatibility:</strong> Available in Apache 1.3 and later
+<STRONG>Syntax:</STRONG> &lt;DirectoryMatch <EM>regex</EM>&gt; ... &lt;/DirectoryMatch&gt; <BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Core.<BR>
+<STRONG>Compatibility:</STRONG> Available in Apache 1.3 and later
 
-<p>&lt;DirectoryMatch&gt; and &lt;/DirectoryMatch&gt; are used to enclose a group of
+<P>&lt;DirectoryMatch&gt; and &lt;/DirectoryMatch&gt; are used to enclose a group of
 directives which will apply only to the named directory and sub-directories
-of that directory, the same as <a
-href="#directory">&lt;Directory&gt;</a>. However, it takes as an
-argument a regular expression. For example:</p>
+of that directory, the same as <A
+HREF="#directory">&lt;Directory&gt;</A>. However, it takes as an
+argument a regular expression. For example:</P>
 
-<pre>
+<PRE>
    &lt;DirectoryMatch &quot;^/www/.*/[0-9]{3}&quot;&gt;
-</pre>
+</PRE>
 
-<p>would match directories in /www/ that consisted of three numbers.</p>
+<P>would match directories in /www/ that consisted of three numbers.</P>
 
-<p><strong>See Also:</strong>
-<a href="#directory">&lt;Directory&gt;</a> for a description of how
+<P><STRONG>See Also:</STRONG>
+<A HREF="#directory">&lt;Directory&gt;</A> for a description of how
 regular expressions are mixed in with normal &lt;Directory&gt;s.
-<br>
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+<BR>
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
 
-<hr>
+<HR>
 
 <h2><A NAME="documentroot">DocumentRoot directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt DocumentRoot} directive&gt; -->
-<strong>Syntax:</strong> DocumentRoot <em>directory-filename</em><br>
-<strong>Default:</strong> <code>DocumentRoot
-/usr/local/apache/htdocs</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> DocumentRoot <EM>directory-filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>DocumentRoot
+/usr/local/apache/htdocs</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 This directive sets the directory from which httpd will serve files.
 Unless matched by a directive like Alias, the server appends the path
 from the requested URL to the document root to make the path to the
 document. Example:
-<blockquote><code>DocumentRoot /usr/web</code></blockquote>
-then an access to <code>http://www.my.host.com/index.html</code> refers
-to <code>/usr/web/index.html</code>.
+<BLOCKQUOTE><CODE>DocumentRoot /usr/web</CODE></BLOCKQUOTE>
+then an access to <CODE>http://www.my.host.com/index.html</CODE> refers
+to <CODE>/usr/web/index.html</CODE>.
 
 <P>There appears to be a bug in mod_dir which causes problems when the
 DocumentRoot has a trailing slash (i.e. "DocumentRoot /usr/web/") so
 please avoid that.
 
-<p><hr>
+<P><HR>
 
 <h2><A name="errordocument">ErrorDocument directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ErrorDocument} directive&gt; -->
-<strong>Syntax:</strong> ErrorDocument <em>error-code document</em><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> core<br>
-<strong>Override:</strong> FileInfo<br>
-<strong>Compatibility:</strong> The directory and .htaccess contexts
-are only available in Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ErrorDocument <EM>error-code document</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Override:</STRONG> FileInfo<BR>
+<STRONG>Compatibility:</STRONG> The directory and .htaccess contexts
+are only available in Apache 1.1 and later.<P>
 
 In the event of a problem or error, Apache can be configured to do
 one of four things,
@@ -530,19 +530,19 @@ one of four things,
 using the <CODE>ErrorDocument</CODE> directive, which is followed by
 the HTTP response code and a message or URL.
 
-<P><em>Messages</em> in this context begin with a single quote
-(<code>"</code>), which does not form part of the message itself.
+<P><EM>Messages</EM> in this context begin with a single quote
+(<CODE>"</CODE>), which does not form part of the message itself.
 Apache will sometimes offer additional information regarding the
 problem/error.
 
 <P>URLs can begin with a slash (/) for local URLs, or be a full
 URL which the client can resolve. Examples:
-<blockquote><code>
-ErrorDocument 500 http://foo.example.com/cgi-bin/tester<br>
-ErrorDocument 404 /cgi-bin/bad_urls.pl<br>
-ErrorDocument 401 /subscription_info.html<br>
+<BLOCKQUOTE><CODE>
+ErrorDocument 500 http://foo.example.com/cgi-bin/tester<BR>
+ErrorDocument 404 /cgi-bin/bad_urls.pl<BR>
+ErrorDocument 401 /subscription_info.html<BR>
 ErrorDocument 403 "Sorry can't allow you access today
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
 <P>Note that when you specify an <CODE>ErrorDocument</CODE> that
 points to a remote URL (ie. anything with a method such as "http" in
@@ -554,654 +554,654 @@ directive then it must refer to a local document.</STRONG>  This results
 from the nature of the HTTP basic authentication scheme.
 
 <P>See Also: <A HREF="../custom-error.html">documentation of customizable
-responses.</A><p><hr>
+responses.</A><P><HR>
 
 <h2><A name="errorlog">ErrorLog directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ErrorLog} directive&gt; -->
-<strong>Syntax:</strong> ErrorLog <em>filename</em><br>
-<strong>Default:</strong> <code>ErrorLog logs/error_log</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ErrorLog <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ErrorLog logs/error_log</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The error log directive sets the name of the file to which the server will log
 any errors it encounters. If the filename does not begin with a slash (/)
 then it is assumed to be relative to the <A HREF="#serverroot">ServerRoot</A>.
 Example:
-<blockquote><code>ErrorLog /dev/null</code></blockquote>
-This effectively turns off error logging.<p>
+<BLOCKQUOTE><CODE>ErrorLog /dev/null</CODE></BLOCKQUOTE>
+This effectively turns off error logging.<P>
 
 SECURITY: See the <A HREF="../misc/security_tips.html#serverroot">security tips</A>
 document for details on why your security could be compromised if
 the directory where logfiles are stored is writable by anyone other
 than the user that starts the server.
 
-<p><hr>
+<P><HR>
 
 <h2><A name="files">&lt;Files&gt; directive</A></h2>
-<strong>Syntax:</strong> &lt;Files <em>filename</em>&gt;
-... &lt;/Files&gt;<br>
-<strong>Context:</strong> server config, virtual host, .htaccess<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> only available in Apache
-1.2 and above.<p>
-
-<p>The &lt;Files&gt; directive provides for access control by
-filename. It is comparable to the <a
-href="#directory">&lt;Directory&gt;</a> directive and
-<a href="#location">&lt;Location&gt;</a> directives. It
+<STRONG>Syntax:</STRONG> &lt;Files <EM>filename</EM>&gt;
+... &lt;/Files&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host, .htaccess<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> only available in Apache
+1.2 and above.<P>
+
+<P>The &lt;Files&gt; directive provides for access control by
+filename. It is comparable to the <A
+HREF="#directory">&lt;Directory&gt;</A> directive and
+<A HREF="#location">&lt;Location&gt;</A> directives. It
 should be matched with a &lt;/Files&gt; directive. Directives that
 apply to the filename given should be listed
-within. <code>&lt;Files&gt;</code> sections are processed in the
+within. <CODE>&lt;Files&gt;</CODE> sections are processed in the
 order they appear in the configuration file, after the
-&lt;Directory&gt; sections and <code>.htaccess</code> files are
-read, but before &lt;Location&gt; sections.</p>
+&lt;Directory&gt; sections and <CODE>.htaccess</CODE> files are
+read, but before &lt;Location&gt; sections.</P>
 
-<p>The <em>filename</em> argument should include a filename, or a
+<P>The <EM>filename</EM> argument should include a filename, or a
 wild-card string, where `?' matches any single character, and `*' matches any
 sequences of characters. Extended regular expressions can also be used,
 with the addition of
-the <code>~</code> character. For example:</p>
+the <CODE>~</CODE> character. For example:</P>
 
-<pre>
+<PRE>
    &lt;Files ~ &quot;\.(gif|jpe?g|png)$&quot;&gt;
-</pre>
+</PRE>
 
 would match most common Internet graphics formats. In Apache 1.3 and
-later, <a href="#filesmatch">&lt;FilesMatch&gt;</a> is preferred,
+later, <A HREF="#filesmatch">&lt;FilesMatch&gt;</A> is preferred,
 however.
 
-<p>Note that unlike <a
-href="#directory"><code>&lt;Directory&gt;</code></a> and <a
-href="#location"><code>&lt;Location&gt;</code></a> sections,
-<code>&lt;Files&gt;</code> sections can be used inside .htaccess
+<P>Note that unlike <A
+HREF="#directory"><CODE>&lt;Directory&gt;</CODE></A> and <A
+HREF="#location"><CODE>&lt;Location&gt;</CODE></A> sections,
+<CODE>&lt;Files&gt;</CODE> sections can be used inside .htaccess
 files. This allows users to control access to their own files, at a
 file-by-file level. When used in an .htaccess file, if the
-<em>filename</em> does not begin with a <code>/</code> character,
+<EM>filename</EM> does not begin with a <CODE>/</CODE> character,
 the directory being applied will be prefixed automatically.
 
-<p>
+<P>
 
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
 
-<hr>
+<HR>
 
 <h2><A name="filesmatch">&lt;FilesMatch&gt;</A></h2>
-<strong>Syntax:</strong> &lt;FilesMatch <em>regex</em>&gt;
-... &lt;/Files&gt;<br>
-<strong>Context:</strong> server config, virtual host, .htaccess<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> only available in Apache
-1.3 and above.<p>
-
-<p>The &lt;FilesMatch&gt; directive provides for access control by
-filename, just as the <a href="#files">&lt;Files&gt;</a> directive
-does. However, it accepts a regular expression. For example:</p>
-
-<pre>
+<STRONG>Syntax:</STRONG> &lt;FilesMatch <EM>regex</EM>&gt;
+... &lt;/Files&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host, .htaccess<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> only available in Apache
+1.3 and above.<P>
+
+<P>The &lt;FilesMatch&gt; directive provides for access control by
+filename, just as the <A HREF="#files">&lt;Files&gt;</A> directive
+does. However, it accepts a regular expression. For example:</P>
+
+<PRE>
    &lt;FilesMatch &quot;\.(gif|jpe?g|png)$&quot;&gt;
-</pre>
+</PRE>
 
-<p>would match most common Internet graphics formats.</p>
+<P>would match most common Internet graphics formats.</P>
 
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
 
-<hr>
+<HR>
 
 <h2><A name="group">Group directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Group} directive&gt; -->
-<strong>Syntax:</strong> Group <em>unix-group</em><br>
-<strong>Default:</strong> <code>Group #-1</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> Group <EM>unix-group</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Group #-1</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The Group directive sets the group under which the server will answer requests.
 In order to use this directive, the stand-alone server must be run initially
-as root. <em>Unix-group</em> is one of:
-<dl>
-<dt>A group name
-<dd>Refers to the given group by name.
-<dt># followed by a group number.
-<dd>Refers to a group by its number.
-</dl>
+as root. <EM>Unix-group</EM> is one of:
+<DL>
+<DT>A group name
+<DD>Refers to the given group by name.
+<DT># followed by a group number.
+<DD>Refers to a group by its number.
+</DL>
 
 It is recommended that you set up a new group specifically for running the
-server. Some admins use user <code>nobody</code>, but this is not always
-possible or desirable.<p>
+server. Some admins use user <CODE>nobody</CODE>, but this is not always
+possible or desirable.<P>
 
 Note: if you start the server as a non-root user, it will fail to change
 to the specified group, and will instead continue to run as the group of the
-original user. <p>
+original user. <P>
 
 Special note: Use of this directive in &lt;VirtualHost&gt; requires a
 properly configured <A HREF="../suexec.html">suEXEC wrapper</A>.
 When used inside a &lt;VirtualHost&gt; in this manner, only the group
 that CGIs are run as is affected.  Non-CGI requests are still processed
-as the group specified in the main Group directive.<p>
+as the group specified in the main Group directive.<P>
 
 SECURITY: See <A HREF="#user">User</A> for a discussion of the security
-considerations.<p><hr>
+considerations.<P><HR>
 
 <h2><A name="hostnamelookups">HostNameLookups directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt HostNameLookups} directive&gt; -->
-<strong>Syntax:</strong> HostNameLookups <em>on | off | double</em><br>
-<strong>Default:</strong> <code>HostNameLookups off</code><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> <code>double</code> available only in Apache
-1.3 and above.<br>
-<strong>Compatibility:</strong> Default was <code>on</code> prior to Apache
-1.3.<p>
+<STRONG>Syntax:</STRONG> HostNameLookups <EM>on | off | double</EM><BR>
+<STRONG>Default:</STRONG> <CODE>HostNameLookups off</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> <CODE>double</CODE> available only in Apache
+1.3 and above.<BR>
+<STRONG>Compatibility:</STRONG> Default was <CODE>on</CODE> prior to Apache
+1.3.<P>
 
 This directive enables DNS lookups so that host names can be logged (and
-passed to CGIs/SSIs in <code>REMOTE_HOST</code>).
-The value <code>double</code> refers to doing double-reverse DNS.
+passed to CGIs/SSIs in <CODE>REMOTE_HOST</CODE>).
+The value <CODE>double</CODE> refers to doing double-reverse DNS.
 That is, after a reverse lookup is performed, a forward lookup is then
 performed on that result.  At least one of the ip addresses in the forward
 lookup must match the original address.  (In "tcpwrappers" terminology
-this is called <code>PARANOID</code>.)<p>
+this is called <CODE>PARANOID</CODE>.)<P>
 
-Regardless of the setting, when <a href="mod_access.html">mod_access</a>
+Regardless of the setting, when <A HREF="mod_access.html">mod_access</A>
 is used for controlling access by hostname, a double reverse lookup
 will be performed.  This is necessary for security.  Note that the
 result of this double-reverse isn't generally available unless
-you set <code>HostnameLookups double</code>.  For example, if only
-<code>HostnameLookups on</code> and a request is made to an object that
+you set <CODE>HostnameLookups double</CODE>.  For example, if only
+<CODE>HostnameLookups on</CODE> and a request is made to an object that
 is protected by hostname restrictions, regardless of whether the
 double-reverse fails or not, CGIs will still be passed the single-reverse
-result in <code>REMOTE_HOST</code>.<p>
+result in <CODE>REMOTE_HOST</CODE>.<P>
 
-The default for this directive was previously <code>on</code> in
-versions of Apache prior to 1.3.  It was changed to <code>off</code>
+The default for this directive was previously <CODE>on</CODE> in
+versions of Apache prior to 1.3.  It was changed to <CODE>off</CODE>
 in order to save the network traffic for those sites that don't truly
 need the reverse lookups done.  It is also better for the end users
 because they don't have to suffer the extra latency that a lookup
 entails.
-Heavily loaded sites should leave this directive <code>off</code>, since DNS
-lookups can take considerable amounts of time. The utility <i>logresolve</i>,
-provided in the <i>/support</i> directory, can be used to look up host names
-from logged IP addresses offline.<p><hr>
+Heavily loaded sites should leave this directive <CODE>off</CODE>, since DNS
+lookups can take considerable amounts of time. The utility <EM>logresolve</EM>,
+provided in the <EM>/support</EM> directory, can be used to look up host names
+from logged IP addresses offline.<P><HR>
 
 <h2><A name="identitycheck">IdentityCheck directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt IdentityCheck} directive&gt; -->
-<strong>Syntax:</strong> IdentityCheck <em>boolean</em><br>
-<strong>Default:</strong> <code>IdentityCheck off</code><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> IdentityCheck <EM>boolean</EM><BR>
+<STRONG>Default:</STRONG> <CODE>IdentityCheck off</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> core<P>
 
 This directive enables RFC1413-compliant logging of the remote user name
 for each connection, where the client machine runs identd or something similar.
-This information is logged in the access log. <em>Boolean</em> is either
-<code>on</code> or <code>off</code>.<p>
+This information is logged in the access log. <EM>Boolean</EM> is either
+<CODE>on</CODE> or <CODE>off</CODE>.<P>
 
 The information should not be trusted in any way except for rudimentary usage
-tracking.<p>
+tracking.<P>
 
 Note that this can cause serious latency problems accessing your server
 since every request requires one of these lookups to be performed.  When
 firewalls are involved each lookup might possibly fail and add 30 seconds
 of latency to each hit.  So in general this is not very useful on public
 servers accessible from the Internet.
-<p><hr>
+<P><HR>
 
 <H2><A NAME="ifmodule">&lt;IfModule&gt; directive</A></H2>
-<b>Syntax:</b> &lt;IfModule [!]<i>module-name</i>&gt; <i>...</i>
-&lt;/IfModule&gt;<br>
-<b>Default:</b> None<br>
-<b>Context:</b> all<br>
-<b>Status:</b> Core<br>
-<strong>Compatibility:</strong> IfModule is only available in 1.2 and
+<STRONG>Syntax:</STRONG> &lt;IfModule [!]<EM>module-name</EM>&gt; <EM>...</EM>
+&lt;/IfModule&gt;<BR>
+<STRONG>Default:</STRONG> None<BR>
+<STRONG>Context:</STRONG> all<BR>
+<STRONG>Status:</STRONG> Core<BR>
+<STRONG>Compatibility:</STRONG> IfModule is only available in 1.2 and
 later.<P>
 
-<p>
+<P>
 
-The &lt;IfModule <i>test</i>&gt;...&lt;/IfModule&gt;
+The &lt;IfModule <EM>test</EM>&gt;...&lt;/IfModule&gt;
 section is used to mark directives that are conditional. The
 directives within an IfModule section are only
-processed if the <i>test</i> is true. If <i>test</i>
+processed if the <EM>test</EM> is true. If <EM>test</EM>
 is false, everything between the start and end markers
-is ignored.<p>
+is ignored.<P>
 
-The <i>test</i> in the &lt;IfModule&gt; section directive
+The <EM>test</EM> in the &lt;IfModule&gt; section directive
 can be one of two forms:
 
-<ul>
-<li><i>module name</i>
-<li>!<i>module name</i>
-</ul>
+<UL>
+<LI><EM>module name</EM>
+<LI>!<EM>module name</EM>
+</UL>
 
-<p>In the former case, the directives between the start and end markers
-are only processed if the module named <i>module name</i> is compiled
+<P>In the former case, the directives between the start and end markers
+are only processed if the module named <EM>module name</EM> is compiled
 in to Apache. The second format reverses the test, and only processes
-the directives if <i>module name</i> is <b>not</b> compiled in.
+the directives if <EM>module name</EM> is <STRONG>not</STRONG> compiled in.
 
-<p>The <i>module name</i> argument is a module name as given as the file
+<P>The <EM>module name</EM> argument is a module name as given as the file
 name of the module, at the time it was compiled. For example,
-<code>mod_rewrite.c</code>.
+<CODE>mod_rewrite.c</CODE>.
 
-<p>&lt;IfModule&gt; sections are nest-able, which can be used to implement
+<P>&lt;IfModule&gt; sections are nest-able, which can be used to implement
 simple multiple-module tests.
 
-<P> <hr>
+<P> <HR>
 
-<h2><a name="include">Include directive</a></h2>
-<strong>Syntax: (Apache 1.2)</strong> Include <em>filename</em><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<br>
-<strong>Compatibility:</strong> Include is only available in Apache 1.3 and later.
+<h2><A name="include">Include directive</A></h2>
+<STRONG>Syntax: (Apache 1.2)</STRONG> Include <EM>filename</EM><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<BR>
+<STRONG>Compatibility:</STRONG> Include is only available in Apache 1.3 and later.
 <P>
 This directive allows inclusion of other configuration files from within the server configuration files.
 
-<P> <hr>
+<P> <HR>
 
-<h2><a name="keepalive">KeepAlive directive</a></h2>
-<strong>Syntax: (Apache 1.1)</strong> KeepAlive <em>max-requests</em><br>
-<strong>Default: (Apache 1.1)</strong> <code>KeepAlive 5</code><br>
-<strong>Syntax: (Apache 1.2)</strong> KeepAlive <em>on/off</em><br>
-<strong>Default: (Apache 1.2)</strong> <code>KeepAlive On</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<br>
-<strong>Compatibility:</strong> KeepAlive is only available in Apache
-1.1 and later.<p>
+<h2><A name="keepalive">KeepAlive directive</A></h2>
+<STRONG>Syntax: (Apache 1.1)</STRONG> KeepAlive <EM>max-requests</EM><BR>
+<STRONG>Default: (Apache 1.1)</STRONG> <CODE>KeepAlive 5</CODE><BR>
+<STRONG>Syntax: (Apache 1.2)</STRONG> KeepAlive <EM>on/off</EM><BR>
+<STRONG>Default: (Apache 1.2)</STRONG> <CODE>KeepAlive On</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<BR>
+<STRONG>Compatibility:</STRONG> KeepAlive is only available in Apache
+1.1 and later.<P>
 
 This directive enables
-<a href="../keepalive.html">Keep-Alive</a>
+<A HREF="../keepalive.html">Keep-Alive</A>
 support.
 
-<p><strong>Apache 1.1</strong>: Set <em>max-requests</em>
+<P><STRONG>Apache 1.1</STRONG>: Set <EM>max-requests</EM>
 to the maximum number of requests you want Apache to entertain per
 request. A limit is imposed to prevent a client from hogging your
-server resources. Set this to <code>0</code> to disable support.
+server resources. Set this to <CODE>0</CODE> to disable support.
 
-<p><strong>Apache 1.2 and later</strong>: Set to "On" to enable
-persistent connections, "Off" to disable. See also the <a
-href="#maxkeepaliverequests">MaxKeepAliveRequests</a> directive.</p><hr>
+<P><STRONG>Apache 1.2 and later</STRONG>: Set to "On" to enable
+persistent connections, "Off" to disable. See also the <A
+HREF="#maxkeepaliverequests">MaxKeepAliveRequests</A> directive.</P><HR>
 
-<h2><a name="keepalivetimeout">KeepAliveTimeout directive</a></h2>
-<strong>Syntax:</strong> KeepAliveTimeout <em>seconds</em><br>
-<strong>Default:</strong> <code>KeepAliveTimeout 15</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<br>
-<strong>Compatibility:</strong> KeepAliveTimeout is only available in Apache
-1.1 and later.<p>
+<h2><A name="keepalivetimeout">KeepAliveTimeout directive</A></h2>
+<STRONG>Syntax:</STRONG> KeepAliveTimeout <EM>seconds</EM><BR>
+<STRONG>Default:</STRONG> <CODE>KeepAliveTimeout 15</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<BR>
+<STRONG>Compatibility:</STRONG> KeepAliveTimeout is only available in Apache
+1.1 and later.<P>
 
 The number of seconds Apache will wait for a subsequent request before
 closing the connection. Once a request has been received, the timeout
-value specified by the <a
-href="#timeout"><code>Timeout</code></a> directive
+value specified by the <A
+HREF="#timeout"><CODE>Timeout</CODE></A> directive
 applies.
-<hr>
+<HR>
 
 <h2><A name="limit">&lt;Limit&gt; directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Limit} section directive&gt; -->
-<strong>Syntax:</strong>
- &lt;Limit <em>method method</em> ... &gt; ... &lt;/Limit&gt;<br>
-<strong>Context:</strong> any<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG>
+ &lt;Limit <EM>method method</EM> ... &gt; ... &lt;/Limit&gt;<BR>
+<STRONG>Context:</STRONG> any<BR>
+<STRONG>Status:</STRONG> core<P>
 
 &lt;Limit&gt; and &lt;/Limit&gt; are used to enclose a group of
 access control directives which will then apply only to the specified
-access methods, where <em>method</em> is any valid HTTP method.
+access methods, where <EM>method</EM> is any valid HTTP method.
 Any directive except another &lt;Limit&gt; or
 <A HREF="#directory">&lt;Directory&gt;</A> may be used; the majority will be
 unaffected by the &lt;Limit&gt;. Example:
-<blockquote><code>
-&lt;Limit GET POST&gt;<br>
-require valid-user<br>
-&lt;/Limit&gt;</code></blockquote>
+<BLOCKQUOTE><CODE>
+&lt;Limit GET POST&gt;<BR>
+require valid-user<BR>
+&lt;/Limit&gt;</CODE></BLOCKQUOTE>
 
 If an access control directive appears outside a &lt;Limit&gt;
 directive, then it applies to all access methods. The method names
 listed can be one or more of: GET, POST, PUT, DELETE, CONNECT or
 OPTIONS. If GET is used it will also restrict HEAD requests.
 <STRONG>If you wish to limit all methods, do not include any
-&lt;Limit&gt; directive at all.</STRONG> <p><hr>
+&lt;Limit&gt; directive at all.</STRONG> <P><HR>
 
 <h2><A name="listen">Listen directive</A></h2>
-<strong>Syntax:</strong>
-Listen [<em>IP address</em>:]<em>port number</em><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> Listen is only available in Apache
-1.1 and later.<p>
-
-<p>The Listen directive instructs Apache to listen to more than one IP
+<STRONG>Syntax:</STRONG>
+Listen [<EM>IP address</EM>:]<EM>port number</EM><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> Listen is only available in Apache
+1.1 and later.<P>
+
+<P>The Listen directive instructs Apache to listen to more than one IP
 address or port; by default it responds to requests on all IP
-interfaces, but only on the port given by the <code><a
-href="#port">Port</a></code> directive.</p>
+interfaces, but only on the port given by the <CODE><A
+HREF="#port">Port</A></CODE> directive.</P>
 
-<tt>Listen</tt> can be used instead of <tt><a
-href="#bindaddress">BindAddress</a></tt> and <tt>Port</tt>. It tells
+<TT>Listen</TT> can be used instead of <TT><A
+HREF="#bindaddress">BindAddress</A></TT> and <TT>Port</TT>. It tells
 the server to accept incoming requests on the specified port or
 address-and-port combination. If the first format is used, with a port
 number only, the server listens to the given port on all interfaces,
-instead of the port given by the <tt>Port</tt> directive. If an IP
+instead of the port given by the <TT>Port</TT> directive. If an IP
 address is given as well as a port, the server will listen on the
-given port and interface.  <p>
+given port and interface.  <P>
 
-Note that you may still require a <tt>Port</tt> directive so
+Note that you may still require a <TT>Port</TT> directive so
 that URLs that Apache generates that point to your server still
-work.<p>
+work.<P>
 
 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:
-<pre>
+<PRE>
    Listen 80
    Listen 8000
-</pre>
+</PRE>
 
 To make the server accept connections on two specified
 interfaces and port numbers, use
-<pre>
+<PRE>
    Listen 192.170.2.1:80
    Listen 192.170.2.5:8000
-</pre>
+</PRE>
 
-<p><strong>See Also:</strong>
-<a href="../dns-caveats.html">DNS Issues</a><br>
-<strong>See Also:</strong>
-<a href="../bind.html">Setting which addresses and ports Apache uses</a><br>
-<strong>See Also:</strong>
-<a href="../misc/known_bugs.html#listenbug">Known Bugs</a></p>
-<hr>
+<P><STRONG>See Also:</STRONG>
+<A HREF="../dns-caveats.html">DNS Issues</A><BR>
+<STRONG>See Also:</STRONG>
+<A HREF="../bind.html">Setting which addresses and ports Apache uses</A><BR>
+<STRONG>See Also:</STRONG>
+<A HREF="../misc/known_bugs.html#listenbug">Known Bugs</A></P>
+<HR>
 
 <H2><A NAME="listenbacklog">ListenBacklog directive</A></H2>
-<strong>Syntax:</strong> ListenBacklog <em>backlog</em><br>
-<strong>Default:</strong> <code>ListenBacklog 511</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<br>
-<strong>Compatibility:</strong> ListenBacklog is only available in Apache
-versions after 1.2.0.<p>
+<STRONG>Syntax:</STRONG> ListenBacklog <EM>backlog</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ListenBacklog 511</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<BR>
+<STRONG>Compatibility:</STRONG> ListenBacklog is only available in Apache
+versions after 1.2.0.<P>
 
 The maximum length of the queue of pending connections.  Generally no
 tuning is needed or desired, however on some systems it is desirable
 to increase this when under a TCP SYN flood attack.  See
-the backlog parameter to the <code>listen(2)</code> system call.</p><hr>
+the backlog parameter to the <CODE>listen(2)</CODE> system call.</P><HR>
 
-<h2><a name="location">&lt;Location&gt; directive</a></h2>
+<h2><A name="location">&lt;Location&gt; directive</A></h2>
 
-<strong>Syntax:</strong> &lt;Location <em>URL</em>&gt;
-... &lt;/Location&gt;<br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> Location is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> &lt;Location <EM>URL</EM>&gt;
+... &lt;/Location&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> Location is only available in Apache
+1.1 and later.<P>
 
-<p>The &lt;Location&gt; directive provides for access control by
-URL. It is comparable to the <a
-href="#directory">&lt;Directory&gt;</a> directive, and
+<P>The &lt;Location&gt; directive provides for access control by
+URL. It is comparable to the <A
+HREF="#directory">&lt;Directory&gt;</A> directive, and
 should be matched with a &lt;/Location&gt; directive. Directives that
 apply to the URL given should be listed
-within. <code>&lt;Location&gt;</code> sections are processed in the
+within. <CODE>&lt;Location&gt;</CODE> sections are processed in the
 order they appear in the configuration file, after the
-&lt;Directory&gt; sections and <code>.htaccess</code> files are
-read.</p>
+&lt;Directory&gt; sections and <CODE>.htaccess</CODE> files are
+read.</P>
 
-<p>Note that, due to the way HTTP functions, <em>URL prefix</em>
-should, save for proxy requests, be of the form <code>/path/</code>,
-and should not include the <code>http://servername</code>. It doesn't
+<P>Note that, due to the way HTTP functions, <EM>URL prefix</EM>
+should, save for proxy requests, be of the form <CODE>/path/</CODE>,
+and should not include the <CODE>http://servername</CODE>. It doesn't
 necessarily have to protect a directory (it can be an individual
 file, or a number of files), and can include wild-cards.  In a wild-card
 string, `?' matches any single character, and `*' matches any
 sequences of characters.
 
-<p><strong>Apache 1.2 and above:</strong>
+<P><STRONG>Apache 1.2 and above:</STRONG>
 Extended regular expressions can also be used, with the addition of
 the
-<code>~</code> character. For example:</p>
+<CODE>~</CODE> character. For example:</P>
 
-<pre>
+<PRE>
    &lt;Location ~ &quot;/(extra|special)/data&quot;&gt;
-</pre>
+</PRE>
 
-<p>would match URLs that contained the substring "/extra/data" or
-"/special/data". However, in Apache 1.3 and above, use of <a
-href="#locationmatch">&lt;LocationMatch&gt;</a> is preferred.</p>
+<P>would match URLs that contained the substring "/extra/data" or
+"/special/data". However, in Apache 1.3 and above, use of <A
+HREF="#locationmatch">&lt;LocationMatch&gt;</A> is preferred.</P>
 
-<p>The <code>Location</code> functionality is especially useful when
-combined with the <code><a
-href="mod_mime.html#sethandler">SetHandler</a></code> directive. For example, to enable status requests, but allow them only
+<P>The <CODE>Location</CODE> functionality is especially useful when
+combined with the <CODE><A
+HREF="mod_mime.html#sethandler">SetHandler</A></CODE> directive. For example, to enable status requests, but allow them only
 from browsers at foo.com, you might use:
 
-<pre>
+<PRE>
     &lt;Location /status&gt;
     SetHandler server-status
     order deny,allow
     deny from all
     allow from .foo.com
     &lt;/Location&gt;
-</pre>
+</PRE>
 
-<p>
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+<P>
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
 
-<hr>
+<HR>
 
-<h2><a name="locationmatch">&lt;LocationMatch&gt;</a></h2>
+<h2><A name="locationmatch">&lt;LocationMatch&gt;</A></h2>
 
-<strong>Syntax:</strong> &lt;LocationMatch <em>regex</em>&gt;
-... &lt;/LocationMatch&gt;<br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> Location is only available in Apache
-1.3 and later.<p>
+<STRONG>Syntax:</STRONG> &lt;LocationMatch <EM>regex</EM>&gt;
+... &lt;/LocationMatch&gt;<BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> Location is only available in Apache
+1.3 and later.<P>
 
-<p>The &lt;LocationMatch&gt; directive provides for access control by
-URL, in an identical manner to <a
-href="#location">&lt;Location&gt;</a>. However, it takes a regular
-expression as an argument instead of a simple string. For example:</p>
+<P>The &lt;LocationMatch&gt; directive provides for access control by
+URL, in an identical manner to <A
+HREF="#location">&lt;Location&gt;</A>. However, it takes a regular
+expression as an argument instead of a simple string. For example:</P>
 
-<pre>
+<PRE>
    &lt;LocationMatch &quot;/(extra|special)/data&quot;&gt;
-</pre>
+</PRE>
 
-<p>would match URLs that contained the substring "/extra/data" or
-"/special/data".</p>
+<P>would match URLs that contained the substring "/extra/data" or
+"/special/data".</P>
 
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
 
-<hr>
+<HR>
 
 <H2><A NAME="lockfile">LockFile directive</A></H2>
-<strong>Syntax:</strong> LockFile <em>filename</em><BR>
-<strong>Default:</strong> <code>LockFile logs/accept.lock</code><BR>
-<strong>Context:</strong> server config<BR>
-<strong>Status:</strong> core<P>
+<STRONG>Syntax:</STRONG> LockFile <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>LockFile logs/accept.lock</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The LockFile directive sets the path to the lockfile used when
 Apache is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or
 USE_FLOCK_SERIALIZED_ACCEPT.  This directive should normally be
 left at its default value.  The main reason for changing it is if
-the <code>logs</code> directory is NFS mounted, since <b>the lockfile
-must be stored on a local disk</b>.  The PID of the main
-server process is automatically appended to the filename. <p>
+the <CODE>logs</CODE> directory is NFS mounted, since <STRONG>the lockfile
+must be stored on a local disk</STRONG>.  The PID of the main
+server process is automatically appended to the filename. <P>
 
 <STRONG>SECURITY:</STRONG> It is best to avoid putting this file in a 
 world writable directory such as <CODE>/var/tmp</CODE> because someone 
 could create a denial of service attack and prevent the server from
 starting by creating a lockfile with the same name as the one the 
-server will try to create.<p>
+server will try to create.<P>
 
 <P><HR>
 
 <h2><A name="maxclients">MaxClients directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt MaxClients} directive&gt; -->
-<strong>Syntax:</strong> MaxClients <em>number</em><br>
-<strong>Default:</strong> <code>MaxClients 256</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> MaxClients <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MaxClients 256</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The MaxClients directive sets the limit on the number of simultaneous
 requests that can be supported; not more than this number of child server
-processes will be created.<p><hr>
+processes will be created.<P><HR>
 
 <h2><A name="maxkeepaliverequests">MaxKeepAliveRequests directive</A></h2>
-<strong>Syntax:</strong> MaxKeepAliveRequests <em>number</em><br>
-<strong>Default:</strong> <code>MaxKeepAliveRequests 100</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> Only available in Apache
+<STRONG>Syntax:</STRONG> MaxKeepAliveRequests <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MaxKeepAliveRequests 100</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> Only available in Apache
 1.2 and later.
 
-<p>The MaxKeepAliveRequests directive limits the number of requests
-allowed per connection when <a href="#keepalive">KeepAlive</a> is
-on. If it is set to "<code>0</code>", unlimited requests will be
+<P>The MaxKeepAliveRequests directive limits the number of requests
+allowed per connection when <A HREF="#keepalive">KeepAlive</A> is
+on. If it is set to "<CODE>0</CODE>", unlimited requests will be
 allowed. We recommend that this setting be kept to a high value for
-maximum server performance.</p><hr>
+maximum server performance.</P><HR>
 
 <h2><A name="maxrequestsperchild">MaxRequestsPerChild directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt MaxRequestsPerChild} directive&gt; -->
-<strong>Syntax:</strong> MaxRequestsPerChild <em>number</em><br>
-<strong>Default:</strong> <code>MaxRequestsPerChild 0</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> MaxRequestsPerChild <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MaxRequestsPerChild 0</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The MaxRequestsPerChild directive sets the limit on the number of requests
 that an individual child server process will handle. After MaxRequestsPerChild
 requests, the child process will die. If MaxRequestsPerChild is 0, then
-the process will never expire.<p>
+the process will never expire.<P>
 
 Setting MaxRequestsPerChild to a non-zero limit has two beneficial effects:
-<ul>
-<li>it limits the amount of memory that process can consume by (accidental)
+<UL>
+<LI>it limits the amount of memory that process can consume by (accidental)
 memory leakage;
-<li> by giving processes a finite lifetime, it helps reduce the
+<LI> by giving processes a finite lifetime, it helps reduce the
 number of processes when the server load reduces.
-</ul><p><hr>
+</UL><P><HR>
 
 <h2><A name="maxspareservers">MaxSpareServers directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt MaxSpareServers} directive&gt; -->
-<strong>Syntax:</strong> MaxSpareServers <em>number</em><br>
-<strong>Default:</strong> <code>MaxSpareServers 10</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> MaxSpareServers <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MaxSpareServers 10</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
-The MaxSpareServers directive sets the desired maximum number of <em>idle</em>
+The MaxSpareServers directive sets the desired maximum number of <EM>idle</EM>
 child server processes. An idle process is one which is not handling
 a request. If there are more than MaxSpareServers idle, then the parent
-process will kill off the excess processes.<p>
+process will kill off the excess processes.<P>
 
 Tuning of this parameter should only be necessary on very busy sites.
-Setting this parameter to a large number is almost always a bad idea.<p>
+Setting this parameter to a large number is almost always a bad idea.<P>
 
 See also <A HREF="#minspareservers">MinSpareServers</A> and
-<A HREF="#startservers">StartServers</A>.<p><hr>
+<A HREF="#startservers">StartServers</A>.<P><HR>
 
 <h2><A name="minspareservers">MinSpareServers directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt MinSpareServers} directive&gt; -->
-<strong>Syntax:</strong> MinSpareServers <em>number</em><br>
-<strong>Default:</strong> <code>MinSpareServers 5</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> MinSpareServers <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MinSpareServers 5</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
-The MinSpareServers directive sets the desired minimum number of <em>idle</em>
+The MinSpareServers directive sets the desired minimum number of <EM>idle</EM>
 child server processes. An idle process is one which is not handling
 a request. If there are fewer than MinSpareServers idle, then the parent
-process creates new children at a maximum rate of 1 per second.<p>
+process creates new children at a maximum rate of 1 per second.<P>
 
 Tuning of this parameter should only be necessary on very busy sites.
-Setting this parameter to a large number is almost always a bad idea.<p>
+Setting this parameter to a large number is almost always a bad idea.<P>
 
 See also <A HREF="#maxspareservers">MaxSpareServers</A> and
-<A HREF="#startservers">StartServers</A>.<p><hr>
+<A HREF="#startservers">StartServers</A>.<P><HR>
 
 <h2><A name="namevirtualhost">NameVirtualHost directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt NameVirtualHost} directive&gt; -->
-<strong>Syntax:</strong> NameVirtualHost <em>addr</em>[:<em>port</em>]<br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
-<strong>Compatibility:</strong> NameVirtualHost is only available in Apache 1.3 and later<p>
+<STRONG>Syntax:</STRONG> NameVirtualHost <EM>addr</EM>[:<EM>port</EM>]<BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
+<STRONG>Compatibility:</STRONG> NameVirtualHost is only available in Apache 1.3 and later<P>
 
 The NameVirtualHost directive is a required directive if you want to configure
-<A HREF="../vhosts/index.html">name-based virtual hosts</A>.<p>
+<A HREF="../vhosts/index.html">name-based virtual hosts</A>.<P>
 
-Although <em>addr</em> can be hostname it is recommended that you always use
+Although <EM>addr</EM> can be hostname it is recommended that you always use
 an IP address, e.g.
 
-<blockquote><code>NameVirtualHost 111.22.33.44</code></blockquote>
+<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44</CODE></BLOCKQUOTE>
 
 With the NameVirtualHost directive the address to which your name-based
 virtual host names resolve.
 If you have multiple name-based hosts on multiple addresses,
-repeat the directive for each address.<p>
+repeat the directive for each address.<P>
 
 Optionally you can specify a port number on which the name-based
 virtual hosts should be used, e.g.
 
-<blockquote><code>NameVirtualHost 111.22.33.44:8080</code></blockquote>
+<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44:8080</CODE></BLOCKQUOTE>
 
-<strong>See also:</strong>
-<a href="../vhosts/index.html">Apache Virtual Host documentation</a>
+<STRONG>See also:</STRONG>
+<A HREF="../vhosts/index.html">Apache Virtual Host documentation</A>
 
 <h2><A name="options">Options directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Options} directive&gt; -->
-<strong>Syntax:</strong> Options <em>[+|-]option [+|-]option ...</em><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Override:</strong> Options<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> Options <EM>[+|-]option [+|-]option ...</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Override:</STRONG> Options<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The Options directive controls which server features are available in
 a particular directory.
-<p>
-<em>option</em> can be set to <code>None</code>, in which case none of
+<P>
+<EM>option</EM> can be set to <CODE>None</CODE>, in which case none of
 the extra features are enabled, or one or more of the following:
-<dl>
-<dt>All
-<dd>All options except for MultiViews.
-<dt>ExecCGI
-<dd>
+<DL>
+<DT>All
+<DD>All options except for MultiViews.
+<DT>ExecCGI
+<DD>
 <!--%plaintext &lt;?INDEX {\tt ExecCGI} option&gt; -->
 Execution of CGI scripts is permitted.
-<dt>FollowSymLinks
-<dd>
+<DT>FollowSymLinks
+<DD>
 <!--%plaintext &lt;?INDEX {\tt FollowSymLinks} option&gt; -->
 The server will follow symbolic links in this directory.
-<b>Note</b>: even though the server follows the symlink it does <i>not</i>
-change the pathname used to match against <code>&lt;Directory&gt;</code>
+<STRONG>Note</STRONG>: even though the server follows the symlink it does <EM>not</EM>
+change the pathname used to match against <CODE>&lt;Directory&gt;</CODE>
 sections.
-<dt>Includes
-<dd>
+<DT>Includes
+<DD>
 <!--%plaintext &lt;?INDEX {\tt Includes} option&gt; -->
 Server-side includes are permitted.
-<dt>IncludesNOEXEC
-<dd>
+<DT>IncludesNOEXEC
+<DD>
 <!--%plaintext &lt;?INDEX {\tt IncludesNOEXEC} option&gt; -->
 Server-side includes are permitted, but the #exec command and
 #include of CGI scripts are disabled.
-<dt>Indexes
-<dd>
+<DT>Indexes
+<DD>
 <!--%plaintext &lt;?INDEX {\tt Indexes} option&gt; -->
 If a URL which maps to a directory is requested, and the there is no
 DirectoryIndex (e.g. index.html) in that directory, then the server will
 return a formatted listing of the directory.
-<dt>MultiViews
-<dd>
+<DT>MultiViews
+<DD>
 <!--%plaintext &lt;?INDEX {\tt MultiViews} option&gt; -->
 <A HREF="../content-negotiation.html">Content negotiated</A> MultiViews are
 allowed.
-<dt>SymLinksIfOwnerMatch
-<dd>
+<DT>SymLinksIfOwnerMatch
+<DD>
 <!--%plaintext &lt;?INDEX {\tt SymLinksIfOwnerMatch} option&gt; -->
 The server will only follow symbolic links for which the target
 file or directory is owned by the same user id as the link.
-</dl>
+</DL>
 
-Normally, if multiple <code>Options</code> could apply to a directory,
+Normally, if multiple <CODE>Options</CODE> could apply to a directory,
 then the most specific one is taken complete; the options are not
-merged. However if <i>all</i> the options on the <code>Options</code>
+merged. However if <EM>all</EM> the options on the <CODE>Options</CODE>
 directive are preceded by a + or - symbol, the options are
 merged. Any options preceded by a + are added to the options
 currently in force, and any options preceded by a - are removed from
@@ -1209,258 +1209,258 @@ the options currently in force.  <P>
 
 For example, without any + and - symbols:
 
-<blockquote><code>
-&lt;Directory /web/docs&gt; <br>
-Options Indexes FollowSymLinks<br>
-&lt;/Directory&gt;<br>
-&lt;Directory /web/docs/spec&gt; <br>
-Options Includes<br>
+<BLOCKQUOTE><CODE>
+&lt;Directory /web/docs&gt; <BR>
+Options Indexes FollowSymLinks<BR>
+&lt;/Directory&gt;<BR>
+&lt;Directory /web/docs/spec&gt; <BR>
+Options Includes<BR>
 &lt;/Directory&gt;
-</code></blockquote>
-then only <code>Includes</code> will be set for the /web/docs/spec
-directory. However if the second <code>Options</code> directive uses the +
-and - symbols:<p>
-
-<blockquote><code>
-&lt;Directory /web/docs&gt; <br>
-Options Indexes FollowSymLinks<br>
-&lt;/Directory&gt;<br>
-&lt;Directory /web/docs/spec&gt; <br>
-Options +Includes -Indexes<br>
+</CODE></BLOCKQUOTE>
+then only <CODE>Includes</CODE> will be set for the /web/docs/spec
+directory. However if the second <CODE>Options</CODE> directive uses the +
+and - symbols:<P>
+
+<BLOCKQUOTE><CODE>
+&lt;Directory /web/docs&gt; <BR>
+Options Indexes FollowSymLinks<BR>
+&lt;/Directory&gt;<BR>
+&lt;Directory /web/docs/spec&gt; <BR>
+Options +Includes -Indexes<BR>
 &lt;/Directory&gt;
-</code></blockquote>
-then the options <code>FollowSymLinks</code> and <code>Includes</code>
+</CODE></BLOCKQUOTE>
+then the options <CODE>FollowSymLinks</CODE> and <CODE>Includes</CODE>
 are set for the /web/docs/spec directory.
-<hr>
+<HR>
 
 <h2><A name="pidfile">PidFile directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt PidFile} directive&gt; -->
-<strong>Syntax:</strong> PidFile <em>filename</em><br>
-<strong>Default:</strong> <code>PidFile logs/httpd.pid</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> PidFile <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>PidFile logs/httpd.pid</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The PidFile directive sets the file to which the server records the
 process id of the daemon. If the filename does not begin with a slash (/)
 then it is assumed to be relative to the <A HREF="#serverroot">ServerRoot</A>.
-The PidFile is only used in <A HREF="#servertype">standalone</A> mode.<p>
+The PidFile is only used in <A HREF="#servertype">standalone</A> mode.<P>
 
 It is often useful to be able to send the server a signal, so that it closes
 and then reopens its <A HREF="#errorlog">ErrorLog</A> and TransferLog, and
 re-reads its configuration files. This is done by sending a SIGHUP (kill -1)
-signal to the process id listed in the PidFile.<p>
+signal to the process id listed in the PidFile.<P>
 
 The PidFile is subject to the same warnings about log file placement and
-<a href="../misc/security_tips.html#serverroot">security</a>.
+<A HREF="../misc/security_tips.html#serverroot">security</A>.
 
-<p><hr>
+<P><HR>
 
 <h2><A name="port">Port directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Port} directive&gt; -->
-<strong>Syntax:</strong> Port <em>number</em><br>
-<strong>Default:</strong> <code>Port 80</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> Port <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Port 80</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
-<em>Number</em> is a number from 0 to 65535; some port numbers (especially below
-1024) are reserved for particular protocols. See <code>/etc/services</code>
+<EM>Number</EM> is a number from 0 to 65535; some port numbers (especially below
+1024) are reserved for particular protocols. See <CODE>/etc/services</CODE>
 for a list of some defined ports; the standard port for the http protocol
-is 80.<p>
+is 80.<P>
 
 The Port directive has two behaviors, the first of which is necessary for
 NCSA backwards compatibility (and which is confusing in the context of
-Apache).<p>
+Apache).<P>
 
-<ul>
-<li>
-In the absence of any <a href="#listen">Listen</a> or
-<a href="#bindaddress">BindAddress</a> directives specifying a port number,
+<UL>
+<LI>
+In the absence of any <A HREF="#listen">Listen</A> or
+<A HREF="#bindaddress">BindAddress</A> directives specifying a port number,
 a Port directive given in the "main server"
-(i.e. outside any <a href="#virtualhost">&lt;VirtualHost&gt</a> section)
+(i.e. outside any <A HREF="#virtualhost">&lt;VirtualHost&gt</A> section)
 sets the network port on which the server listens.
 If there are any Listen or BindAddress directives specifying
-<code>:number</code> then Port has no effect on what address the server
+<CODE>:number</CODE> then Port has no effect on what address the server
 listens at.
 
-<li>The Port directive
-sets the <code>SERVER_PORT</code> environment variable (for
-<a href="mod_cgi.html">CGI</a> and <a href="mod_include.html">SSI</a>),
+<LI>The Port directive
+sets the <CODE>SERVER_PORT</CODE> environment variable (for
+<A HREF="mod_cgi.html">CGI</A> and <A HREF="mod_include.html">SSI</A>),
 and is used when the server must generate a URL that refers to itself
 (for example when creating an external redirect to itself).
-</ul>
+</UL>
 
 In no event does a Port setting affect
-what ports a <a href="#virtualhost">VirtualHost</a> responds on, the
-VirtualHost directive itself is used for that.<p>
+what ports a <A HREF="#virtualhost">VirtualHost</A> responds on, the
+VirtualHost directive itself is used for that.<P>
 
 The primary behaviour of Port should be considered to be similar to that of
-the <a href="#servername">ServerName</a> directive.  The ServerName
-and Port together specify what you consider to be the <i>canonical</i>
-address of the server.<p>
+the <A HREF="#servername">ServerName</A> directive.  The ServerName
+and Port together specify what you consider to be the <EM>canonical</EM>
+address of the server.<P>
 
 Port 80 is one of Unix's special ports. All ports numbered
 below 1024 are reserved for system use, i.e. regular (non-root) users cannot
 make use of them; instead they can only use higher port numbers.
 To use port 80, you must start the server from the root account.
 After binding to the port and before accepting requests, Apache will change
-to a low privileged user as set by the <A HREF="#user">User directive</A>.<p>
+to a low privileged user as set by the <A HREF="#user">User directive</A>.<P>
 
 If you cannot use port 80, choose any other unused port. Non-root users
-will have to choose a port number higher than 1023, such as 8000.<p>
+will have to choose a port number higher than 1023, such as 8000.<P>
 
 SECURITY: if you do start the server as root, be sure
 not to set <A HREF="#user">User</A> to root. If you run the server as
 root whilst handling connections, your site may be open to a major security
-attack.<p><hr>
+attack.<P><HR>
 
 <h2><A name="require">require directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt require} directive&gt; -->
-<strong>Syntax:</strong> require <em>entity-name entity entity...</em><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> require <EM>entity-name entity entity...</EM><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> core<P>
 
 This directive selects which authenticated users can access a directory.
 The allowed syntaxes are:
-<ul>
-<li>require user <em>userid userid ...</em><p>
-Only the named users can access the directory.<p>
-<li>require group <em>group-name group-name ...</em><p>
-Only users in the named groups can access the directory.<p>
-<li>require valid-user<p>
+<UL>
+<LI>require user <EM>userid userid ...</EM><P>
+Only the named users can access the directory.<P>
+<LI>require group <EM>group-name group-name ...</EM><P>
+Only users in the named groups can access the directory.<P>
+<LI>require valid-user<P>
 All valid users can access the directory.
-</ul>
-<p>
-If <code>require</code> appears in a <A HREF="#limit">&lt;Limit&gt;</A>
+</UL>
+<P>
+If <CODE>require</CODE> appears in a <A HREF="#limit">&lt;Limit&gt;</A>
 section, then it restricts access to the named methods, otherwise
 it restricts access for all methods. Example:
-<blockquote><code>
-AuthType Basic<br>
-AuthName somedomain<br>
-AuthUserFile /web/users<br>
-AuthGroupFile /web/groups<br>
-&lt;Limit GET POST&gt;<br>
-require group admin<br>
+<BLOCKQUOTE><CODE>
+AuthType Basic<BR>
+AuthName somedomain<BR>
+AuthUserFile /web/users<BR>
+AuthGroupFile /web/groups<BR>
+&lt;Limit GET POST&gt;<BR>
+require group admin<BR>
 &lt;/Limit&gt;
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
 Require must be accompanied by <A HREF="#authname">AuthName</A> and
 <A HREF="#authtype">AuthType</A> directives, and directives such as
 <A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
 <A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> (to define users and
-groups) in order to work correctly.<p><hr>
+groups) in order to work correctly.<P><HR>
 
 <h2><A name="resourceconfig">ResourceConfig directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ResourceConfig} directive&gt; -->
-<strong>Syntax:</strong> ResourceConfig <em>filename</em><br>
-<strong>Default:</strong> <code>ResourceConfig conf/srm.conf</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ResourceConfig <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ResourceConfig conf/srm.conf</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The server will read this file for more directives after reading the
-httpd.conf file. <em>Filename</em> is relative to the
+httpd.conf file. <EM>Filename</EM> is relative to the
 <A HREF="#serverroot">ServerRoot</A>.
 This feature can be disabled using:
-<blockquote><code>ResourceConfig /dev/null</code></blockquote>
+<BLOCKQUOTE><CODE>ResourceConfig /dev/null</CODE></BLOCKQUOTE>
 Historically, this file contained most directives except for server
 configuration directives and <A HREF="#directory">&lt;Directory&gt;</A>
 sections; in fact it can now contain any server directive allowed in the
-<em>server config</em> context.<p>
+<EM>server config</EM> context.<P>
 
-See also <A HREF="#accessconfig">AccessConfig</A>.<p><hr>
+See also <A HREF="#accessconfig">AccessConfig</A>.<P><HR>
 
 <H2><A name="rlimit">RLimitCPU</A> <A NAME="rlimitcpu">directive</A></H2>
 <!--%plaintext &lt;?INDEX {\tt RLimitCPU} directive&gt; -->
-<strong>Syntax:</strong> RLimitCPU <em># or 'max'</em> <em>[# or 'max']</em><br>
-<strong>Default:</strong> <em>Unset; uses operating system defaults</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> RLimitCPU is only available in Apache 1.2 and later<p>
+<STRONG>Syntax:</STRONG> RLimitCPU <EM># or 'max'</EM> <EM>[# or 'max']</EM><BR>
+<STRONG>Default:</STRONG> <EM>Unset; uses operating system defaults</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> RLimitCPU is only available in Apache 1.2 and later<P>
 
 Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all
 processes and the second parameter sets the maximum resource limit. Either parameter
-can be a number, or <em>max</em> to indicate to the server that the limit should
+can be a number, or <EM>max</EM> to indicate to the server that the limit should
 be set to the maximum allowed by the operating system configuration. Raising the
 maximum resource limit requires that the server is running as root, or in the initial
-startup phase.<p>
+startup phase.<P>
 
-CPU resource limits are expressed in seconds per process.<p>
+CPU resource limits are expressed in seconds per process.<P>
 
-See also <A HREF="#rlimitmem">RLimitMEM</A> or <A HREF="#rlimitnproc">RLimitNPROC</A>.<p><hr>
+See also <A HREF="#rlimitmem">RLimitMEM</A> or <A HREF="#rlimitnproc">RLimitNPROC</A>.<P><HR>
 
 <h2><A name="rlimitmem">RLimitMEM directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt RLimitMEM} directive&gt; -->
-<strong>Syntax:</strong> RLimitMEM <em># or 'max'</em> <em>[# or 'max']</em><br>
-<strong>Default:</strong> <em>Unset; uses operating system defaults</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> RLimitMEM is only available in Apache 1.2 and later<p>
+<STRONG>Syntax:</STRONG> RLimitMEM <EM># or 'max'</EM> <EM>[# or 'max']</EM><BR>
+<STRONG>Default:</STRONG> <EM>Unset; uses operating system defaults</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> RLimitMEM is only available in Apache 1.2 and later<P>
 
 Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all
 processes and the second parameter sets the maximum resource limit. Either parameter
-can be a number, or <em>max</em> to indicate to the server that the limit should
+can be a number, or <EM>max</EM> to indicate to the server that the limit should
 be set to the maximum allowed by the operating system configuration. Raising the
 maximum resource limit requires that the server is running as root, or in the initial
-startup phase.<p>
+startup phase.<P>
 
-Memory resource limits are expressed in bytes per process.<p>
+Memory resource limits are expressed in bytes per process.<P>
 
-See also <A HREF="#rlimitcpu">RLimitCPU</A> or <A HREF="#rlimitnproc">RLimitNPROC</A>.<p><hr>
+See also <A HREF="#rlimitcpu">RLimitCPU</A> or <A HREF="#rlimitnproc">RLimitNPROC</A>.<P><HR>
 
 <h2><A name="rlimitnproc">RLimitNPROC directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt RLimitNPROC} directive&gt; -->
-<strong>Syntax:</strong> RLimitNPROC <em># or 'max'</em> <em>[# or 'max']</em><br>
-<strong>Default:</strong> <em>Unset; uses operating system defaults</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> RLimitNPROC is only available in Apache 1.2 and later<p>
+<STRONG>Syntax:</STRONG> RLimitNPROC <EM># or 'max'</EM> <EM>[# or 'max']</EM><BR>
+<STRONG>Default:</STRONG> <EM>Unset; uses operating system defaults</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> RLimitNPROC is only available in Apache 1.2 and later<P>
 
 Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all
 processes and the second parameter sets the maximum resource limit. Either parameter
-can be a number, or <em>max</em> to indicate to the server that the limit should
+can be a number, or <EM>max</EM> to indicate to the server that the limit should
 be set to the maximum allowed by the operating system configuration. Raising the
 maximum resource limit requires that the server is running as root, or in the initial
-startup phase.<p>
+startup phase.<P>
 
-Process limits control the number of processes per user.<p>
+Process limits control the number of processes per user.<P>
 
-Note: If CGI processes are <b>not</b> running under userids other than the
+Note: If CGI processes are <STRONG>not</STRONG> running under userids other than the
 web server userid, this directive will limit the number of processes that the
 server itself can create. Evidence of this situation will be indicated by
-<b><em>cannot fork</em></b> messages in the error_log.<p>
+<STRONG><EM>cannot fork</EM></STRONG> messages in the error_log.<P>
 
 See also <A HREF="#rlimitmem">RLimitMEM</A> or <A HREF="#rlimitcpu">RLimitCPU</A>.
 
-<p><hr>
+<P><HR>
 
 <h2><A name="satisfy">Satisfy directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Satisfy} directive&gt; -->
-<strong>Syntax:</strong> Satisfy <em>'any' or 'all'</em><br>
-<strong>Default:</strong> Satisfy all<br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> Satisfy is only available in Apache 1.2 and later<p>
+<STRONG>Syntax:</STRONG> Satisfy <EM>'any' or 'all'</EM><BR>
+<STRONG>Default:</STRONG> Satisfy all<BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> Satisfy is only available in Apache 1.2 and later<P>
 
 Access policy if both allow and require used. The parameter can be
-either <em>'all'</em> or <em>'any'</em>. This directive is only useful
+either <EM>'all'</EM> or <EM>'any'</EM>. This directive is only useful
 if access to a particular area is being restricted by both
-username/password <i>and</i> client host address. In this case the
+username/password <EM>and</EM> client host address. In this case the
 default behavior ("all") is to require that the client passes the
-address access restriction <i>and</i> enters a valid username and
+address access restriction <EM>and</EM> enters a valid username and
 password. With the "any" option the client will be granted access if
 they either pass the host restriction or enter a valid username and
 password. This can be used to password restrict an area, but to let
 clients from particular addresses in without prompting for a password.
 
 
-<p><hr>
+<P><HR>
 
 <h2><A name="scoreboardfile">ScoreBoardFile directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ScoreBoardFile} directive&gt; -->
-<strong>Syntax:</strong> ScoreBoardFile <em>filename</em><br>
-<strong>Default:</strong> <code>ScoreBoardFile logs/apache_status</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ScoreBoardFile <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ScoreBoardFile logs/apache_status</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The ScoreBoardFile directive is required on some architectures to place
 a file that the server will use to communicate between its children and
@@ -1468,143 +1468,143 @@ the parent.  The easiest way to find out if your architecture requires
 a scoreboard file is to run Apache and see if it creates the file named
 by the directive.  If your architecture requires it then you must ensure
 that this file is not used at the same time by more than one invocation
-of Apache.<p>
+of Apache.<P>
 
 If you have to use a ScoreBoardFile then you may see improved speed by
 placing it on a RAM disk.  But be careful that you heed the same warnings
 about log file placement and
-<a href="../misc/security_tips.html">security</a>.<p>
+<A HREF="../misc/security_tips.html">security</A>.<P>
 
-Apache 1.2 and above:<p>
+Apache 1.2 and above:<P>
 
 Linux 1.x users might be able to add
-<code>-DHAVE_SHMGET -DUSE_SHMGET_SCOREBOARD</code> to
-the <code>EXTRA_CFLAGS</code> in your <code>Configuration</code>.  This
+<CODE>-DHAVE_SHMGET -DUSE_SHMGET_SCOREBOARD</CODE> to
+the <CODE>EXTRA_CFLAGS</CODE> in your <CODE>Configuration</CODE>.  This
 might work with some 1.x installations, but won't work with all of
-them. (Prior to 1.3b4, <code>HAVE_SHMGET</code> would have sufficed.)<p>
+them. (Prior to 1.3b4, <CODE>HAVE_SHMGET</CODE> would have sufficed.)<P>
 
 SVR4 users should consider adding
-<code>-DHAVE_SHMGET -DUSE_SHMGET_SCOREBOARD</code> to the
-<code>EXTRA_CFLAGS</code> in your <code>Configuration</code>.  This
+<CODE>-DHAVE_SHMGET -DUSE_SHMGET_SCOREBOARD</CODE> to the
+<CODE>EXTRA_CFLAGS</CODE> in your <CODE>Configuration</CODE>.  This
 is believed to work, but we were unable to test it in time for 1.2
-release. (Prior to 1.3b4, <code>HAVE_SHMGET</code> would have sufficed.)<p>
+release. (Prior to 1.3b4, <CODE>HAVE_SHMGET</CODE> would have sufficed.)<P>
 
-<strong>See Also</strong>:
-<a href="../stopping.html">Stopping and Restarting Apache</a></p>
+<STRONG>See Also</STRONG>:
+<A HREF="../stopping.html">Stopping and Restarting Apache</A></P>
 
-<p><hr>
+<P><HR>
 
 <h2><A name="sendbuffersize">SendBufferSize directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt SendBufferSize} directive&gt; -->
-<strong>Syntax:</strong> SendBufferSize <em>bytes</em><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> SendBufferSize <EM>bytes</EM><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The server will set the TCP buffer size to the number of bytes
 specified. Very useful to increase past standard OS defaults on high
 speed high latency (i.e. 100ms or so, such as transcontinental
 fast pipes)
-<p><hr>
+<P><HR>
 
 <h2><A name="serveradmin">ServerAdmin directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ServerAdmin} directive&gt; -->
-<strong>Syntax:</strong> ServerAdmin <em>email-address</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ServerAdmin <EM>email-address</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The ServerAdmin sets the e-mail address that the server includes in any
-error messages it returns to the client.<p>
+error messages it returns to the client.<P>
 
 It may be worth setting up a dedicated address for this, e.g.
-<blockquote><code>ServerAdmin www-admin@foo.bar.com</code></blockquote>
-as users do not always mention that they are talking about the server!<p><hr>
+<BLOCKQUOTE><CODE>ServerAdmin www-admin@foo.bar.com</CODE></BLOCKQUOTE>
+as users do not always mention that they are talking about the server!<P><HR>
 
 <h2><A name="serveralias">ServerAlias directive</A></h2>
 
-<strong>Syntax:</strong> ServerAlias <em>host1 host2 ...</em><br>
-<strong>Context:</strong> virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> ServerAlias is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ServerAlias <EM>host1 host2 ...</EM><BR>
+<STRONG>Context:</STRONG> virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> ServerAlias is only available in Apache
+1.1 and later.<P>
 
 The ServerAlias directive sets the alternate names for a host, for use
 with
-<a href="../vhosts/name-based.html">name-based virtual hosts</a>.
+<A HREF="../vhosts/name-based.html">name-based virtual hosts</A>.
 
-<p><strong>See also:</strong>
-<a href="../vhosts/index.html">Apache Virtual Host documentation</a>
+<P><STRONG>See also:</STRONG>
+<A HREF="../vhosts/index.html">Apache Virtual Host documentation</A>
 
-<hr>
+<HR>
 
 <h2><A name="servername">ServerName directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ServerName} directive&gt; -->
-<strong>Syntax:</strong> ServerName <em>fully-qualified domain name</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ServerName <EM>fully-qualified domain name</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The ServerName directive sets the hostname of the server; this is only
 used when creating redirection URLs. If it is not specified, then the
 server attempts to deduce it from its own IP address; however this may
 not work reliably, or may not return the preferred hostname. For example:
-<blockquote><code>ServerName www.wibble.com</code></blockquote>
+<BLOCKQUOTE><CODE>ServerName www.wibble.com</CODE></BLOCKQUOTE>
 would be used if the canonical (main) name of the actual machine
-were <code>monster.wibble.com</code>.<p>
-<p><strong>See Also</strong>:
-<a href="../dns-caveats.html">DNS Issues</a></p>
-<hr>
+were <CODE>monster.wibble.com</CODE>.<P>
+<P><STRONG>See Also</STRONG>:
+<A HREF="../dns-caveats.html">DNS Issues</A></P>
+<HR>
 
 <h2><A name="serverpath">ServerPath directive</A></h2>
 
-<strong>Syntax:</strong> ServerPath <em>pathname</em><br>
-<strong>Context:</strong> virtual host<br>
-<strong>Status:</strong> core<br>
-<strong>Compatibility:</strong> ServerPath is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ServerPath <EM>pathname</EM><BR>
+<STRONG>Context:</STRONG> virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
+<STRONG>Compatibility:</STRONG> ServerPath is only available in Apache
+1.1 and later.<P>
 
 The ServerPath directive sets the legacy URL pathname for a host, for
-use with <a href="../vhosts/index.html">name-based virtual hosts</a>.
+use with <A HREF="../vhosts/index.html">name-based virtual hosts</A>.
 
-<p><strong>See also:</strong>
-<a href="../vhosts/index.html">Apache Virtual Host documentation</a>
+<P><STRONG>See also:</STRONG>
+<A HREF="../vhosts/index.html">Apache Virtual Host documentation</A>
 
-<hr>
+<HR>
 
 <h2><A name="serverroot">ServerRoot directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ServerRoot} directive&gt; -->
-<strong>Syntax:</strong> ServerRoot <em>directory-filename</em><br>
-<strong>Default:</strong> <code>ServerRoot /usr/local/apache</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ServerRoot <EM>directory-filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ServerRoot /usr/local/apache</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The ServerRoot directive sets the directory in which the server lives.
-Typically it will contain the subdirectories <code>conf/</code> and
-<code>logs/</code>. Relative paths for other configuration files are taken
-as relative to this directory.<p>
+Typically it will contain the subdirectories <CODE>conf/</CODE> and
+<CODE>logs/</CODE>. Relative paths for other configuration files are taken
+as relative to this directory.<P>
 
-See also <a href="../invoking.html">the <code>-d</code> option to httpd</a>.<p>
-See also <a href="../misc/security_tips.html#serverroot">the security tips</a>
-for information on how to properly set permissions on the ServerRoot.<p>
+See also <A HREF="../invoking.html">the <CODE>-d</CODE> option to httpd</A>.<P>
+See also <A HREF="../misc/security_tips.html#serverroot">the security tips</A>
+for information on how to properly set permissions on the ServerRoot.<P>
 
-<hr>
+<HR>
 
 <h2><A name="servertype">ServerType directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt ServerType} directive&gt; -->
-<strong>Syntax:</strong> ServerType <em>type</em><br>
-<strong>Default:</strong> <code>ServerType standalone</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> ServerType <EM>type</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ServerType standalone</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The ServerType directive sets how the server is executed by the system.
-<em>Type</em> is one of
-<dl>
-<dt>inetd
-<dd>The server will be run from the system process inetd; the command to start
-the server is added to <code>/etc/inetd.conf</code>
-<dt>standalone
-<dd>The server will run as a daemon process; the command to start the server
-is added to the system startup scripts. (<code>/etc/rc.local</code> or
-<code>/etc/rc3.d/...</code>.)
-</dl>
+<EM>Type</EM> is one of
+<DL>
+<DT>inetd
+<DD>The server will be run from the system process inetd; the command to start
+the server is added to <CODE>/etc/inetd.conf</CODE>
+<DT>standalone
+<DD>The server will run as a daemon process; the command to start the server
+is added to the system startup scripts. (<CODE>/etc/rc.local</CODE> or
+<CODE>/etc/rc3.d/...</CODE>.)
+</DL>
 
 Inetd is the lesser used of the two options. For each http
 connection received, a new copy of the server is started from scratch;
@@ -1612,56 +1612,56 @@ after the connection is complete, this program exits. There is a high price to
 pay per connection, but for security reasons, some admins prefer this option.
 <FONT COLOR="red">Inetd mode is no longer recommended and does not always
 work properly.  Avoid it if at all possible.</FONT>
-<p>
+<P>
 
 Standalone is the most common setting for ServerType since
 it is far more efficient. The server is started once, and services all
 subsequent connections. If you intend running Apache to serve a busy site,
-standalone will probably be your only option.<p>
+standalone will probably be your only option.<P>
 
 <h2><A name="startservers">StartServers directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt StartServers} directive&gt; -->
-<strong>Syntax:</strong> StartServers <em>number</em><br>
-<strong>Default:</strong> <code>StartServers 5</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> StartServers <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>StartServers 5</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The StartServers directive sets the number of child server processes created
 on startup. As the number of processes is dynamically controlled depending
-on the load, there is usually little reason to adjust this parameter.<p>
+on the load, there is usually little reason to adjust this parameter.<P>
 
-<p>When running with Microsoft Windows, this directive sets the total
+<P>When running with Microsoft Windows, this directive sets the total
    number of child processes running. Since the Windows version of Apache
    is multithreaded, one processes handles all the requests. The rest are
    held in reserve until the main processes dies.
 
 See also <A HREF="#minspareservers">MinSpareServers</A> and
-<A HREF="#maxspareservers">MaxSpareServers</A>.<p><hr>
+<A HREF="#maxspareservers">MaxSpareServers</A>.<P><HR>
 
 <h2><A name="threadsperchild">ThreadsPerChild</A></h2>
-<strong>Syntax:</strong> ThreadsPerChild <em>number</em><br>
-<strong>Default:</strong> <code>ThreadsPerChild 50</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core (Windows)<br>
-<strong>Compatbility:</strong> Available only with Apache 1.3 and later
+<STRONG>Syntax:</STRONG> ThreadsPerChild <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ThreadsPerChild 50</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core (Windows)<BR>
+<STRONG>Compatbility:</STRONG> Available only with Apache 1.3 and later
 with Windows
 
-<p>This directive tells the server how many threads it should use. This
+<P>This directive tells the server how many threads it should use. This
    is the maximum number of connections the server can handle at once; be
    sure and set this number high enough for your site if you get a lot of
    hits.
 
-<p>See also <A HREF="#startservers">StartServers</A> and <A
-   HREF="#maxrequestsperchild">MaxRequestsPerChild</A>.</p>
+<P>See also <A HREF="#startservers">StartServers</A> and <A
+   HREF="#maxrequestsperchild">MaxRequestsPerChild</A>.</P>
 
-<hr>
+<HR>
 
 <h2><A name="timeout">TimeOut directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt TimeOut} directive&gt; -->
-<strong>Syntax:</strong> TimeOut <em>number</em><br>
-<strong>Default:</strong> <code>TimeOut 300</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> TimeOut <EM>number</EM><BR>
+<STRONG>Default:</STRONG> <CODE>TimeOut 300</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The TimeOut directive currently defines the amount of time Apache will
 wait for three things:
@@ -1681,121 +1681,121 @@ situations.  It is not set any lower by default because there may
 still be odd places in the code where the timer is not reset when
 a packet is sent.
 
-<p><hr>
+<P><HR>
 
 <h2><A name="user">User directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt User} directive&gt; -->
-<strong>Syntax:</strong> User <em>unix-userid</em><br>
-<strong>Default:</strong> <code>User #-1</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG> User <EM>unix-userid</EM><BR>
+<STRONG>Default:</STRONG> <CODE>User #-1</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<P>
 
 The User directive sets the userid as which the server will answer requests.
 In order to use this directive, the standalone server must be run initially
-as root. <em>Unix-userid</em> is one of:
-<dl>
-<dt>A username
-<dd>Refers to the given user by name.
-<dt># followed by a user number.
-<dd>Refers to a user by their number.
-</dl>
+as root. <EM>Unix-userid</EM> is one of:
+<DL>
+<DT>A username
+<DD>Refers to the given user by name.
+<DT># followed by a user number.
+<DD>Refers to a user by their number.
+</DL>
 
 The user should have no privileges which result in it being able to access
 files which are not intended to be visible to the outside world, and
 similarly, the user should not be able to execute code which is not
 meant for httpd requests. It is recommended that you set up a new user and
 group specifically for running the server. Some admins use user
-<code>nobody</code>, but this is not always possible or desirable.<p>
+<CODE>nobody</CODE>, but this is not always possible or desirable.<P>
 
 Notes: If you start the server as a non-root user, it will fail to change
 to the lesser privileged user, and will instead continue to run as
 that original user. If you do start the server as root, then it is normal
-for the parent process to remain running as root.<p>
+for the parent process to remain running as root.<P>
 
 Special note: Use of this directive in &lt;VirtualHost&gt; requires a
 properly configured <A HREF="../suexec.html">suEXEC wrapper</A>.
 When used inside a &lt;VirtualHost&gt; in this manner, only the user
 that CGIs are run as is affected.  Non-CGI requests are still processed
-with the user specified in the main User directive.<p>
+with the user specified in the main User directive.<P>
 
 SECURITY: Don't set User (or <A HREF="#group">Group</A>) to
-<code>root</code> unless you know exactly what you are doing, and what the
-dangers are.<p><hr>
+<CODE>root</CODE> unless you know exactly what you are doing, and what the
+dangers are.<P><HR>
 
 <h2><A name="virtualhost">&lt;VirtualHost&gt; directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt VirtualHost} section directive&gt; -->
-<strong>Syntax:</strong> &lt;VirtualHost <em>addr</em>[:<em>port</em>] ...&gt; ...
-&lt;/VirtualHost&gt; <br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core.<br>
-<strong>Compatibility:</strong> Non-IP address-based Virtual Hosting only
-available in Apache 1.1 and later.<br>
-<strong>Compatibility:</strong> Multiple address support only available in
-Apache 1.2 and later.<p>
+<STRONG>Syntax:</STRONG> &lt;VirtualHost <EM>addr</EM>[:<EM>port</EM>] ...&gt; ...
+&lt;/VirtualHost&gt; <BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core.<BR>
+<STRONG>Compatibility:</STRONG> Non-IP address-based Virtual Hosting only
+available in Apache 1.1 and later.<BR>
+<STRONG>Compatibility:</STRONG> Multiple address support only available in
+Apache 1.2 and later.<P>
 
 &lt;VirtualHost&gt; and &lt;/VirtualHost&gt; are used to enclose a group of
 directives which will apply only to a particular virtual host.
 Any directive which is allowed in a virtual host context may be used.
 When the server receives a request for a document on a particular virtual
 host, it uses the configuration directives enclosed in the &lt;VirtualHost&gt;
-section. <em>Addr</em> can be
-<menu>
-<li>The IP address of the virtual host
-<li>A fully qualified domain name for the IP address of the virtual host.
-</menu> Example:
-<blockquote>
-<code>
-&lt;VirtualHost 10.1.2.3&gt; <br>
-ServerAdmin webmaster@host.foo.com <br>
-DocumentRoot /www/docs/host.foo.com <br>
-ServerName host.foo.com <br>
-ErrorLog logs/host.foo.com-error_log <br>
-TransferLog logs/host.foo.com-access_log <br>
+section. <EM>Addr</EM> can be
+<MENU>
+<LI>The IP address of the virtual host
+<LI>A fully qualified domain name for the IP address of the virtual host.
+</MENU> Example:
+<BLOCKQUOTE>
+<CODE>
+&lt;VirtualHost 10.1.2.3&gt; <BR>
+ServerAdmin webmaster@host.foo.com <BR>
+DocumentRoot /www/docs/host.foo.com <BR>
+ServerName host.foo.com <BR>
+ErrorLog logs/host.foo.com-error_log <BR>
+TransferLog logs/host.foo.com-access_log <BR>
 &lt;/VirtualHost&gt;
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
 Each VirtualHost must correspond to a different IP address, different port number or a
 different host name for the server, in the latter case the server
 machine must be configured to accept IP packets for multiple
 addresses. (If the machine does not have multiple network interfaces,
-then this can be accomplished with the <code>ifconfig alias</code>
+then this can be accomplished with the <CODE>ifconfig alias</CODE>
 command (if your OS supports it), or with kernel patches like <A
-HREF="../misc/vif-info.html">VIF</A> (for SunOS(TM) 4.1.x)).<p>
+HREF="../misc/vif-info.html">VIF</A> (for SunOS(TM) 4.1.x)).<P>
 
-The special name <code>_default_</code> can be specified in which case
+The special name <CODE>_default_</CODE> can be specified in which case
 this virtual host will match any IP address that is not explicitly listed
 in another virtual host.  In the absence of any _default_ virtual host
 the "main" server config, consisting of all those definitions outside
-any VirtualHost section, is used when no match occurs.<p>
+any VirtualHost section, is used when no match occurs.<P>
 
-You can specify a <code>:port</code> to change the port that is matched.
+You can specify a <CODE>:port</CODE> to change the port that is matched.
 If unspecified then it defaults to the same port as the most recent
-<code><a href="#port">Port</a></code> statement of the main server.  You
-may also specify <code>:*</code> to match all ports on that address.
-(This is recommended when used with <code>_default_</code>.)<p>
+<CODE><A HREF="#port">Port</A></CODE> statement of the main server.  You
+may also specify <CODE>:*</CODE> to match all ports on that address.
+(This is recommended when used with <CODE>_default_</CODE>.)<P>
 
-<strong>SECURITY</strong>: See the
+<STRONG>SECURITY</STRONG>: See the
 <A HREF="../misc/security_tips.html">security tips</A>
 document for details on why your security could be compromised if
 the directory where logfiles are stored is writable by anyone other
 than the user that starts the server.
 
-<p><strong>NOTE</strong>: The use of &lt;VirtualHost&gt; does
-<strong>not</strong> affect what addresses Apache listens on. You may
+<P><STRONG>NOTE</STRONG>: The use of &lt;VirtualHost&gt; does
+<STRONG>not</STRONG> affect what addresses Apache listens on. You may
 need to ensure that Apache is listening on the correct addresses using
-either <a href="#bindaddress">BindAddress</a> or <a
-href="#listen">Listen</a>.
-
-<p><strong>See also:</strong>
-<a href="../vhosts/index.html">Apache Virtual Host documentation</a><br>
-<strong>See also:</strong>
-<A HREF="../dns-caveats.html">Warnings about DNS and Apache</a><br>
-<strong>See also:</strong>
-<a href="../bind.html">Setting which addresses and ports Apache uses</a><br>
-<strong>See also</strong>: <a href="../sections.html">How Directory,
-Location and Files sections work</a> for an explanation of how these
+either <A HREF="#bindaddress">BindAddress</A> or <A
+HREF="#listen">Listen</A>.
+
+<P><STRONG>See also:</STRONG>
+<A HREF="../vhosts/index.html">Apache Virtual Host documentation</A><BR>
+<STRONG>See also:</STRONG>
+<A HREF="../dns-caveats.html">Warnings about DNS and Apache</A><BR>
+<STRONG>See also:</STRONG>
+<A HREF="../bind.html">Setting which addresses and ports Apache uses</A><BR>
+<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
+Location and Files sections work</A> for an explanation of how these
 different sections are combined when a request is received
-</p>
+</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 17055e28ed218ce3602f9346089507a622ab3be0..b29213e697008a12e200731ca97c2f1cb9155998 100644 (file)
@@ -23,179 +23,179 @@ listed here.  They are described using a consistent format, and there is
 >a dictionary</A>
 of the terms used in their descriptions available.
 </P>
-<ul>
-<li><A HREF="core.html#accessconfig">AccessConfig</A>
-<li><A HREF="core.html#accessfilename">AccessFileName</A>
-<li><A HREF="mod_actions.html#action">Action</A>
-<li><A HREF="mod_autoindex.html#addalt">AddAlt</A>
-<li><A HREF="mod_autoindex.html#addaltbyencoding">AddAltByEncoding</A>
-<li><A HREF="mod_autoindex.html#addaltbytype">AddAltByType</A>
-<li><A HREF="mod_autoindex.html#adddescription">AddDescription</A>
-<li><A HREF="mod_mime.html#addencoding">AddEncoding</A>
-<li><A HREF="mod_mime.html#addhandler">AddHandler</A>
-<li><A HREF="mod_autoindex.html#addicon">AddIcon</A>
-<li><A HREF="mod_autoindex.html#addiconbyencoding">AddIconByEncoding</A>
-<li><A HREF="mod_autoindex.html#addiconbytype">AddIconByType</A>
-<li><A HREF="mod_mime.html#addlanguage">AddLanguage</A>
-<li><A HREF="core.html#addmodule">AddModule</A>
-<li><A HREF="mod_info.html#addmoduleinfo">AddModuleInfo</A>
-<li><A HREF="mod_mime.html#addtype">AddType</A>
-<li><A HREF="mod_log_agent.html#agentlog">AgentLog</A>
-<li><A HREF="mod_alias.html#alias">Alias</A>
-<li><A HREF="mod_alias.html#aliasmatch">AliasMatch</A>
-<li><A HREF="mod_access.html#allow">allow</A>
-<li><A HREF="core.html#allowoverride">AllowOverride</A>
-<li><A HREF="mod_auth_anon.html#anonymous">Anonymous</A>
-<li><A HREF="mod_auth_anon.html#Authoritative">Anonymous_Authoritative</A>
-<li><A HREF="mod_auth_anon.html#LogEmail">Anonymous_LogEmail</A>
-<li><A HREF="mod_auth_anon.html#MustGiveEmail">Anonymous_MustGiveEmail</A>
-<li><A HREF="mod_auth_anon.html#NoUserID">Anonymous_NoUserID</A>
-<li><A HREF="mod_auth_anon.html#VerifyEmail">Anonymous_VerifyEmail</A>
-<li><A HREF="mod_auth.html#authauthoritative">AuthAuthoritative</A>
-<li><A HREF="mod_auth_db.html#authdbauthoritative">AuthDBAuthoritative</A>
-<li><A HREF="mod_auth_db.html#authdbgroupfile">AuthDBGroupFile</A>
-<li><A HREF="mod_auth_dbm.html#authdbmauthoritative">AuthDBMAuthoritative</A>
-<li><A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>
-<li><A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>
-<li><A HREF="mod_auth_db.html#authdbuserfile">AuthDBUserFile</A>
-<li><A HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A>
-<li><A HREF="mod_digest.html#authdigestfile">AuthDigestFile</A>
-<li><A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A>
-<li><A HREF="core.html#authname">AuthName</A>
-<li><A HREF="core.html#authtype">AuthType</A>
-<li><A HREF="mod_auth.html#authuserfile">AuthUserFile</A>
-<li><A HREF="core.html#bindaddress">BindAddress</A>
-<li><A HREF="mod_setenvif.html#BrowserMatch">BrowserMatch</A>
-<li><A HREF="mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</A>
-<li><A HREF="mod_proxy.html#cachedefaultexpire">CacheDefaultExpire</A>
-<li><A HREF="mod_proxy.html#cachedirlength">CacheDirLength</A>
-<li><A HREF="mod_proxy.html#cachedirlevels">CacheDirLevels</A>
-<li><A HREF="mod_proxy.html#cachegcinterval">CacheGcInterval</A>
-<li><A HREF="mod_proxy.html#cachelastmodifiedfactor">CacheLastModifiedFactor</A>
-<li><A HREF="mod_proxy.html#cachemaxexpire">CacheMaxExpire</A>
-<li><A HREF="mod_negotiation.html#cachenegotiateddocs">CacheNegotiatedDocs</A>
-<li><A HREF="mod_proxy.html#cacheroot">CacheRoot</A>
-<li><A HREF="mod_proxy.html#cachesize">CacheSize</A>
-<li><A HREF="mod_speling.html#checkspelling">CheckSpelling</A>
-<li><A HREF="core.html#clearmodulelist">ClearModuleList</A>
-<li><A HREF="core.html#contentdigest">ContentDigest</A>
-<li><A HREF="mod_usertrack.html#cookieexpires">CookieExpires</A>
-<li><A HREF="mod_cookies.html#cookielog">CookieLog</A> (mod_cookies)
-<li><A HREF="mod_log_config.html#cookielog">CookieLog</A> (mod_log_config)
-<li><A HREF="mod_usertrack.html#cookietracking">CookieTracking</A>
-<li><A HREF="core.html#coredumpdirectory">CoreDumpDirectory</A>
-<li><A HREF="mod_log_config.html#customlog">CustomLog</A>
-<li><A HREF="mod_autoindex.html#defaulticon">DefaultIcon</A>
-<li><A HREF="core.html#defaulttype">DefaultType</A>
-<li><A HREF="mod_access.html#deny">deny</A>
-<li><A HREF="core.html#directory">&lt;Directory&gt;</A>
-<li><A HREF="core.html#directorymatch">&lt;DirectoryMatch&gt;</A>
-<li><A HREF="mod_dir.html#directoryindex">DirectoryIndex</A>
-<li><A HREF="core.html#documentroot">DocumentRoot</A>
-<li><A HREF="core.html#errordocument">ErrorDocument</A>
-<li><A HREF="core.html#errorlog">ErrorLog</A>
-<li><A HREF="mod_example.html#example">Example</A>
-<li><A HREF="mod_expires.html#expiresactive">ExpiresActive</A>
-<li><A HREF="mod_expires.html#expiresbytype">ExpiresByType</A>
-<li><A HREF="mod_expires.html#expiresdefault">ExpiresDefault</A>
-<li><A HREF="mod_autoindex.html#fancyindexing">FancyIndexing</A>
-<li><A HREF="core.html#files">&lt;Files&gt;</A>
-<li><A HREF="core.html#filesmatch">&lt;FilesMatch&gt;</A>
-<li><A HREF="mod_mime.html#forcetype">ForceType</A>
-<li><A HREF="core.html#group">Group</A>
-<li><A HREF="mod_headers.html#header">Header</A>
-<li><A HREF="mod_autoindex.html#headername">HeaderName</A>
-<li><A HREF="core.html#hostnamelookups">HostNameLookups</A>
-<li><A HREF="core.html#identitycheck">IdentityCheck</A>
-<li><A HREF="core.html#ifmodule">&lt;IfModule&gt;</A>
-<li><A HREF="mod_imap.html#imapbase">ImapBase</A>
-<li><A HREF="mod_imap.html#imapdefault">ImapDefault</A>
-<li><A HREF="mod_imap.html#imapmenu">ImapMenu</A>
-<li><A HREF="core.html#include">Include</A>
-<li><A HREF="mod_autoindex.html#indexignore">IndexIgnore</A>
-<li><A HREF="mod_autoindex.html#indexoptions">IndexOptions</A>
-<li><A HREF="core.html#keepalive">KeepAlive</A>
-<li><A HREF="core.html#keepalivetimeout">KeepAliveTimeout</A>
-<li><A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>
-<li><A HREF="core.html#limit">&lt;Limit&gt;</A>
-<li><A HREF="core.html#listen">Listen</A>
-<li><A HREF="core.html#listenbacklog">ListenBacklog</A>
-<li><A HREF="mod_dld.html#loadfile">LoadFile</A> (Unix)
-<li><A HREF="mod_dll.html#loadfile">LoadFile</A> (Windows)
-<li><A HREF="mod_dld.html#loadmodule">LoadModule</A> (Unix)
-<li><A HREF="mod_dll.html#loadmodule">LoadModule</A> (Windows)
-<li><A HREF="core.html#location">&lt;Location&gt;</A>
-<li><A HREF="core.html#locationmatch">&lt;LocationMatch&gt;</A>
-<li><A HREF="core.html#lockfile">LockFile</A>
-<li><A HREF="mod_log_config.html#logformat">LogFormat</A>
-<li><A HREF="core.html#maxclients">MaxClients</A>
-<li><A HREF="core.html#maxkeepaliverequests">MaxKeepAliveRequests</A>
-<li><A HREF="core.html#maxrequestsperchild">MaxRequestsPerChild</A>
-<li><A HREF="core.html#maxspareservers">MaxSpareServers</A>
-<li><A HREF="mod_cern_meta.html#metadir">MetaDir</A>
-<li><A HREF="mod_cern_meta.html#metasuffix">MetaSuffix</A>
-<li><A HREF="mod_mime_magic.html#mimemagicfile">MimeMagicFile</A>
-<li><A HREF="core.html#minspareservers">MinSpareServers</A>
-<li><A HREF="mod_proxy.html#nocache">NoCache</A>
-<li><A HREF="core.html#options">Options</A>
-<li><A HREF="mod_access.html#order">order</A>
-<li><A HREF="mod_env.html#passenv">PassEnv</A>
-<li><A HREF="core.html#pidfile">PidFile</A>
-<li><A HREF="core.html#port">Port</A>
-<li><A HREF="mod_proxy.html#proxyblock">ProxyBlock</A>
-<li><A HREF="mod_proxy.html#proxypass">ProxyPass</A>
-<li><A HREF="mod_proxy.html#proxyremote">ProxyRemote</A>
-<li><A HREF="mod_proxy.html#proxyrequests">ProxyRequests</A>
-<li><A HREF="mod_autoindex.html#readmename">ReadmeName</A>
-<li><A HREF="mod_alias.html#redirect">Redirect</A>
-<li><A HREF="mod_alias.html#redirectmatch">RedirectMatch</A>
-<li><A HREF="mod_alias.html#redirectperm">RedirectPermanent</A>
-<li><A HREF="mod_alias.html#redirecttemp">RedirectTemp</A>
-<li><A HREF="mod_log_referer.html#refererignore">RefererIgnore</A>
-<li><A HREF="mod_log_referer.html#refererlog">RefererLog</A>
-<li><A HREF="core.html#require">require</A>
-<li><A HREF="core.html#resourceconfig">ResourceConfig</A>
-<li><A HREF="mod_rewrite.html#RewriteBase">RewriteBase</A>
-<li><A HREF="mod_rewrite.html#RewriteCond">RewriteCond</A>
-<li><A HREF="mod_rewrite.html#RewriteEngine">RewriteEngine</A>
-<li><A HREF="mod_rewrite.html#RewriteLog">RewriteLog</A>
-<li><A HREF="mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</A>
-<li><A HREF="mod_rewrite.html#RewriteMap">RewriteMap</A>
-<li><A HREF="mod_rewrite.html#RewriteOptions">RewriteOptions</A>
-<li><A HREF="mod_rewrite.html#RewriteRule">RewriteRule</A>
-<li><A HREF="core.html#rlimitcpu">RLimitCPU</A>
-<li><A HREF="core.html#rlimitmem">RLimitMEM</A>
-<li><A HREF="core.html#rlimitnproc">RLimitNPROC</A>
-<li><A HREF="core.html#satisfy">Satisfy</A>
-<li><A HREF="core.html#scoreboardfile">ScoreBoardFile</A>
-<li><A HREF="mod_actions.html#script">Script</A>
-<li><A HREF="mod_alias.html#scriptalias">ScriptAlias</A>
-<li><A HREF="mod_alias.html#scriptaliasmatch">ScriptAliasMatch</A>
-<li><A HREF="mod_cgi.html#scriptlog">ScriptLog</A>
-<li><A HREF="mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</A>
-<li><A HREF="mod_cgi.html#scriptloglength">ScriptLogLength</A>
-<li><A HREF="core.html#sendbuffersize">SendBufferSize</A>
-<li><A HREF="core.html#serveradmin">ServerAdmin</A>
-<li><A HREF="core.html#serveralias">ServerAlias</A>
-<li><A HREF="core.html#servername">ServerName</A>
-<li><A HREF="core.html#serverpath">ServerPath</A>
-<li><A HREF="core.html#serverroot">ServerRoot</A>
-<li><A HREF="core.html#servertype">ServerType</A>
-<li><A HREF="mod_env.html#setenv">SetEnv</A>
-<li><A HREF="mod_setenvif.html#setenvif">SetEnvIf</A>
-<li><A HREF="mod_setenvif.html#SetEnvIfNoCase">SetEnvIfNoCase</A>
-<li><A HREF="mod_mime.html#sethandler">SetHandler</A>
-<li><A HREF="core.html#startservers">StartServers</A>
-<li><A HREF="core.html#threadsperchild">ThreadsPerChild</A>
-<li><A HREF="core.html#timeout">TimeOut</A>
-<li><A HREF="mod_log_config.html#transferlog">TransferLog</A>
-<li><A HREF="mod_mime.html#typesconfig">TypesConfig</A>
-<li><A HREF="mod_env.html#unsetenv">UnsetEnv</A>
-<li><A HREF="core.html#user">User</A>
-<li><A HREF="mod_userdir.html#userdir">UserDir</A>
-<li><A HREF="core.html#virtualhost">&lt;VirtualHost&gt;</A>
-<li><A HREF="mod_include.html#xbithack">XBitHack</A>
-</ul>
+<UL>
+<LI><A HREF="core.html#accessconfig">AccessConfig</A>
+<LI><A HREF="core.html#accessfilename">AccessFileName</A>
+<LI><A HREF="mod_actions.html#action">Action</A>
+<LI><A HREF="mod_autoindex.html#addalt">AddAlt</A>
+<LI><A HREF="mod_autoindex.html#addaltbyencoding">AddAltByEncoding</A>
+<LI><A HREF="mod_autoindex.html#addaltbytype">AddAltByType</A>
+<LI><A HREF="mod_autoindex.html#adddescription">AddDescription</A>
+<LI><A HREF="mod_mime.html#addencoding">AddEncoding</A>
+<LI><A HREF="mod_mime.html#addhandler">AddHandler</A>
+<LI><A HREF="mod_autoindex.html#addicon">AddIcon</A>
+<LI><A HREF="mod_autoindex.html#addiconbyencoding">AddIconByEncoding</A>
+<LI><A HREF="mod_autoindex.html#addiconbytype">AddIconByType</A>
+<LI><A HREF="mod_mime.html#addlanguage">AddLanguage</A>
+<LI><A HREF="core.html#addmodule">AddModule</A>
+<LI><A HREF="mod_info.html#addmoduleinfo">AddModuleInfo</A>
+<LI><A HREF="mod_mime.html#addtype">AddType</A>
+<LI><A HREF="mod_log_agent.html#agentlog">AgentLog</A>
+<LI><A HREF="mod_alias.html#alias">Alias</A>
+<LI><A HREF="mod_alias.html#aliasmatch">AliasMatch</A>
+<LI><A HREF="mod_access.html#allow">allow</A>
+<LI><A HREF="core.html#allowoverride">AllowOverride</A>
+<LI><A HREF="mod_auth_anon.html#anonymous">Anonymous</A>
+<LI><A HREF="mod_auth_anon.html#Authoritative">Anonymous_Authoritative</A>
+<LI><A HREF="mod_auth_anon.html#LogEmail">Anonymous_LogEmail</A>
+<LI><A HREF="mod_auth_anon.html#MustGiveEmail">Anonymous_MustGiveEmail</A>
+<LI><A HREF="mod_auth_anon.html#NoUserID">Anonymous_NoUserID</A>
+<LI><A HREF="mod_auth_anon.html#VerifyEmail">Anonymous_VerifyEmail</A>
+<LI><A HREF="mod_auth.html#authauthoritative">AuthAuthoritative</A>
+<LI><A HREF="mod_auth_db.html#authdbauthoritative">AuthDBAuthoritative</A>
+<LI><A HREF="mod_auth_db.html#authdbgroupfile">AuthDBGroupFile</A>
+<LI><A HREF="mod_auth_dbm.html#authdbmauthoritative">AuthDBMAuthoritative</A>
+<LI><A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>
+<LI><A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>
+<LI><A HREF="mod_auth_db.html#authdbuserfile">AuthDBUserFile</A>
+<LI><A HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A>
+<LI><A HREF="mod_digest.html#authdigestfile">AuthDigestFile</A>
+<LI><A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A>
+<LI><A HREF="core.html#authname">AuthName</A>
+<LI><A HREF="core.html#authtype">AuthType</A>
+<LI><A HREF="mod_auth.html#authuserfile">AuthUserFile</A>
+<LI><A HREF="core.html#bindaddress">BindAddress</A>
+<LI><A HREF="mod_setenvif.html#BrowserMatch">BrowserMatch</A>
+<LI><A HREF="mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</A>
+<LI><A HREF="mod_proxy.html#cachedefaultexpire">CacheDefaultExpire</A>
+<LI><A HREF="mod_proxy.html#cachedirlength">CacheDirLength</A>
+<LI><A HREF="mod_proxy.html#cachedirlevels">CacheDirLevels</A>
+<LI><A HREF="mod_proxy.html#cachegcinterval">CacheGcInterval</A>
+<LI><A HREF="mod_proxy.html#cachelastmodifiedfactor">CacheLastModifiedFactor</A>
+<LI><A HREF="mod_proxy.html#cachemaxexpire">CacheMaxExpire</A>
+<LI><A HREF="mod_negotiation.html#cachenegotiateddocs">CacheNegotiatedDocs</A>
+<LI><A HREF="mod_proxy.html#cacheroot">CacheRoot</A>
+<LI><A HREF="mod_proxy.html#cachesize">CacheSize</A>
+<LI><A HREF="mod_speling.html#checkspelling">CheckSpelling</A>
+<LI><A HREF="core.html#clearmodulelist">ClearModuleList</A>
+<LI><A HREF="core.html#contentdigest">ContentDigest</A>
+<LI><A HREF="mod_usertrack.html#cookieexpires">CookieExpires</A>
+<LI><A HREF="mod_cookies.html#cookielog">CookieLog</A> (mod_cookies)
+<LI><A HREF="mod_log_config.html#cookielog">CookieLog</A> (mod_log_config)
+<LI><A HREF="mod_usertrack.html#cookietracking">CookieTracking</A>
+<LI><A HREF="core.html#coredumpdirectory">CoreDumpDirectory</A>
+<LI><A HREF="mod_log_config.html#customlog">CustomLog</A>
+<LI><A HREF="mod_autoindex.html#defaulticon">DefaultIcon</A>
+<LI><A HREF="core.html#defaulttype">DefaultType</A>
+<LI><A HREF="mod_access.html#deny">deny</A>
+<LI><A HREF="core.html#directory">&lt;Directory&gt;</A>
+<LI><A HREF="core.html#directorymatch">&lt;DirectoryMatch&gt;</A>
+<LI><A HREF="mod_dir.html#directoryindex">DirectoryIndex</A>
+<LI><A HREF="core.html#documentroot">DocumentRoot</A>
+<LI><A HREF="core.html#errordocument">ErrorDocument</A>
+<LI><A HREF="core.html#errorlog">ErrorLog</A>
+<LI><A HREF="mod_example.html#example">Example</A>
+<LI><A HREF="mod_expires.html#expiresactive">ExpiresActive</A>
+<LI><A HREF="mod_expires.html#expiresbytype">ExpiresByType</A>
+<LI><A HREF="mod_expires.html#expiresdefault">ExpiresDefault</A>
+<LI><A HREF="mod_autoindex.html#fancyindexing">FancyIndexing</A>
+<LI><A HREF="core.html#files">&lt;Files&gt;</A>
+<LI><A HREF="core.html#filesmatch">&lt;FilesMatch&gt;</A>
+<LI><A HREF="mod_mime.html#forcetype">ForceType</A>
+<LI><A HREF="core.html#group">Group</A>
+<LI><A HREF="mod_headers.html#header">Header</A>
+<LI><A HREF="mod_autoindex.html#headername">HeaderName</A>
+<LI><A HREF="core.html#hostnamelookups">HostNameLookups</A>
+<LI><A HREF="core.html#identitycheck">IdentityCheck</A>
+<LI><A HREF="core.html#ifmodule">&lt;IfModule&gt;</A>
+<LI><A HREF="mod_imap.html#imapbase">ImapBase</A>
+<LI><A HREF="mod_imap.html#imapdefault">ImapDefault</A>
+<LI><A HREF="mod_imap.html#imapmenu">ImapMenu</A>
+<LI><A HREF="core.html#include">Include</A>
+<LI><A HREF="mod_autoindex.html#indexignore">IndexIgnore</A>
+<LI><A HREF="mod_autoindex.html#indexoptions">IndexOptions</A>
+<LI><A HREF="core.html#keepalive">KeepAlive</A>
+<LI><A HREF="core.html#keepalivetimeout">KeepAliveTimeout</A>
+<LI><A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>
+<LI><A HREF="core.html#limit">&lt;Limit&gt;</A>
+<LI><A HREF="core.html#listen">Listen</A>
+<LI><A HREF="core.html#listenbacklog">ListenBacklog</A>
+<LI><A HREF="mod_dld.html#loadfile">LoadFile</A> (Unix)
+<LI><A HREF="mod_dll.html#loadfile">LoadFile</A> (Windows)
+<LI><A HREF="mod_dld.html#loadmodule">LoadModule</A> (Unix)
+<LI><A HREF="mod_dll.html#loadmodule">LoadModule</A> (Windows)
+<LI><A HREF="core.html#location">&lt;Location&gt;</A>
+<LI><A HREF="core.html#locationmatch">&lt;LocationMatch&gt;</A>
+<LI><A HREF="core.html#lockfile">LockFile</A>
+<LI><A HREF="mod_log_config.html#logformat">LogFormat</A>
+<LI><A HREF="core.html#maxclients">MaxClients</A>
+<LI><A HREF="core.html#maxkeepaliverequests">MaxKeepAliveRequests</A>
+<LI><A HREF="core.html#maxrequestsperchild">MaxRequestsPerChild</A>
+<LI><A HREF="core.html#maxspareservers">MaxSpareServers</A>
+<LI><A HREF="mod_cern_meta.html#metadir">MetaDir</A>
+<LI><A HREF="mod_cern_meta.html#metasuffix">MetaSuffix</A>
+<LI><A HREF="mod_mime_magic.html#mimemagicfile">MimeMagicFile</A>
+<LI><A HREF="core.html#minspareservers">MinSpareServers</A>
+<LI><A HREF="mod_proxy.html#nocache">NoCache</A>
+<LI><A HREF="core.html#options">Options</A>
+<LI><A HREF="mod_access.html#order">order</A>
+<LI><A HREF="mod_env.html#passenv">PassEnv</A>
+<LI><A HREF="core.html#pidfile">PidFile</A>
+<LI><A HREF="core.html#port">Port</A>
+<LI><A HREF="mod_proxy.html#proxyblock">ProxyBlock</A>
+<LI><A HREF="mod_proxy.html#proxypass">ProxyPass</A>
+<LI><A HREF="mod_proxy.html#proxyremote">ProxyRemote</A>
+<LI><A HREF="mod_proxy.html#proxyrequests">ProxyRequests</A>
+<LI><A HREF="mod_autoindex.html#readmename">ReadmeName</A>
+<LI><A HREF="mod_alias.html#redirect">Redirect</A>
+<LI><A HREF="mod_alias.html#redirectmatch">RedirectMatch</A>
+<LI><A HREF="mod_alias.html#redirectperm">RedirectPermanent</A>
+<LI><A HREF="mod_alias.html#redirecttemp">RedirectTemp</A>
+<LI><A HREF="mod_log_referer.html#refererignore">RefererIgnore</A>
+<LI><A HREF="mod_log_referer.html#refererlog">RefererLog</A>
+<LI><A HREF="core.html#require">require</A>
+<LI><A HREF="core.html#resourceconfig">ResourceConfig</A>
+<LI><A HREF="mod_rewrite.html#RewriteBase">RewriteBase</A>
+<LI><A HREF="mod_rewrite.html#RewriteCond">RewriteCond</A>
+<LI><A HREF="mod_rewrite.html#RewriteEngine">RewriteEngine</A>
+<LI><A HREF="mod_rewrite.html#RewriteLog">RewriteLog</A>
+<LI><A HREF="mod_rewrite.html#RewriteLogLevel">RewriteLogLevel</A>
+<LI><A HREF="mod_rewrite.html#RewriteMap">RewriteMap</A>
+<LI><A HREF="mod_rewrite.html#RewriteOptions">RewriteOptions</A>
+<LI><A HREF="mod_rewrite.html#RewriteRule">RewriteRule</A>
+<LI><A HREF="core.html#rlimitcpu">RLimitCPU</A>
+<LI><A HREF="core.html#rlimitmem">RLimitMEM</A>
+<LI><A HREF="core.html#rlimitnproc">RLimitNPROC</A>
+<LI><A HREF="core.html#satisfy">Satisfy</A>
+<LI><A HREF="core.html#scoreboardfile">ScoreBoardFile</A>
+<LI><A HREF="mod_actions.html#script">Script</A>
+<LI><A HREF="mod_alias.html#scriptalias">ScriptAlias</A>
+<LI><A HREF="mod_alias.html#scriptaliasmatch">ScriptAliasMatch</A>
+<LI><A HREF="mod_cgi.html#scriptlog">ScriptLog</A>
+<LI><A HREF="mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</A>
+<LI><A HREF="mod_cgi.html#scriptloglength">ScriptLogLength</A>
+<LI><A HREF="core.html#sendbuffersize">SendBufferSize</A>
+<LI><A HREF="core.html#serveradmin">ServerAdmin</A>
+<LI><A HREF="core.html#serveralias">ServerAlias</A>
+<LI><A HREF="core.html#servername">ServerName</A>
+<LI><A HREF="core.html#serverpath">ServerPath</A>
+<LI><A HREF="core.html#serverroot">ServerRoot</A>
+<LI><A HREF="core.html#servertype">ServerType</A>
+<LI><A HREF="mod_env.html#setenv">SetEnv</A>
+<LI><A HREF="mod_setenvif.html#setenvif">SetEnvIf</A>
+<LI><A HREF="mod_setenvif.html#SetEnvIfNoCase">SetEnvIfNoCase</A>
+<LI><A HREF="mod_mime.html#sethandler">SetHandler</A>
+<LI><A HREF="core.html#startservers">StartServers</A>
+<LI><A HREF="core.html#threadsperchild">ThreadsPerChild</A>
+<LI><A HREF="core.html#timeout">TimeOut</A>
+<LI><A HREF="mod_log_config.html#transferlog">TransferLog</A>
+<LI><A HREF="mod_mime.html#typesconfig">TypesConfig</A>
+<LI><A HREF="mod_env.html#unsetenv">UnsetEnv</A>
+<LI><A HREF="core.html#user">User</A>
+<LI><A HREF="mod_userdir.html#userdir">UserDir</A>
+<LI><A HREF="core.html#virtualhost">&lt;VirtualHost&gt;</A>
+<LI><A HREF="mod_include.html#xbithack">XBitHack</A>
+</UL>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 426e7758f2692c30fa2b4b7831cd926cd8b2dd08..6ac99dba3a485a3b850d197e3179929b95a8e7a7 100644 (file)
@@ -13,7 +13,7 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache modules</h1>
+<H1 ALIGN="CENTER">Apache modules</H1>
 
 <P>
 Below is a list of all of the modules that come as part of the
@@ -23,93 +23,93 @@ Apache distribution.  See also the complete alphabetical list of
 >all Apache directives</A>.
 </P>
 
-<dl>
-<dt><A HREF="core.html">Core</A>
-<dd>Core Apache features.
-<dt><A HREF="mod_access.html">mod_access</A>
-<dd>Host based access control.
-<dt><A HREF="mod_actions.html">mod_actions</A> Apache 1.1 and later.
-<dd>Filetype/method-based script execution
-<dt><A HREF="mod_alias.html">mod_alias</A>
-<dd>Aliases and redirects.
-<dt><A HREF="mod_asis.html">mod_asis</A>
-<dd>The .asis file handler.
-<dt><A HREF="mod_auth.html">mod_auth</A>
-<dd>User authentication using text files.
-<dt><A HREF="mod_auth_anon.html">mod_auth_anon</A>
-<dd>Anonymous user authentication, FTP-style.
-<dt><A HREF="mod_auth_db.html">mod_auth_db</A>
-<dd>User authentication using Berkeley DB files.
-<dt><A HREF="mod_auth_dbm.html">mod_auth_dbm</A>
-<dd>User authentication using DBM files.
-<dt><A HREF="mod_autoindex.html">mod_autoindex</A>
-<dd>Automatic directory listings.
-<dt><A HREF="mod_browser.html">mod_browser</A> Apache 1.2.* only
-<dd>Set environment variables based on User-Agent strings. Replaced by 
+<DL>
+<DT><A HREF="core.html">Core</A>
+<DD>Core Apache features.
+<DT><A HREF="mod_access.html">mod_access</A>
+<DD>Host based access control.
+<DT><A HREF="mod_actions.html">mod_actions</A> Apache 1.1 and later.
+<DD>Filetype/method-based script execution
+<DT><A HREF="mod_alias.html">mod_alias</A>
+<DD>Aliases and redirects.
+<DT><A HREF="mod_asis.html">mod_asis</A>
+<DD>The .asis file handler.
+<DT><A HREF="mod_auth.html">mod_auth</A>
+<DD>User authentication using text files.
+<DT><A HREF="mod_auth_anon.html">mod_auth_anon</A>
+<DD>Anonymous user authentication, FTP-style.
+<DT><A HREF="mod_auth_db.html">mod_auth_db</A>
+<DD>User authentication using Berkeley DB files.
+<DT><A HREF="mod_auth_dbm.html">mod_auth_dbm</A>
+<DD>User authentication using DBM files.
+<DT><A HREF="mod_autoindex.html">mod_autoindex</A>
+<DD>Automatic directory listings.
+<DT><A HREF="mod_browser.html">mod_browser</A> Apache 1.2.* only
+<DD>Set environment variables based on User-Agent strings. Replaced by 
  mod_setenvif in Apache 1.3 and up
-<dt><A HREF="mod_cern_meta.html">mod_cern_meta</a>
-<dd>Support for HTTP header metafiles.
-<dt><A HREF="mod_cgi.html">mod_cgi</A>
-<dd>Invoking CGI scripts.
-<dt><A HREF="mod_cookies.html">mod_cookies</A> up to Apache 1.1.1
-<dd>Support for Netscape-like cookies.  Replaced in Apache 1.2 by
+<DT><A HREF="mod_cern_meta.html">mod_cern_meta</A>
+<DD>Support for HTTP header metafiles.
+<DT><A HREF="mod_cgi.html">mod_cgi</A>
+<DD>Invoking CGI scripts.
+<DT><A HREF="mod_cookies.html">mod_cookies</A> up to Apache 1.1.1
+<DD>Support for Netscape-like cookies.  Replaced in Apache 1.2 by
 mod_usertrack
-<dt><A HREF="mod_digest.html">mod_digest</A>
-<dd>MD5 authentication
-<dt><A HREF="mod_dir.html">mod_dir</A>
-<dd>Basic directory handling.
-<dt><A HREF="mod_dld.html">mod_dld</A>
-<dd>Start-time linking with the GNU libdld.
-<dt><A HREF="mod_dll.html">mod_dll</A>
-<dd>Start-time module linking with Win32 DLLs.
-<dt><A HREF="mod_env.html">mod_env</A>
-<dd>Passing of environments to CGI scripts
-<dt><A HREF="mod_example.html">mod_example</A> Apache 1.2 and up
-<dd>Demonstrates Apache API
-<dt><A HREF="mod_expires.html">mod_expires</A> Apache 1.2 and up
-<dd>Apply Expires: headers to resources
-<dt><A HREF="mod_headers.html">mod_headers</A> Apache 1.2 and up
-<dd>Add arbitrary HTTP headers to resources
-<dt><A HREF="mod_imap.html">mod_imap</A>
-<dd>The imagemap file handler.
-<dt><A HREF="mod_include.html">mod_include</A>
-<dd>Server-parsed documents.
-<dt><A HREF="mod_info.html">mod_info</a>
-<dd>Server configuration information
-<dt><A HREF="mod_isapi.html">mod_isapi</a>
-<dd>Windows ISAPI Extension support
-<dt><A HREF="mod_log_agent.html">mod_log_agent</A>
-<dd>Logging of User Agents.
-<dt><A HREF="mod_log_common.html">mod_log_common</A> up to Apache 1.1.1
-<dd>Standard logging in the Common Logfile Format.  Replaced by the
+<DT><A HREF="mod_digest.html">mod_digest</A>
+<DD>MD5 authentication
+<DT><A HREF="mod_dir.html">mod_dir</A>
+<DD>Basic directory handling.
+<DT><A HREF="mod_dld.html">mod_dld</A>
+<DD>Start-time linking with the GNU libdld.
+<DT><A HREF="mod_dll.html">mod_dll</A>
+<DD>Start-time module linking with Win32 DLLs.
+<DT><A HREF="mod_env.html">mod_env</A>
+<DD>Passing of environments to CGI scripts
+<DT><A HREF="mod_example.html">mod_example</A> Apache 1.2 and up
+<DD>Demonstrates Apache API
+<DT><A HREF="mod_expires.html">mod_expires</A> Apache 1.2 and up
+<DD>Apply Expires: headers to resources
+<DT><A HREF="mod_headers.html">mod_headers</A> Apache 1.2 and up
+<DD>Add arbitrary HTTP headers to resources
+<DT><A HREF="mod_imap.html">mod_imap</A>
+<DD>The imagemap file handler.
+<DT><A HREF="mod_include.html">mod_include</A>
+<DD>Server-parsed documents.
+<DT><A HREF="mod_info.html">mod_info</A>
+<DD>Server configuration information
+<DT><A HREF="mod_isapi.html">mod_isapi</A>
+<DD>Windows ISAPI Extension support
+<DT><A HREF="mod_log_agent.html">mod_log_agent</A>
+<DD>Logging of User Agents.
+<DT><A HREF="mod_log_common.html">mod_log_common</A> up to Apache 1.1.1
+<DD>Standard logging in the Common Logfile Format.  Replaced by the
 mod_log_config module in Apache 1.2 and up
-<dt><A HREF="mod_log_config.html">mod_log_config</A>
-<dd>User-configurable logging replacement for mod_log_common.
-<dt><A HREF="mod_log_referer.html">mod_log_referer</A>
-<dd>Logging of document references.
-<dt><A HREF="mod_mime.html">mod_mime</A>
-<dd>Determining document types using file extensions.
-<dt><A HREF="mod_mime_magic.html">mod_mime_magic</A>
-<dd>Determining document types using "magic numbers".
-<dt><A HREF="mod_negotiation.html">mod_negotiation</A>
-<dd>Content negotiation.
-<dt><A HREF="mod_proxy.html">mod_proxy</A>
-<dd>Caching proxy abilities
-<dt><A HREF="mod_rewrite.html">mod_rewrite</a> Apache 1.2 and up
-<dd>Powerful URI-to-filename mapping using regular expressions
-<dt><A HREF="mod_setenvif.html">mod_setenvif</a> Apache 1.3 and up
-<dd>Set environment variables based on client information
-<dt><A HREF="mod_speling.html">mod_speling</a> Apache 1.3 and up
-<dd>Automatically correct minor typos in URLs
-<dt><A HREF="mod_status.html">mod_status</a>
-<dd>Server status display
-<dt><A HREF="mod_userdir.html">mod_userdir</A>
-<dd>User home directories.
-<dt><A HREF="mod_unique_id.html">mod_unique_id</A> Apache 1.3 and up
-<dd>Generate unique request identifier for every request
-<dt><A HREF="mod_usertrack.html">mod_usertrack</A> Apache 1.2 and up
-<dd>User tracking using Cookies (replacement for mod_cookies.c)
-</dl>
+<DT><A HREF="mod_log_config.html">mod_log_config</A>
+<DD>User-configurable logging replacement for mod_log_common.
+<DT><A HREF="mod_log_referer.html">mod_log_referer</A>
+<DD>Logging of document references.
+<DT><A HREF="mod_mime.html">mod_mime</A>
+<DD>Determining document types using file extensions.
+<DT><A HREF="mod_mime_magic.html">mod_mime_magic</A>
+<DD>Determining document types using "magic numbers".
+<DT><A HREF="mod_negotiation.html">mod_negotiation</A>
+<DD>Content negotiation.
+<DT><A HREF="mod_proxy.html">mod_proxy</A>
+<DD>Caching proxy abilities
+<DT><A HREF="mod_rewrite.html">mod_rewrite</A> Apache 1.2 and up
+<DD>Powerful URI-to-filename mapping using regular expressions
+<DT><A HREF="mod_setenvif.html">mod_setenvif</A> Apache 1.3 and up
+<DD>Set environment variables based on client information
+<DT><A HREF="mod_speling.html">mod_speling</A> Apache 1.3 and up
+<DD>Automatically correct minor typos in URLs
+<DT><A HREF="mod_status.html">mod_status</A>
+<DD>Server status display
+<DT><A HREF="mod_userdir.html">mod_userdir</A>
+<DD>User home directories.
+<DT><A HREF="mod_unique_id.html">mod_unique_id</A> Apache 1.3 and up
+<DD>Generate unique request identifier for every request
+<DT><A HREF="mod_usertrack.html">mod_usertrack</A> Apache 1.2 and up
+<DD>User tracking using Cookies (replacement for mod_cookies.c)
+</DL>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 4e9bcf460699315ab96959582222acd23dc39274..50a178582720d79e85a438ae464932cdddda90a3 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Module mod_access</h1>
+<H1 ALIGN="CENTER">Module mod_access</H1>
 <P>
-This module is contained in the <code>mod_access.c</code> file, and
+This module is contained in the <CODE>mod_access.c</CODE> file, and
 is compiled in by default. It provides access control based on client
 hostname or IP address.
 </P>
 
 <UL>
-<li><A HREF="#allow">allow</A>
-<li><A HREF="#allowfromenv">allow from env=</A>
-<li><A HREF="#deny">deny</A>
-<li><A HREF="#denyfromenv">deny from env=</A>
-<li><A HREF="#order">order</A>
+<LI><A HREF="#allow">allow</A>
+<LI><A HREF="#allowfromenv">allow from env=</A>
+<LI><A HREF="#deny">deny</A>
+<LI><A HREF="#denyfromenv">deny from env=</A>
+<LI><A HREF="#order">order</A>
 </UL>
-<hr>
+<HR>
 
 
 <h2><A name="allow">allow directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt allow} directive&gt; -->
-<strong>Syntax:</strong> allow from <em>host host ...</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> Limit<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_access
-</p>
+<STRONG>Syntax:</STRONG> allow from <EM>host host ...</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> Limit<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_access
+</P>
 <P>
 The allow directive affects which hosts can access a given directory.
-<em>Host</em> is one of the following:
-</P>
-<dl>
-<dt><code>all</code>
-<dd>All hosts are allowed access
-<dt>A (partial) domain-name
-<dd>Hosts whose names match, or end in, this string are allowed access.
-<dt>A full IP address
-<dd>An IP address of a host allowed access
-<dt>A partial IP address
-<dd>The first 1 to 3 bytes of an IP address, for subnet restriction.
-<dt>A network/netmask pair (<b>Apache 1.3 and later</b>)
-<dd>A network a.b.c.d, and a netmask w.x.y.z.  For more fine-grained subnet
+<EM>Host</EM> is one of the following:
+</P>
+<DL>
+<DT><CODE>all</CODE>
+<DD>All hosts are allowed access
+<DT>A (partial) domain-name
+<DD>Hosts whose names match, or end in, this string are allowed access.
+<DT>A full IP address
+<DD>An IP address of a host allowed access
+<DT>A partial IP address
+<DD>The first 1 to 3 bytes of an IP address, for subnet restriction.
+<DT>A network/netmask pair (<STRONG>Apache 1.3 and later</STRONG>)
+<DD>A network a.b.c.d, and a netmask w.x.y.z.  For more fine-grained subnet
     restriction.  (i.e. 10.1.0.0/255.255.0.0)
-<dt>A network/nnn CIDR specification (<b>Apache 1.3 and later</b>)
-<dd>Similar to the previous case, except the netmask consists of nnn 
+<DT>A network/nnn CIDR specification (<STRONG>Apache 1.3 and later</STRONG>)
+<DD>Similar to the previous case, except the netmask consists of nnn 
     high-order 1 bits.  (i.e. 10.1.0.0/16 is the same as 10.1.0.0/255.255.0.0)
-</dl>
+</DL>
 <P>
 Example:
 </P>
-<blockquote><code>allow from .ncsa.uiuc.edu</code></blockquote>
+<BLOCKQUOTE><CODE>allow from .ncsa.uiuc.edu</CODE></BLOCKQUOTE>
 <P>
 All hosts in the specified domain are allowed access.
-</p>
+</P>
 <P>
-Note that this compares whole components; <code>bar.edu</code>
-would not match <code>foobar.edu</code>.
+Note that this compares whole components; <CODE>bar.edu</CODE>
+would not match <CODE>foobar.edu</CODE>.
 </P>
 <P>
 See also <A HREF="#deny">deny</A>, <A HREF="#order">order</A>, and
-<a href="mod_browser.html#browsermatch">BrowserMatch</a>.
-</p>
+<A HREF="mod_browser.html#browsermatch">BrowserMatch</A>.
+</P>
 
 <P>
-<a name="allowfromenv"><strong>Syntax:</strong> allow from env=<em>variablename</em></a><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> Limit<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_access<br>
-<strong>Compatibility:</strong> Apache 1.2 and above
-</p>
+<A name="allowfromenv"><STRONG>Syntax:</STRONG> allow from env=<EM>variablename</EM></A><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> Limit<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_access<BR>
+<STRONG>Compatibility:</STRONG> Apache 1.2 and above
+</P>
 <P>
 The allow from env directive controls access to a directory by the
 existence (or non-existence) of an environment variable.
@@ -91,74 +91,74 @@ existence (or non-existence) of an environment variable.
 <P>
 Example:
 </P>
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 BrowserMatch ^KnockKnock/2.0 let_me_in
 &lt;Directory /docroot&gt;
     order deny,allow
     deny from all
     allow from env=let_me_in
 &lt;/Directory&gt;
-</pre></blockquote>
-In this case browsers with the user-agent string <tt>KnockKnock/2.0</tt> will
+</PRE></BLOCKQUOTE>
+In this case browsers with the user-agent string <TT>KnockKnock/2.0</TT> will
 be allowed access, and all others will be denied.
 <P>
 See also <A HREF="#denyfromenv">deny from env</A>
 and <A HREF="#order">order</A>.
-</p>
-<hr>
+</P>
+<HR>
 
 <h2><A name="deny">deny directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt deny} directive&gt; -->
-<strong>Syntax:</strong> deny from <em>host host ...</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> Limit<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_access
-</p>
+<STRONG>Syntax:</STRONG> deny from <EM>host host ...</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> Limit<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_access
+</P>
 <P>
 The deny directive affects which hosts can access a given directory.
-<em>Host</em> is one of the following:
-</P>
-<dl>
-<dt><code>all</code>
-<dd>all hosts are denied access
-<dt>A (partial) domain-name
-<dd>host whose name is, or ends in, this string are denied access.
-<dt>A full IP address
-<dd>An IP address of a host denied access
-<dt>A partial IP address
-<dd>The first 1 to 3 bytes of an IP address, for subnet restriction.
-<dt>A network/netmask pair (<b>Apache 1.3 and later</b>)
-<dd>A network a.b.c.d, and a netmask w.x.y.z.  For more fine-grained subnet
+<EM>Host</EM> is one of the following:
+</P>
+<DL>
+<DT><CODE>all</CODE>
+<DD>all hosts are denied access
+<DT>A (partial) domain-name
+<DD>host whose name is, or ends in, this string are denied access.
+<DT>A full IP address
+<DD>An IP address of a host denied access
+<DT>A partial IP address
+<DD>The first 1 to 3 bytes of an IP address, for subnet restriction.
+<DT>A network/netmask pair (<STRONG>Apache 1.3 and later</STRONG>)
+<DD>A network a.b.c.d, and a netmask w.x.y.z.  For more fine-grained subnet
     restriction.  (i.e. 10.1.0.0/255.255.0.0)
-<dt>A network/nnn CIDR specification (<b>Apache 1.3 and later</b>)
-<dd>Similar to the previous case, except the netmask consists of nnn 
+<DT>A network/nnn CIDR specification (<STRONG>Apache 1.3 and later</STRONG>)
+<DD>Similar to the previous case, except the netmask consists of nnn 
     high-order 1 bits.  (i.e. 10.1.0.0/16 is the same as 10.1.0.0/255.255.0.0)
-</dl>
+</DL>
 <P>
 Example:
 </P>
-<blockquote><code>deny from 16</code></blockquote>
+<BLOCKQUOTE><CODE>deny from 16</CODE></BLOCKQUOTE>
 <P>
 All hosts in the specified network are denied access.
-</p>
+</P>
 <P>
-Note that this compares whole components; <code>bar.edu</code>
-would not match <code>foobar.edu</code>.
-</p>
+Note that this compares whole components; <CODE>bar.edu</CODE>
+would not match <CODE>foobar.edu</CODE>.
+</P>
 <P>
 See also <A HREF="#allow">allow</A> and <A HREF="#order">order</A>.
-</p>
+</P>
 
 <P>
-<a name="denyfromenv"><strong>Syntax:</strong> deny from env=<em>variablename</em></a><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> Limit<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_access<br>
-<strong>Compatibility:</strong> Apache 1.2 and above
-</p>
+<A name="denyfromenv"><STRONG>Syntax:</STRONG> deny from env=<EM>variablename</EM></A><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> Limit<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_access<BR>
+<STRONG>Compatibility:</STRONG> Apache 1.2 and above
+</P>
 <P>
 The deny from env directive controls access to a directory by the
 existence (or non-existence) of an environment variable.
@@ -166,61 +166,61 @@ existence (or non-existence) of an environment variable.
 <P>
 Example:
 </P>
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 BrowserMatch ^BadRobot/0.9 go_away
 &lt;Directory /docroot&gt;
     order allow,deny
     allow from all
     deny from env=go_away
 &lt;/Directory&gt;
-</pre></blockquote>
-In this case browsers with the user-agent string <tt>BadRobot/0.9</tt> will
+</PRE></BLOCKQUOTE>
+In this case browsers with the user-agent string <TT>BadRobot/0.9</TT> will
 be denied access, and all others will be allowed.
 
 <P>
 See also <A HREF="#allowfromenv">allow from env</A>
 and <A HREF="#order">order</A>.
-</p>
-<hr>
+</P>
+<HR>
 
 <h2><A name="order">order directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt order} directive&gt; -->
-<strong>Syntax:</strong> order <em>ordering</em><br>
-<strong>Default:</strong> <code>order deny,allow</code><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> Limit<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_access
-</p>
+<STRONG>Syntax:</STRONG> order <EM>ordering</EM><BR>
+<STRONG>Default:</STRONG> <CODE>order deny,allow</CODE><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> Limit<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_access
+</P>
 <P>
 The order directive controls the order in which <A HREF="#allow">allow</A> and
-<A HREF="#deny">deny</A> directives are evaluated. <em>Ordering</em> is one
+<A HREF="#deny">deny</A> directives are evaluated. <EM>Ordering</EM> is one
 of
 </P>
-<dl>
-<dt>deny,allow
-<dd>the deny directives are evaluated before the allow directives.  (The
+<DL>
+<DT>deny,allow
+<DD>the deny directives are evaluated before the allow directives.  (The
 initial state is OK.)
-<dt>allow,deny
-<dd>the allow directives are evaluated before the deny directives.  (The
+<DT>allow,deny
+<DD>the allow directives are evaluated before the deny directives.  (The
 initial state is FORBIDDEN.)
-<dt>mutual-failure
-<dd>Only those hosts which appear on the allow list and do not appear
+<DT>mutual-failure
+<DD>Only those hosts which appear on the allow list and do not appear
 on the deny list are granted access.  (The initial state is irrelevant.)
-</dl>
+</DL>
 <P>
-<b>Note that in all cases every <code>allow</code> and <code>deny</code>
-statement is evaluated, there is no &quot;short-circuiting&quot;.</b>
+<STRONG>Note that in all cases every <CODE>allow</CODE> and <CODE>deny</CODE>
+statement is evaluated, there is no &quot;short-circuiting&quot;.</STRONG>
 </P>
-<p>
+<P>
 Example:
 </P>
-<blockquote><code>
-    order deny,allow<br>
-    deny from all<br>
-    allow from .ncsa.uiuc.edu<br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+    order deny,allow<BR>
+    deny from all<BR>
+    allow from .ncsa.uiuc.edu<BR>
+</CODE></BLOCKQUOTE>
 <P>
 Hosts in the ncsa.uiuc.edu domain are allowed access; all other hosts are
 denied access.
index 07823cbc82c5c862399bb0f7557c4dd8759673cc..dd41533dad168ac59b5631f6ed8f441c62edc70f 100644 (file)
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_actions</h1>
+<H1 ALIGN="CENTER">Module mod_actions</H1>
 <P>
-This module is contained in the <code>mod_actions.c</code> file, and
+This module is contained in the <CODE>mod_actions.c</CODE> file, and
 is compiled in by default. It provides for
 executing CGI scripts based on media type or request method. It is not
 present in versions prior to Apache 1.1.
@@ -27,64 +27,64 @@ is requested. This makes it much easier to execute scripts that
 process files.
 </P>
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#action">Action</A>
-<li><A HREF="#script">Script</A>
-</ul>
+<UL>
+<LI><A HREF="#action">Action</A>
+<LI><A HREF="#script">Script</A>
+</UL>
 
-<hr>
+<HR>
 
 <h2><A name="action">Action directive</A></h2>
 <P>
-<strong>Syntax:</strong> Action <em>mime-type cgi-script</em><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_actions<br>
-<strong>Compatibility:</strong> Action is only available in Apache 1.1
+<STRONG>Syntax:</STRONG> Action <EM>mime-type cgi-script</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_actions<BR>
+<STRONG>Compatibility:</STRONG> Action is only available in Apache 1.1
 and later
-</p>
+</P>
 <P>
-This directive adds an action, which will activate <em>cgi-script</em> when
-a file of content type <em>mime-type</em> is requested. It sends the
+This directive adds an action, which will activate <EM>cgi-script</EM> when
+a file of content type <EM>mime-type</EM> is requested. It sends the
 URL and file path of the requested document using the standard
 CGI PATH_INFO and PATH_TRANSLATED environment variables.
 </P>
-<hr>
+<HR>
 
 <h2><A name="script">Script directive</A></h2>
 <P>
-<strong>Syntax:</strong> Script <em>method cgi-script</em><br>
-<strong>Context:</strong> server config, virtual host, directory<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_actions<br>
-<strong>Compatibility:</strong> Script is only available in Apache 1.1
+<STRONG>Syntax:</STRONG> Script <EM>method cgi-script</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_actions<BR>
+<STRONG>Compatibility:</STRONG> Script is only available in Apache 1.1
 and later
-</p>
+</P>
 
-<p>
-This directive adds an action, which will activate <em>cgi-script</em> when
-a file is requested using the method of <em>method</em>, which can be
-one of <code>GET</code>, <code>POST</code>, <code>PUT</code> or
-<code>DELETE</code>. It sends the
+<P>
+This directive adds an action, which will activate <EM>cgi-script</EM> when
+a file is requested using the method of <EM>method</EM>, which can be
+one of <CODE>GET</CODE>, <CODE>POST</CODE>, <CODE>PUT</CODE> or
+<CODE>DELETE</CODE>. It sends the
 URL and file path of the requested document using the standard
 CGI PATH_INFO and PATH_TRANSLATED environment variables.
 </P>
-<p>
+<P>
 Note that the Script command defines default actions only. If a CGI
 script is called, or some other resource that is capable of handling
 the requested method internally, it will do so. Also note that Script
-with a method of <code>GET</code> will only be called if there are
+with a method of <CODE>GET</CODE> will only be called if there are
 query arguments present (e.g. foo.html?hi). Otherwise, the request
 will proceed normally.
 </P>
-<p>
+<P>
 Examples:
 </P>
-<pre>
+<PRE>
     Script GET /cgi-bin/search     #e.g. for &lt;ISINDEX&gt;-style searching
     Script PUT /~bob/put.cgi
-</pre>
+</PRE>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 82b025fbaf22b472d24077f13e3e515163b522e1..61e2b07ca0ca811db0645771434d57c44e77bdb5 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Module mod_alias</h1>
+<H1 ALIGN="CENTER">Module mod_alias</H1>
 <P>
-This module is contained in the <code>mod_alias.c</code> file, and
+This module is contained in the <CODE>mod_alias.c</CODE> file, and
 is compiled in by default. It provides for mapping different parts of the
 host filesystem in the the document tree, and for URL redirection.
 </P>
 
 <H2>Directives</H2>
 <UL>
-<li><A HREF="#alias">Alias</A>
-<li><A HREF="#aliasmatch">AliasMatch</A>
-<li><A HREF="#redirect">Redirect</A>
-<li><A HREF="#redirectmatch">RedirectMatch</A>
-<li><A HREF="#redirecttemp">RedirectTemp</A>
-<li><A HREF="#redirectperm">RedirectPermanent</A>
-<li><A HREF="#scriptalias">ScriptAlias</A>
-<li><A HREF="#scriptaliasmatch">ScriptAliasMatch</A>
+<LI><A HREF="#alias">Alias</A>
+<LI><A HREF="#aliasmatch">AliasMatch</A>
+<LI><A HREF="#redirect">Redirect</A>
+<LI><A HREF="#redirectmatch">RedirectMatch</A>
+<LI><A HREF="#redirecttemp">RedirectTemp</A>
+<LI><A HREF="#redirectperm">RedirectPermanent</A>
+<LI><A HREF="#scriptalias">ScriptAlias</A>
+<LI><A HREF="#scriptaliasmatch">ScriptAliasMatch</A>
 </UL>
-<hr>
+<HR>
 
 
 <h2><A name="alias">Alias directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt Alias} directive&gt; -->
-<strong>Syntax:</strong> Alias <em>url-path directory-filename</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias
+<STRONG>Syntax:</STRONG> Alias <EM>url-path directory-filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias
 </P>
 <P>
 The Alias directive allows documents to be stored in the local filesystem
 other than under the <A HREF="core.html#documentroot">DocumentRoot</A>.
-URLs with a (%-decoded) path beginning with <em>url-path</em> will be
-mapped to local files beginning with <em>directory-filename</em>.
+URLs with a (%-decoded) path beginning with <EM>url-path</EM> will be
+mapped to local files beginning with <EM>directory-filename</EM>.
 <P>
 Example:
 </P>
-<blockquote><code>Alias /image /ftp/pub/image</code></blockquote>
+<BLOCKQUOTE><CODE>Alias /image /ftp/pub/image</CODE></BLOCKQUOTE>
 <P>
 A request for http://myserver/image/foo.gif would cause the server to
 return the file /ftp/pub/image/foo.gif.
-</p>
+</P>
 <P>
-Note that if you include a trailing / on the <em>url-path</em> then the
+Note that if you include a trailing / on the <EM>url-path</EM> then the
 server will require a trailing / in order to expand the alias.  That is,
-if you use <code>Alias /icons/ /usr/local/apache/icons/</code> then
-the url <code>/icons</code> will not be aliased.
-</p>
+if you use <CODE>Alias /icons/ /usr/local/apache/icons/</CODE> then
+the url <CODE>/icons</CODE> will not be aliased.
+</P>
 <P>
 See also <A HREF="#scriptalias">ScriptAlias</A>.
-</p>
-<hr>
+</P>
+<HR>
 
 <h2><A name="aliasmatch">AliasMatch</A></h2>
 <P>
-<strong>Syntax:</strong> AliasMatch <em>regex directory-filename</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias<br>
-<strong>Compatibility:</strong> Available in Apache 1.3 and later
+<STRONG>Syntax:</STRONG> AliasMatch <EM>regex directory-filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias<BR>
+<STRONG>Compatibility:</STRONG> Available in Apache 1.3 and later
 </P>
 
-<p>This directive is equivalent to <a href="#alias">Alias</a>, but
+<P>This directive is equivalent to <A HREF="#alias">Alias</A>, but
 makes use of standard regular expressions, instead of simple prefix
 matching. The supplied regular expression is matched against the URL,
 and if it matches, the server will substitute any parenthesized
 matches into the given string and use it as a filename. For example,
-to activate the <code>/icons</code> directory, one might use:
-<pre>
+to activate the <CODE>/icons</CODE> directory, one might use:
+<PRE>
     AliasMatch ^/icons(.*) /usr/local/apache/icons$1
-</pre>
-</p>
+</PRE>
+</P>
 
-<hr>
+<HR>
 
 <h2><A name="redirect">Redirect directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt Redirect} directive&gt; -->
-<strong>Syntax:</strong> Redirect [ <em>status</em> ] <em>url-path url</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias<br>
-<strong>Compatibility:</strong> The directory and .htaccess context's
-are only available in versions 1.1 and later. The <em>status</em>
+<STRONG>Syntax:</STRONG> Redirect [ <EM>status</EM> ] <EM>url-path url</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias<BR>
+<STRONG>Compatibility:</STRONG> The directory and .htaccess context's
+are only available in versions 1.1 and later. The <EM>status</EM>
 argument is only available in Apache 1.2 or later.
 </P>
 <P>
 The Redirect directive maps an old URL into a new one. The new URL is returned
 to the client which attempts to fetch it again with the new address.
-<em>Url-path</em> a (%-decoded) path; any requests for documents beginning with
+<EM>Url-path</EM> a (%-decoded) path; any requests for documents beginning with
 this path will be returned a redirect error to a new (%-encoded) url
-beginning with <em>url</em>.
+beginning with <EM>url</EM>.
 </P>
 <P>
 Example:
 </P>
-<blockquote><code>Redirect /service
-http://foo2.bar.com/service</code></blockquote>
+<BLOCKQUOTE><CODE>Redirect /service
+http://foo2.bar.com/service</CODE></BLOCKQUOTE>
 <P>
 If the client requests http://myserver/service/foo.txt, it will be told to
 access http://foo2.bar.com/service/foo.txt instead.
-</p>
+</P>
 <P>
 <STRONG>Note:</STRONG> Redirect directives take precedence over Alias
 and ScriptAlias
 directives, irrespective of their ordering in the configuration file.  Also,
-<em>Url-path</em> must be an absolute path, not a relative path, even
+<EM>Url-path</EM> must be an absolute path, not a relative path, even
 when used with .htaccess files or inside of &lt;Directory&gt; sections.
-</p>
+</P>
 <P>
-If no <em>status</em> argument is given, the redirect will be
+If no <EM>status</EM> argument is given, the redirect will be
 &quot;temporary&quot; (HTTP status 302). This indicates to the client that the
-resources is has moved temporarily. The <em>status</em>
+resources is has moved temporarily. The <EM>status</EM>
 argument can be used to return other HTTP status codes:
 <P>
-<dl>
-<dt>permanent
-<dd>Returns a permanent redirect status (301) indicating that
+<DL>
+<DT>permanent
+<DD>Returns a permanent redirect status (301) indicating that
 the resource has moved permanently.
-<dt>temp
-<dd>Returns a temporary redirect status (302). This is the
+<DT>temp
+<DD>Returns a temporary redirect status (302). This is the
 default.
-<dt>seeother
-<dd>Returns a "See Other" status (303) indicating that
+<DT>seeother
+<DD>Returns a "See Other" status (303) indicating that
 the resource has been replaced.
-<dt>gone
-<dd>Returns a "Gone" status (410) indicating that the resource
-has been permanently removed. When this status is used the <em>url</em>
+<DT>gone
+<DD>Returns a "Gone" status (410) indicating that the resource
+has been permanently removed. When this status is used the <EM>url</EM>
 argument should be omitted.
-</dl>
+</DL>
 <P>
 Other status codes can be returned by giving the numeric status code
-as the value of <em>status</em>. If the status is between 300 and 399,
-the <em>url</em> argument must be present, otherwise it must be
+as the value of <EM>status</EM>. If the status is between 300 and 399,
+the <EM>url</EM> argument must be present, otherwise it must be
 omitted. Note that the status must be known to the Apache code (see
-the function <code>send_error_response</code> in http_protocol.c).
+the function <CODE>send_error_response</CODE> in http_protocol.c).
 </P>
 <HR>
 
 <h2><A name="redirectmatch">RedirectMatch</A></h2>
 <P>
-<strong>Syntax:</strong> RedirectMatch [<em>status</em> <em>regex url</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias<br>
-<strong>Compatibility:</strong> Available in Apache 1.3 and later
+<STRONG>Syntax:</STRONG> RedirectMatch [<EM>status</EM> <EM>regex url</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias<BR>
+<STRONG>Compatibility:</STRONG> Available in Apache 1.3 and later
 </P>
 
-<p>This directive is equivalent to <a href="#alias">Redirect</a>, but
+<P>This directive is equivalent to <A HREF="#alias">Redirect</A>, but
 makes use of standard regular expressions, instead of simple prefix
 matching. The supplied regular expression is matched against the URL,
 and if it matches, the server will substitute any parenthesized
 matches into the given string and use it as a filename. For example,
 to redirect all GIF files to like-named JPEG files on another server,
 one might use:
-<pre>
+<PRE>
     RedirectMatch (.*)\.gif$ http://www.anotherserver.com$1.jpg
-</pre>
-</p>
+</PRE>
+</P>
 
-<hr>
+<HR>
 
 <h2><A name="redirecttemp">RedirectTemp directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt Redirect} directive&gt; -->
-<strong>Syntax:</strong> RedirectTemp <em>url-path url</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias<br>
-<strong>Compatibility:</strong> This directive is only available in 1.2
+<STRONG>Syntax:</STRONG> RedirectTemp <EM>url-path url</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias<BR>
+<STRONG>Compatibility:</STRONG> This directive is only available in 1.2
 </P>
 <P>
 This directive makes the client know that the Redirect is only
-temporary (status 302). Exactly equivalent to <code>Redirect
-temporary</code>.
+temporary (status 302). Exactly equivalent to <CODE>Redirect
+temporary</CODE>.
 </P>
 <HR>
 
 <h2><A name="redirectperm">RedirectPermanent directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt Redirect} directive&gt; -->
-<strong>Syntax:</strong> RedirectPermanent <em>url-path url</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias<br>
-<strong>Compatibility:</strong> This directive is only available in 1.2
+<STRONG>Syntax:</STRONG> RedirectPermanent <EM>url-path url</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias<BR>
+<STRONG>Compatibility:</STRONG> This directive is only available in 1.2
 </P>
 <P>
 This directive makes the client know that the Redirect is permanent
-(status 301). Exactly equivalent to <code>Redirect permanent</code>.
+(status 301). Exactly equivalent to <CODE>Redirect permanent</CODE>.
 </P>
-<hr>
+<HR>
 
 <h2><A name="scriptalias">ScriptAlias directive</A></h2>
 <P>
 <!--%plaintext &lt;?INDEX {\tt ScriptAlias} directive&gt; -->
-<strong>Syntax:</strong> ScriptAlias <em>url-path directory-filename</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias
+<STRONG>Syntax:</STRONG> ScriptAlias <EM>url-path directory-filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias
 </P>
 <P>
 The ScriptAlias directive has the same behavior as the
 <A HREF="#alias">Alias</A> directive, except that in addition it
 marks the target directory as containing CGI scripts.
-URLs with a (%-decoded) path beginning with <em>url-path</em> will be
-mapped to scripts beginning with <em>directory-filename</em>.
+URLs with a (%-decoded) path beginning with <EM>url-path</EM> will be
+mapped to scripts beginning with <EM>directory-filename</EM>.
 <P>
 Example:
 </P>
-<blockquote><code>ScriptAlias /cgi-bin/ /web/cgi-bin/</code></blockquote>
+<BLOCKQUOTE><CODE>ScriptAlias /cgi-bin/ /web/cgi-bin/</CODE></BLOCKQUOTE>
 <P>
 A request for http://myserver/cgi-bin/foo would cause the server to
 run the script /web/cgi-bin/foo.
 </P>
 
-<hr>
+<HR>
 
 <h2><A name="scriptaliasmatch">ScriptAliasMatch</A></h2>
 <P>
-<strong>Syntax:</strong> ScriptAliasMatch <em>regex directory-filename</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_alias<br>
-<strong>Compatibility:</strong> Available in Apache 1.3 and later
+<STRONG>Syntax:</STRONG> ScriptAliasMatch <EM>regex directory-filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_alias<BR>
+<STRONG>Compatibility:</STRONG> Available in Apache 1.3 and later
 </P>
 
-<p>This directive is equivalent to <a href="#scriptalias">ScriptAlias</a>, but
+<P>This directive is equivalent to <A HREF="#scriptalias">ScriptAlias</A>, but
 makes use of standard regular expressions, instead of simple prefix
 matching. The supplied regular expression is matched against the URL,
 and if it matches, the server will substitute any parenthesized
 matches into the given string and use it as a filename. For example,
-to activate the standard <code>/cgi-bin</code>, one might use:
-<pre>
+to activate the standard <CODE>/cgi-bin</CODE>, one might use:
+<PRE>
     ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1
-</pre>
-</p>
+</PRE>
+</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index b3a445d07837abe5f5a62733e45d69485307a2bc..db224d51771f0dd60e85d8c52b9b7d4833466655 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Module mod_asis</h1>
+<H1 ALIGN="CENTER">Module mod_asis</H1>
 
-This module is contained in the <code>mod_asis.c</code> file, and
-is compiled in by default. It provides for <code>.asis</code> files. Any
-document with mime type <code>httpd/send-as-is</code> will be processed by
+This module is contained in the <CODE>mod_asis.c</CODE> file, and
+is compiled in by default. It provides for <CODE>.asis</CODE> files. Any
+document with mime type <CODE>httpd/send-as-is</CODE> will be processed by
 this module.
 <!--%plaintext &lt;?INDEX {\tt httpd/send-as-is} mime type&gt; -->
 
@@ -31,36 +31,36 @@ and other special HTTP responses, without requiring a cgi-script or an nph
 script.
 <h2>Usage</h2>
 In the server configuration file, define a new mime type called
-<code>httpd/send-as-is</code> e.g.
-<blockquote><code>AddType httpd/send-as-is asis</code></blockquote>
-this defines the <code>.asis</code> file extension as being of the new
-<code>httpd/send-as-is</code> mime type. The contents of any file with a
-<code>.asis</code> extension will then be sent by Apache to the client with
+<CODE>httpd/send-as-is</CODE> e.g.
+<BLOCKQUOTE><CODE>AddType httpd/send-as-is asis</CODE></BLOCKQUOTE>
+this defines the <CODE>.asis</CODE> file extension as being of the new
+<CODE>httpd/send-as-is</CODE> mime type. The contents of any file with a
+<CODE>.asis</CODE> extension will then be sent by Apache to the client with
 almost no changes. Clients will need HTTP headers to be attached, so do not
 forget them. A Status: header is also required; the data should be the
-3-digit HTTP response code, followed by a textual message.<p>
+3-digit HTTP response code, followed by a textual message.<P>
 
-Here's an example of a file whose contents are sent <em>as is</em> so as to
+Here's an example of a file whose contents are sent <EM>as is</EM> so as to
 tell the client that a file has redirected.
-<blockquote><code>
-Status: 301 Now where did I leave that URL <br>
-Location: http://xyz.abc.com/foo/bar.html <br>
-Content-type: text/html <br>
-<br>
-&lt;HTML&gt; <br>
-&lt;HEAD&gt; <br>
-&lt;TITLE&gt;Lame excuses'R'us&lt;/TITLE&gt; <br>
-&lt;/HEAD&gt; <br>
-&lt;BODY&gt; <br>
-&lt;H1&gt;Fred's exceptionally wonderful page has moved to <br>
-&lt;A HREF="http://xyz.abc.com/foo/bar.html"&gt;Joe's&lt;/A&gt; site.  <br>
-&lt;/H1&gt; <br>
-&lt;/BODY&gt; <br>
+<BLOCKQUOTE><CODE>
+Status: 301 Now where did I leave that URL <BR>
+Location: http://xyz.abc.com/foo/bar.html <BR>
+Content-type: text/html <BR>
+<BR>
+&lt;HTML&gt; <BR>
+&lt;HEAD&gt; <BR>
+&lt;TITLE&gt;Lame excuses'R'us&lt;/TITLE&gt; <BR>
+&lt;/HEAD&gt; <BR>
+&lt;BODY&gt; <BR>
+&lt;H1&gt;Fred's exceptionally wonderful page has moved to <BR>
+&lt;A HREF="http://xyz.abc.com/foo/bar.html"&gt;Joe's&lt;/A&gt; site.  <BR>
+&lt;/H1&gt; <BR>
+&lt;/BODY&gt; <BR>
 &lt;/HTML&gt;
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 Notes: the server always adds a Date: and Server: header to the data returned
 to the client, so these should not be included in the file.
-The server does <em>not</em> add a Last-Modified header; it probably should.
+The server does <EM>not</EM> add a Last-Modified header; it probably should.
 <P>
 
 <!--#include virtual="footer.html" -->
index c0286fe39517ae62b74429f1c4a31831f781d2f5..eb006f4837102ae179dac87d53210391e398294e 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Module mod_auth</h1>
+<H1 ALIGN="CENTER">Module mod_auth</H1>
 
-This module is contained in the <code>mod_auth.c</code> file, and
+This module is contained in the <CODE>mod_auth.c</CODE> file, and
 is compiled in by default. It provides for user authentication using
 textual files.
 
 
-<menu>
-<li><A HREF="#authgroupfile">AuthGroupFile</A>
-<li><A HREF="#authuserfile">AuthUserFile</A>
-<li><A HREF="#authauthoritative">AuthAuthoritative</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#authgroupfile">AuthGroupFile</A>
+<LI><A HREF="#authuserfile">AuthUserFile</A>
+<LI><A HREF="#authauthoritative">AuthAuthoritative</A>
+</MENU>
+<HR>
 
 
 <A name="authgroupfile"><h2>AuthGroupFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthGroupFile} directive&gt; -->
-<strong>Syntax:</strong> AuthGroupFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_auth<p>
+<STRONG>Syntax:</STRONG> AuthGroupFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_auth<P>
 
 The AuthGroupFile directive sets the name of a textual file containing the list
-of user groups for user authentication. <em>Filename</em> is the path
+of user groups for user authentication. <EM>Filename</EM> is the path
 to the group file.  If it is not absolute (<EM>i.e.</EM>, if it
 doesn't begin with a slash), it is treated as relative to the ServerRoot.
 <P>
 Each line of the group file contains a groupname followed by a colon, followed
 by the member usernames separated by spaces. Example:
-<blockquote><code>mygroup: bob joe anne</code></blockquote>
-Note that searching large text files is <em>very</em> inefficient;
+<BLOCKQUOTE><CODE>mygroup: bob joe anne</CODE></BLOCKQUOTE>
+Note that searching large text files is <EM>very</EM> inefficient;
 <A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A> should
-be used instead.<p>
+be used instead.<P>
 
 Security: make sure that the AuthGroupFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
-it protects. Otherwise, clients will be able to download the AuthGroupFile.<p>
+document tree of the web-server; do <EM>not</EM> put it in the directory that
+it protects. Otherwise, clients will be able to download the AuthGroupFile.<P>
 
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authuserfile">AuthUserFile</A>.<p><hr>
+<A HREF="#authuserfile">AuthUserFile</A>.<P><HR>
 
 <A name="authuserfile"><h2>AuthUserFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthUserFile} directive&gt; -->
-<strong>Syntax:</strong> AuthUserFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_auth<p>
+<STRONG>Syntax:</STRONG> AuthUserFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_auth<P>
 
 The AuthUserFile directive sets the name of a textual file containing
 the list of users and passwords for user
-authentication. <em>Filename</em> is the path to the user
+authentication. <EM>Filename</EM> is the path to the user
 file. If it is not absolute (<EM>i.e.</EM>, if it doesn't begin with a
 slash), it is treated as relative to the ServerRoot.
-<p> Each line of the user file file contains a username followed
+<P> Each line of the user file file contains a username followed
 by a colon, followed by the crypt() encrypted password. The behavior
 of multiple occurrences of the same user is undefined.
-<p> Note that
+<P> Note that
 searching large text files is <EM>very</EM> inefficient;
 <A HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A> should be
 used instead.
-<p>
+<P>
 
 Security: make sure that the AuthUserFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
-it protects. Otherwise, clients will be able to download the AuthUserFile.<p>
+document tree of the web-server; do <EM>not</EM> put it in the directory that
+it protects. Otherwise, clients will be able to download the AuthUserFile.<P>
 
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authgroupfile">AuthGroupFile</A>.<p>
-<hr>
+<A HREF="#authgroupfile">AuthGroupFile</A>.<P>
+<HR>
 <A name="authauthoritative"><h2>AuthAuthoritative</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthAuthoritative} directive&gt; -->
-<strong>Syntax:</strong> AuthAuthoritative &lt; <strong> on</strong>(default) | off &gt; <br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_auth<p>
+<STRONG>Syntax:</STRONG> AuthAuthoritative &lt; <STRONG> on</STRONG>(default) | off &gt; <BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_auth<P>
 
-Setting the AuthAuthoritative directive explicitly to <b>'off'</b>
+Setting the AuthAuthoritative directive explicitly to <STRONG>'off'</STRONG>
 allows for both authentication and authorization to be passed on to
-lower level modules (as defined in the <code>Configuration</code> and
-<code>modules.c</code> files) if there is <b>no userID</b> or
-<b>rule</b> matching the supplied userID. If there is a userID and/or
+lower level modules (as defined in the <CODE>Configuration</CODE> and
+<CODE>modules.c</CODE> files) if there is <STRONG>no userID</STRONG> or
+<STRONG>rule</STRONG> matching the supplied userID. If there is a userID and/or
 rule specified; the usual password and access checks will be applied
 and a failure will give an Authorization Required reply.
 
-<p>
+<P>
 
 So if a userID appears in the database of more than one module; or if
 a valid require directive applies to more than one module; then the
 first module will verify the credentials; and no access is passed on;
 regardless of the AuthAuthoritative setting.
 
-<p>
+<P>
 
 A common use for this is in conjunction with one of the database
-modules; such as <a
-href="mod_auth_db.html"><code>mod_auth_db.c</code></a>, <a
-href="mod_auth_dbm.html"><code>mod_auth_dbm.c</code></a>, 
-<code>mod_auth_msql.c</code>, and <a
-href="mod_auth_anon.html"><code>mod_auth_anon.c</code></a>. These modules
+modules; such as <A
+HREF="mod_auth_db.html"><CODE>mod_auth_db.c</CODE></A>, <A
+HREF="mod_auth_dbm.html"><CODE>mod_auth_dbm.c</CODE></A>, 
+<CODE>mod_auth_msql.c</CODE>, and <A
+HREF="mod_auth_anon.html"><CODE>mod_auth_anon.c</CODE></A>. These modules
 supply the bulk of the user credential checking; but a few
 (administrator) related accesses fall through to a lower level with a
 well protected AuthUserFile.
 
-<p>
+<P>
 
-<b>Default:</b> By default; control is not passed on; and an unknown
+<STRONG>Default:</STRONG> By default; control is not passed on; and an unknown
 userID or rule will result in an Authorization Required reply. Not
 setting it thus keeps the system secure; and forces an NSCA compliant
 behaviour.
 
-<p>
+<P>
 
 Security: Do consider the implications of allowing a user to allow
 fall-through in his .htaccess file; and verify that this is really
 what you want; Generally it is easier to just secure a single
 .htpasswd file, than it is to secure a database such as mSQL. Make
 sure that the AuthUserFile is stored outside the document tree of the
-web-server; do <em>not</em> put it in the directory that it
+web-server; do <EM>not</EM> put it in the directory that it
 protects. Otherwise, clients will be able to download the
 AuthUserFile.
 
-<p>
+<P>
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authgroupfile">AuthGroupFile</A>.<p>
+<A HREF="#authgroupfile">AuthGroupFile</A>.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 2ab6e88afabc3e6d9bcc13d5bc1eecdb9fba9ed4..82acd9812f05645e00505af895feda33283cc45d 100644 (file)
@@ -14,7 +14,7 @@
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Module mod_auth_anon</H1>
 
-This module is contained in the <code>mod_auth_anon.c</code> file and
+This module is contained in the <CODE>mod_auth_anon.c</CODE> file and
 is not compiled in by default. It is only available in Apache 1.1 and
 later. It allows "anonymous" user access to authenticated areas.
 
@@ -23,114 +23,114 @@ later. It allows "anonymous" user access to authenticated areas.
 It does access control in a manner similar to anonymous-ftp sites; i.e.
 have a 'magic' user id 'anonymous' and the email address as a password.
 These email addresses can be logged.
-<p>
+<P>
 Combined with other (database) access control methods, this allows for
 effective user tracking and customization according to a user profile
 while still keeping the site open for 'unregistered' users. One advantage
 of using Auth-based user tracking is that, unlike magic-cookies and
 funny URL pre/postfixes, it is completely browser independent and it
 allows users to share URLs.
-<p>
-
-<a href="#Directives">Directives</a> /
-<a href="#Example">Example</a> /
-<a href="#CompileTimeOptions">Compile time options</a> /
-<a href="#RevisionHistory">RevisionHistory</a> /
-<a href="#Person">Person to blame</a> /
-<a href="#Sourcecode">Sourcecode</a>
-<p>
-
-<h2><a name="Directives">Directives</a></h2>
-<ul>
-<li><A HREF="#anonymous">Anonymous</A>
-<li><A HREF="#Authoritative">Anonymous_Authoritative</A>
-<li><A HREF="#LogEmail">Anonymous_LogEmail</A>
-<li><A HREF="#MustGiveEmail">Anonymous_MustGiveEmail</A>
-<li><A HREF="#NoUserID">Anonymous_NoUserID</A>
-<li><A HREF="#VerifyEmail">Anonymous_VerifyEmail</A>
-</ul>
-
-<hr>
+<P>
+
+<A HREF="#Directives">Directives</A> /
+<A HREF="#Example">Example</A> /
+<A HREF="#CompileTimeOptions">Compile time options</A> /
+<A HREF="#RevisionHistory">RevisionHistory</A> /
+<A HREF="#Person">Person to blame</A> /
+<A HREF="#Sourcecode">Sourcecode</A>
+<P>
+
+<h2><A name="Directives">Directives</A></h2>
+<UL>
+<LI><A HREF="#anonymous">Anonymous</A>
+<LI><A HREF="#Authoritative">Anonymous_Authoritative</A>
+<LI><A HREF="#LogEmail">Anonymous_LogEmail</A>
+<LI><A HREF="#MustGiveEmail">Anonymous_MustGiveEmail</A>
+<LI><A HREF="#NoUserID">Anonymous_NoUserID</A>
+<LI><A HREF="#VerifyEmail">Anonymous_VerifyEmail</A>
+</UL>
+
+<HR>
 
 <h2><A name="anonymous">Anonymous directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Anonymous} directive&gt; -->
-<strong>Syntax:</strong> Anonymous <em>user user ...</em><br>
-<strong>Default:</strong> none<br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_anon<p>
+<STRONG>Syntax:</STRONG> Anonymous <EM>user user ...</EM><BR>
+<STRONG>Default:</STRONG> none<BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_anon<P>
 
         A list of one or more 'magic' userIDs which are allowed access
         without password verification. The userIDs are space separated.
         It is possible to use the ' and " quotes to allow a space in
         a userID as well as the \ escape character.
-        <p>
-        Please note that the comparison is <b>case-IN-sensitive</b>.
-        <br>
-        I strongly suggest that the magic username '<code>anonymous</code>'
+        <P>
+        Please note that the comparison is <STRONG>case-IN-sensitive</STRONG>.
+        <BR>
+        I strongly suggest that the magic username '<CODE>anonymous</CODE>'
         is always one of the allowed userIDs.
-        <p>
-        Example:<br>
-        <code>
+        <P>
+        Example:<BR>
+        <CODE>
         Anonymous anonymous "Not Registered" 'I don\'t know'
-        </code><p>
+        </CODE><P>
         This would allow the user to enter without password verification
         by using the userId's 'anonymous', 'AnonyMous','Not Registered' and
         'I Don't Know'.
 <HR>
 
 <h2><A name="Authoritative">Anonymous_Authoritative directive</A></h2>
-<strong>Syntax:</strong> Anonymous_Authoritative <em>on | off</em><br>
-<strong>Default:</strong> <code>Anonymous_Authoritative off</code><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_anon<p>
+<STRONG>Syntax:</STRONG> Anonymous_Authoritative <EM>on | off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Anonymous_Authoritative off</CODE><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_anon<P>
 
         When set 'on', there is no
         fall-through to other authorization methods. So if a
         userID does not match the values specified in the
-        <code>Anonymous</code> directive, access is denied.
-        <p>
+        <CODE>Anonymous</CODE> directive, access is denied.
+        <P>
         Be sure you know what you are doing when you decide to switch
         it on. And remember that it is the linking order of the modules
         (in the Configuration / Make file) which details the order
         in which the Authorization modules are queried.
-<hr>
+<HR>
 
 <h2><A name="LogEmail">Anonymous_LogEmail directive</A></h2>
-<strong>Syntax:</strong> Anonymous_LogEmail <em>on | off</em><br>
-<strong>Default:</strong> <code>Anonymous_LogEmail on</code><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_anon<p>
+<STRONG>Syntax:</STRONG> Anonymous_LogEmail <EM>on | off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Anonymous_LogEmail on</CODE><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_anon<P>
 
         When set 'on', the default, the 'password' entered (which hopefully
         contains a sensible email address) is logged in the httpd-log file.
-<hr>
+<HR>
 
 <h2><A name="MustGiveEmail">Anonymous_MustGiveEmail directive</A></h2>
 <!--%plaintext &lt;?INDEX {\tt Anonymous_MustGiveEmail} directive&gt; -->
-<strong>Syntax:</strong> Anonymous_MustGiveEmail <em>on</em> | <em>off</em><br>
-<strong>Default:</strong> <code>Anonymous_MustGiveEmail on</code><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_anon<p>
+<STRONG>Syntax:</STRONG> Anonymous_MustGiveEmail <EM>on</EM> | <EM>off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Anonymous_MustGiveEmail on</CODE><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_anon<P>
 
         Specifies whether the user must specify an email
         address as the password.  This prohibits blank passwords.
 <HR>
 
 <h2><A name="NoUserID">Anonymous_NoUserID directive</A></h2>
-<strong>Syntax:</strong> Anonymous_NoUserID <em>on | off</em><br>
-<strong>Default:</strong> <code>Anonymous_NoUserID off</code><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_anon<p>
+<STRONG>Syntax:</STRONG> Anonymous_NoUserID <EM>on | off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Anonymous_NoUserID off</CODE><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_anon<P>
 
         When set 'on', users can leave
         the userID (and perhaps the password field) empty. This
@@ -138,114 +138,114 @@ allows users to share URLs.
         just hit return or click directly on the OK button; which
         seems a natural reaction.
 
-<hr>
+<HR>
 
 <h2><A name="VerifyEmail">Anonymous_VerifyEmail directive</A></h2>
-<strong>Syntax:</strong> Anonymous_VerifyEmail <em>on | off</em><br>
-<strong>Default:</strong> <code>Anonymous_VerifyEmail off</code><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_anon<p>
+<STRONG>Syntax:</STRONG> Anonymous_VerifyEmail <EM>on | off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>Anonymous_VerifyEmail off</CODE><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_anon<P>
 
         When set 'on' the 'password' entered is
         checked for at least one '@' and a '.' to encourage users to enter
-        valid email addresses (see the above <code>Auth_LogEmail</code>).
+        valid email addresses (see the above <CODE>Auth_LogEmail</CODE>).
 
-<hr>
-<h2><a name="Example">Example</A></h2>
+<HR>
+<h2><A name="Example">Example</A></h2>
 
 The example below (when combined with the Auth directives
 of a htpasswd-file based (or GDM, mSQL <EM>etc.</EM>) base access
 control system allows users in as 'guests' with the
 following properties:
-<ul>
-<li>
-It insists that the user enters a userId. (<code>Anonymous_NoUserId</code>)
-<li>
-It insists that the user enters a password. (<code>Anonymous_MustGiveEmail</code>)
-<li>
+<UL>
+<LI>
+It insists that the user enters a userId. (<CODE>Anonymous_NoUserId</CODE>)
+<LI>
+It insists that the user enters a password. (<CODE>Anonymous_MustGiveEmail</CODE>)
+<LI>
 The password entered must be a valid email address, ie. contain at least one '@' and a '.'.
-(<code>Anonymous_VerifyEmail</code>)
-<li>
-The userID must be one of <code>anonymous guest www test welcome</code>
-and comparison is <b>not</b> case sensitive.
-<li>
+(<CODE>Anonymous_VerifyEmail</CODE>)
+<LI>
+The userID must be one of <CODE>anonymous guest www test welcome</CODE>
+and comparison is <STRONG>not</STRONG> case sensitive.
+<LI>
 And the Email addresses entered in the passwd field are logged to
 the httpd-log file
-(<code>Anonymous_LogEmail</code>)
-</ul>
-<p>
+(<CODE>Anonymous_LogEmail</CODE>)
+</UL>
+<P>
 Excerpt of access.conf:
-<blockquote><code>
-Anonymous_NoUserId      off<br>
-Anonymous_MustGiveEmail on<br>
-Anonymous_VerifyEmail    on<br>
-Anonymous_LogEmail      on<br>
-Anonymous        anonymous guest www test welcome<p>
-<p>
-AuthName                Use 'anonymous' & Email address for guest entry<br>
+<BLOCKQUOTE><CODE>
+Anonymous_NoUserId      off<BR>
+Anonymous_MustGiveEmail on<BR>
+Anonymous_VerifyEmail    on<BR>
+Anonymous_LogEmail      on<BR>
+Anonymous        anonymous guest www test welcome<P>
+<P>
+AuthName                Use 'anonymous' & Email address for guest entry<BR>
 AuthType                basic
-<p>
-# An AuthUserFile/AuthDBUserFile/AuthDBMUserFile<br>
-# directive must be specified, or use<br>
-# Anonymous_Authoritative for public access.<br>
-# In the .htaccess for the public directory, add:<br>
-&lt;Files *&gt;<br>
-order deny,allow          <br>
-allow from all            <br>
-<p>
-require valid-user        <br>
-&lt;/Files&gt;<br>
-</code></blockquote>
-
-
-<hr>
-<h2><a name="CompileTimeOptions">Compile Time Options</a></h2>
+<P>
+# An AuthUserFile/AuthDBUserFile/AuthDBMUserFile<BR>
+# directive must be specified, or use<BR>
+# Anonymous_Authoritative for public access.<BR>
+# In the .htaccess for the public directory, add:<BR>
+&lt;Files *&gt;<BR>
+order deny,allow          <BR>
+allow from all            <BR>
+<P>
+require valid-user        <BR>
+&lt;/Files&gt;<BR>
+</CODE></BLOCKQUOTE>
+
+
+<HR>
+<h2><A name="CompileTimeOptions">Compile Time Options</A></h2>
 
 Currently there are no Compile options.
 
-<hr>
-<h2><a name="RevisionHistory">Revision History</a></h2>
+<HR>
+<h2><A name="RevisionHistory">Revision History</A></h2>
 
 This version: 23 Nov 1995, 24 Feb 1996, 16 May 1996.
 
-<dl>
+<DL>
 
-<dt>Version 0.4<br></dt>
-    <dd>First release
-    </dd>
-<dt>Version 0.5<br></dt>
-    <dd>Added 'VerifyEmail' and 'LogEmail' options. Multiple
+<DT>Version 0.4<BR></DT>
+    <DD>First release
+    </DD>
+<DT>Version 0.5<BR></DT>
+    <DD>Added 'VerifyEmail' and 'LogEmail' options. Multiple
         'anonymous' tokens allowed. more docs. Added Authoritative
         functionality.
-    </dd>
-</dl>
+    </DD>
+</DL>
 
 
-<hr>
-<h2><a name="Person">Contact/person to blame</a></h2>
+<HR>
+<h2><A name="Person">Contact/person to blame</A></h2>
 
 This module was written for the
-<a href="http://ewse.ceo.org">European Wide Service Exchange</a> by
-&lt<a href="mailto:Dirk.vanGulik@jrc.it"><code>Dirk.vanGulik@jrc.it</code></a>&gt.
+<A HREF="http://ewse.ceo.org">European Wide Service Exchange</A> by
+&lt<A HREF="mailto:Dirk.vanGulik@jrc.it"><CODE>Dirk.vanGulik@jrc.it</CODE></A>&gt.
 Feel free to contact me if you have any problems, ice-creams or bugs. This
-documentation, courtesy of Nick Himba, <a href="mailto:himba@cs.utwente.nl">
-<code>&lt;himba@cs.utwente.nl&gt;</code></a>.
-<p>
+documentation, courtesy of Nick Himba, <A HREF="mailto:himba@cs.utwente.nl">
+<CODE>&lt;himba@cs.utwente.nl&gt;</CODE></A>.
+<P>
 
 
-<hr>
-<h2><a NAME="Sourcecode">Sourcecode</a></h2>
+<HR>
+<h2><A NAME="Sourcecode">Sourcecode</A></h2>
 
-The source code can be found at <a href="http://www.apache.org"><code>
-http://www.apache.org</code></a>. A snapshot of a development version
-usually resides at <a href="http://me-www.jrc.it/~dirkx/mod_auth_anon.c"><code>
-http://me-www.jrc.it/~dirkx/mod_auth_anon.c</code></a>. Please make sure
+The source code can be found at <A HREF="http://www.apache.org"><CODE>
+http://www.apache.org</CODE></A>. A snapshot of a development version
+usually resides at <A HREF="http://me-www.jrc.it/~dirkx/mod_auth_anon.c"><CODE>
+http://me-www.jrc.it/~dirkx/mod_auth_anon.c</CODE></A>. Please make sure
 that you always quote the version you use when filing a bug report.
-<p>
+<P>
 
 <!--#include virtual="footer.html" -->
-</body>
-</html>
+</BODY>
+</HTML>
 
index d97035bf0fff6372ab8627792ab698dae992bb78..55173ea97ac47d6b64ded94c338f8f092f070ea9 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_auth_db</h1>
+<H1 ALIGN="CENTER">Module mod_auth_db</H1>
 
-This module is contained in the <code>mod_auth_db.c</code> file, and
+This module is contained in the <CODE>mod_auth_db.c</CODE> file, and
 is not compiled in by default. It provides for user authentication using
 Berkeley DB files. It is an alternative to <A HREF="mod_auth_dbm.html">DBM</A>
 files for those systems which support DB and not DBM. It is only
 available in Apache 1.1 and later.
 
 
-<menu>
-<li><A HREF="#authdbgroupfile">AuthDBGroupFile</A>
-<li><A HREF="#authdbuserfile">AuthDBUserFile</A>
-<li><A HREF="#authdbauthoritative">AuthDBAuthoritative</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#authdbgroupfile">AuthDBGroupFile</A>
+<LI><A HREF="#authdbuserfile">AuthDBUserFile</A>
+<LI><A HREF="#authdbauthoritative">AuthDBAuthoritative</A>
+</MENU>
+<HR>
 
 
 <A name="authdbgroupfile"><h2>AuthDBGroupFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBGroupFile} directive&gt; -->
-<strong>Syntax:</strong> AuthDBGroupFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_db<p>
+<STRONG>Syntax:</STRONG> AuthDBGroupFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_db<P>
 
 The AuthDBGroupFile directive sets the name of a DB file containing the list
-of user groups for user authentication. <em>Filename</em> is the absolute path
-to the group file.<p>
+of user groups for user authentication. <EM>Filename</EM> is the absolute path
+to the group file.<P>
 
 The group file is keyed on the username. The value for a user is a
 comma-separated list of the groups to which the users belongs. There must
-be no whitespace within the value, and it must never contain any colons.<p>
+be no whitespace within the value, and it must never contain any colons.<P>
 
 Security: make sure that the AuthDBGroupFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
+document tree of the web-server; do <EM>not</EM> put it in the directory that
 it protects. Otherwise, clients will be able to download the
-AuthDBGroupFile unless otherwise protected.<p>
+AuthDBGroupFile unless otherwise protected.<P>
 
 Combining Group and Password DB files: In some cases it is easier to
 manage a single database which contains both the password and group
 details for each user. This simplifies any support programs that need
 to be written: they now only have to deal with writing to and locking
 a single DBM file. This can be accomplished by first setting the group
-and password files to point to the same DB file:<p>
+and password files to point to the same DB file:<P>
 
-<blockquote><code>
-AuthDBGroupFile /www/userbase<br>
+<BLOCKQUOTE><CODE>
+AuthDBGroupFile /www/userbase<BR>
 AuthDBUserFile /www/userbase
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
-The key for the single DB record is the username. The value consists of <p>
+The key for the single DB record is the username. The value consists of <P>
 
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 Unix Crypt-ed Password : List of Groups [ : (ignored) ]
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
 The password section contains the Unix crypt() password as before. This is
 followed by a colon and the comma separated list of groups. Other data may
 optionally be left in the DB file after another colon; it is ignored by the
-authentication module. <p>
+authentication module. <P>
 
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authdbuserfile">AuthDBUserFile</A>.<p><hr>
+<A HREF="#authdbuserfile">AuthDBUserFile</A>.<P><HR>
 
 <A name="authdbuserfile"><h2>AuthDBUserFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBUserFile} directive&gt; -->
-<strong>Syntax:</strong> AuthDBUserFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_db<p>
+<STRONG>Syntax:</STRONG> AuthDBUserFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_db<P>
 
 The AuthDBUserFile directive sets the name of a DB file containing the list
-of users and passwords for user authentication. <em>Filename</em> is the
-absolute path to the user file.<p>
+of users and passwords for user authentication. <EM>Filename</EM> is the
+absolute path to the user file.<P>
 
 The user file is keyed on the username. The value for a user is the
 crypt() encrypted password, optionally followed by a colon and
 arbitrary data.  The colon and the data following it will be ignored
-by the server.<p>
+by the server.<P>
 
 Security: make sure that the AuthDBUserFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
+document tree of the web-server; do <EM>not</EM> put it in the directory that
 it protects. Otherwise, clients will be able to download the
-AuthDBUserFile.<p>
+AuthDBUserFile.<P>
 
 Important compatibility note: The implementation of "dbmopen" in the
 apache modules reads the string length of the hashed values from the
@@ -106,53 +106,53 @@ DB data structures, rather than relying upon the string being
 NULL-appended. Some applications, such as the Netscape web server,
 rely upon the string being NULL-appended, so if you are having trouble
 using DB files interchangeably between applications this may be a
-part of the problem. <p>
+part of the problem. <P>
 
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<p>
-<hr>
+<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<P>
+<HR>
 <A name="authdbauthoritative"><h2>AuthDBAuthoritative</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBAuthoritative} directive&gt; -->
-<strong>Syntax:</strong> AuthDBAuthoritative &lt; <strong> on</strong>(default) | off &gt; <br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_auth<p>
+<STRONG>Syntax:</STRONG> AuthDBAuthoritative &lt; <STRONG> on</STRONG>(default) | off &gt; <BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_auth<P>
 
-Setting the AuthDBAuthoritative directive explicitly to <b>'off'</b>
+Setting the AuthDBAuthoritative directive explicitly to <STRONG>'off'</STRONG>
 allows for both authentication and authorization to be passed on
-to lower level modules (as defined in the <code>Configuration</code>
-and <code>modules.c</code> file if there is <b>no userID</b> or
-<b>rule</b> matching the supplied userID. If there is a userID
+to lower level modules (as defined in the <CODE>Configuration</CODE>
+and <CODE>modules.c</CODE> file if there is <STRONG>no userID</STRONG> or
+<STRONG>rule</STRONG> matching the supplied userID. If there is a userID
 and/or rule specified; the usual password and access checks will
 be applied and a failure will give an Authorization Required reply.
-<p>
+<P>
 So if a userID appears in the database of more than one module; or
 if a valid require directive applies to more than one module; then
 the first module will verify the credentials; and no access is
-passed on; regardless of the AuthAuthoritative setting.  <p>
+passed on; regardless of the AuthAuthoritative setting.  <P>
 
 A common use for this is in conjunction with one of the basic auth
-modules; such as <a href="mod_auth.html"><code>mod_auth.c</code></a>.
+modules; such as <A HREF="mod_auth.html"><CODE>mod_auth.c</CODE></A>.
 Whereas this DB module supplies the bulk of the user credential
 checking; a few (administrator) related accesses fall through to
-a lower level with a well protected .htpasswd file.  <p>
+a lower level with a well protected .htpasswd file.  <P>
 
-<b>Default:</b> By default; control is not passed on; and an unknown
+<STRONG>Default:</STRONG> By default; control is not passed on; and an unknown
 userID or rule will result in an Authorization Required reply. Not
 setting it thus keeps the system secure; and forces an NSCA compliant
-behaviour.  <p>
+behaviour.  <P>
 Security: Do consider the implications of allowing a user to allow
 fall-through in his .htaccess file; and verify that this is really
 what you want; Generally it is easier to just secure a single
 .htpasswd file, than it is to secure a database which might have
 more access interfaces.
 
-<p>
+<P>
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<p>
+<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index a8fabb2b80f9ed9531e8af18fdcaa16b3f04b7d0..abc34a1ed4d908d442dbe34e2cde12f54eeefcf7 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Module mod_auth_dbm</h1>
+<H1 ALIGN="CENTER">Module mod_auth_dbm</H1>
 
-This module is contained in the <code>mod_auth_dbm.c</code> file, and
+This module is contained in the <CODE>mod_auth_dbm.c</CODE> file, and
 is not compiled in by default. It provides for user authentication using
 DBM files.
 
 
-<menu>
-<li><A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>
-<li><A HREF="#authdbmuserfile">AuthDBMUserFile</A>
-<li><A HREF="#authdbmauthoritative">AuthDBMAuthoritative</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>
+<LI><A HREF="#authdbmuserfile">AuthDBMUserFile</A>
+<LI><A HREF="#authdbmauthoritative">AuthDBMAuthoritative</A>
+</MENU>
+<HR>
 
 
 <A name="authdbmgroupfile"><h2>AuthDbmGroupFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDbmGroupFile} directive&gt; -->
-<strong>Syntax:</strong> AuthDBMGroupFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_dbm<p>
+<STRONG>Syntax:</STRONG> AuthDBMGroupFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_dbm<P>
 
 The AuthDBMGroupFile directive sets the name of a DBM file containing the list
-of user groups for user authentication. <em>Filename</em> is the absolute path
-to the group file.<p>
+of user groups for user authentication. <EM>Filename</EM> is the absolute path
+to the group file.<P>
 
 The group file is keyed on the username. The value for a user is a
 comma-separated list of the groups to which the users belongs. There must
-be no whitespace within the value, and it must never contain any colons.<p>
+be no whitespace within the value, and it must never contain any colons.<P>
 
 Security: make sure that the AuthDBMGroupFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
+document tree of the web-server; do <EM>not</EM> put it in the directory that
 it protects. Otherwise, clients will be able to download the
-AuthDBMGroupFile unless otherwise protected.<p>
+AuthDBMGroupFile unless otherwise protected.<P>
 
 Combining Group and Password DBM files: In some cases it is easier to
 manage a single database which contains both the password and group
 details for each user. This simplifies any support programs that need
 to be written: they now only have to deal with writing to and locking
 a single DBM file. This can be accomplished by first setting the group
-and password files to point to the same DBM:<p>
+and password files to point to the same DBM:<P>
 
-<blockquote><code>
-AuthDBMGroupFile /www/userbase<br>
+<BLOCKQUOTE><CODE>
+AuthDBMGroupFile /www/userbase<BR>
 AuthDBMUserFile /www/userbase
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
-The key for the single DBM is the username. The value consists of <p>
+The key for the single DBM is the username. The value consists of <P>
 
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 Unix Crypt-ed Password : List of Groups [ : (ignored) ]
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
 The password section contains the Unix crypt() password as before. This is
 followed by a colon and the comma separated list of groups. Other data may
 optionally be left in the DBM file after another colon; it is ignored by the
 authentication module. This is what www.telescope.org uses for its combined
-password and group database. <p>
+password and group database. <P>
 
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authdbmuserfile">AuthDBMUserFile</A>.<p><hr>
+<A HREF="#authdbmuserfile">AuthDBMUserFile</A>.<P><HR>
 
 <A name="authdbmuserfile"><h2>AuthDBMUserFile</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBMUserFile} directive&gt; -->
-<strong>Syntax:</strong> AuthDBMUserFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_auth_dbm<p>
+<STRONG>Syntax:</STRONG> AuthDBMUserFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_auth_dbm<P>
 
 The AuthDBMUserFile directive sets the name of a DBM file containing the list
-of users and passwords for user authentication. <em>Filename</em> is the
-absolute path to the user file.<p>
+of users and passwords for user authentication. <EM>Filename</EM> is the
+absolute path to the user file.<P>
 
 The user file is keyed on the username. The value for a user is the
 crypt() encrypted password, optionally followed by a colon and
 arbitrary data.  The colon and the data following it will be ignored
-by the server.<p>
+by the server.<P>
 
 Security: make sure that the AuthDBMUserFile is stored outside the
-document tree of the web-server; do <em>not</em> put it in the directory that
+document tree of the web-server; do <EM>not</EM> put it in the directory that
 it protects. Otherwise, clients will be able to download the
-AuthDBMUserFile.<p>
+AuthDBMUserFile.<P>
 
 Important compatibility note: The implementation of "dbmopen" in the
 apache modules reads the string length of the hashed values from the
@@ -106,44 +106,44 @@ DBM data structures, rather than relying upon the string being
 NULL-appended. Some applications, such as the Netscape web server,
 rely upon the string being NULL-appended, so if you are having trouble
 using DBM files interchangeably between applications this may be a
-part of the problem. <p>
+part of the problem. <P>
 
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<p>
+<A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<P>
 
-<hr>
+<HR>
 <A name="authdbmauthoritative"><h2>AuthDBMAuthoritative</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AuthDBMAuthoritative} directive&gt; -->
-<strong>Syntax:</strong> AuthDBMAuthoritative &lt; <strong> on</strong>(default) | off &gt; <br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_auth<p>
+<STRONG>Syntax:</STRONG> AuthDBMAuthoritative &lt; <STRONG> on</STRONG>(default) | off &gt; <BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_auth<P>
 
-Setting the AuthDBMAuthoritative directive explicitly to <b>'off'</b>
+Setting the AuthDBMAuthoritative directive explicitly to <STRONG>'off'</STRONG>
 allows for both authentication and authorization to be passed on
-to lower level modules (as defined in the <code>Configuration</code>
-and <code>modules.c</code> file if there is <b>no userID</b> or
-<b>rule</b> matching the supplied userID. If there is a userID
+to lower level modules (as defined in the <CODE>Configuration</CODE>
+and <CODE>modules.c</CODE> file if there is <STRONG>no userID</STRONG> or
+<STRONG>rule</STRONG> matching the supplied userID. If there is a userID
 and/or rule specified; the usual password and access checks will
 be applied and a failure will give an Authorization Required reply.
-<p>
+<P>
 So if a userID appears in the database of more than one module; or
 if a valid require directive applies to more than one module; then
 the first module will verify the credentials; and no access is
-passed on; regardless of the AuthAuthoritative setting.  <p>
+passed on; regardless of the AuthAuthoritative setting.  <P>
 
 A common use for this is in conjunction with one of the basic auth
-modules; such as <a href="mod_auth.html"><code>mod_auth.c</code></a>.
+modules; such as <A HREF="mod_auth.html"><CODE>mod_auth.c</CODE></A>.
 Whereas this DBM module supplies the bulk of the user credential
 checking; a few (administrator) related accesses fall through to
-a lower level with a well protected .htpasswd file.  <p>
+a lower level with a well protected .htpasswd file.  <P>
 
-<b>Default:</b> By default; control is not passed on; and an unknown
+<STRONG>Default:</STRONG> By default; control is not passed on; and an unknown
 userID or rule will result in an Authorization Required reply. Not
 setting it thus keeps the system secure; and forces an NSCA compliant
-behaviour.  <p>
+behaviour.  <P>
 
 Security: Do consider the implications of allowing a user to allow
 fall-through in his .htaccess file; and verify that this is really
@@ -151,10 +151,10 @@ what you want; Generally it is easier to just secure a single
 .htpasswd file, than it is to secure a database which might have
 more access interfaces.
 
-<p>
+<P>
 See also <A HREF="core.html#authname">AuthName</A>,
 <A HREF="core.html#authtype">AuthType</A> and
-<A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<p>
+<A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index b71ad7fdfadd094b255aee058bb4b3832dfbcf51..10c438158ad62fc1c75ef59fd3b508c8f9b2c2b5 100644 (file)
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Module mod_autoindex</H1>
 
-This module is contained in the <code>mod_autoindex.c</code> file, and
+This module is contained in the <CODE>mod_autoindex.c</CODE> file, and
 is compiled in by default. It provides for automatic directory indexing.
 
 <h2>Summary</h2>
 The index of a directory can come from one of two sources:
-<ul>
-<li>A file written by the user, typically called <code>index.html</code>.
+<UL>
+<LI>A file written by the user, typically called <CODE>index.html</CODE>.
 The <A HREF="mod_dir.html#directoryindex">DirectoryIndex</A> directive sets
 the name of this file.
-This is controlled by <a href="mod_dir.html"><code>mod_dir</code></a>.
-<li>Otherwise, a listing generated by the server. The other directives
+This is controlled by <A HREF="mod_dir.html"><CODE>mod_dir</CODE></A>.
+<LI>Otherwise, a listing generated by the server. The other directives
 control the format of this listing. The <A HREF="#addicon">AddIcon</A>,
 <A HREF="#addiconbyencoding">AddIconByEncoding</A> and
 <A HREF="#addiconbytype">AddIconByType</A> are used to set a list of
 icons to display for various file types; for each file listed, the
 first icon listed that matches the file is displayed.  These
-are controlled by <code>mod_autoindex</code>.
-</ul>
+are controlled by <CODE>mod_autoindex</CODE>.
+</UL>
 The two functions are separated so that you can completely remove
 (or replace) automatic index generation should you want to.
 <P>
@@ -61,241 +61,241 @@ order) even though they both are shown as &quot;1K&quot;.
 
 <h2>Directives</h2>
 
-<menu>
-<li><A HREF="#addalt">AddAlt</A>
-<li><A HREF="#addaltbyencoding">AddAltByEncoding</A>
-<li><A HREF="#addaltbytype">AddAltByType</A>
-<li><A HREF="#adddescription">AddDescription</A>
-<li><A HREF="#addicon">AddIcon</A>
-<li><A HREF="#addiconbyencoding">AddIconByEncoding</A>
-<li><A HREF="#addiconbytype">AddIconByType</A>
-<li><A HREF="#defaulticon">DefaultIcon</A>
-<li><A HREF="#fancyindexing">FancyIndexing</A>
-<li><A HREF="#headername">HeaderName</A>
-<li><A HREF="#indexignore">IndexIgnore</A>
-<li><A HREF="#indexoptions">IndexOptions</A>
-<li><A HREF="#readmename">ReadmeName</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#addalt">AddAlt</A>
+<LI><A HREF="#addaltbyencoding">AddAltByEncoding</A>
+<LI><A HREF="#addaltbytype">AddAltByType</A>
+<LI><A HREF="#adddescription">AddDescription</A>
+<LI><A HREF="#addicon">AddIcon</A>
+<LI><A HREF="#addiconbyencoding">AddIconByEncoding</A>
+<LI><A HREF="#addiconbytype">AddIconByType</A>
+<LI><A HREF="#defaulticon">DefaultIcon</A>
+<LI><A HREF="#fancyindexing">FancyIndexing</A>
+<LI><A HREF="#headername">HeaderName</A>
+<LI><A HREF="#indexignore">IndexIgnore</A>
+<LI><A HREF="#indexoptions">IndexOptions</A>
+<LI><A HREF="#readmename">ReadmeName</A>
+</MENU>
+<HR>
 
 <A name="addalt"><h2>AddAlt</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddAlt} directive&gt; -->
-<strong>Syntax:</strong> AddAlt <em>string file file...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> AddAlt <EM>string file file...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 This sets the alternate text to display for a file, instead of an icon, for
-<A HREF="#fancyindexing">FancyIndexing</A>. <em>File</em> is a file
+<A HREF="#fancyindexing">FancyIndexing</A>. <EM>File</EM> is a file
 extension, partial filename, wild-card expression or full filename for files
-to describe. <em>String</em> is enclosed in double quotes
-(<code>&quot;</code>).  This alternate text is displayed if the client is
+to describe. <EM>String</EM> is enclosed in double quotes
+(<CODE>&quot;</CODE>).  This alternate text is displayed if the client is
 image-incapable or has image loading disabled.
 
 <HR>
 <A name="addaltbyencoding"><h2>AddAltByEncoding</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddAltByEncoding} directive&gt; -->
-<strong>Syntax:</strong> AddAltByEncoding <em>string MIME-encoding
-    MIME-encoding...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> AddAltByEncoding <EM>string MIME-encoding
+    MIME-encoding...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 This sets the alternate text to display for a file, instead of an icon, for
-<A HREF="#fancyindexing">FancyIndexing</A>. <em>MIME-encoding</em> is a
+<A HREF="#fancyindexing">FancyIndexing</A>. <EM>MIME-encoding</EM> is a
 valid content-encoding, such as <SAMP>x-compress</SAMP>.
-<em>String</em> is enclosed in double quotes
-(<code>&quot;</code>).  This alternate text is displayed if the client is
+<EM>String</EM> is enclosed in double quotes
+(<CODE>&quot;</CODE>).  This alternate text is displayed if the client is
 image-incapable or has image loading disabled.
 
 <HR>
 <A name="addaltbytype"><h2>AddAltByType</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddAltByType} directive&gt; -->
-<strong>Syntax:</strong> AddAltByType <em>string MIME-type MIME-type...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> AddAltByType <EM>string MIME-type MIME-type...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 This sets the alternate text to display for a file, instead of an icon, for
-<A HREF="#fancyindexing">FancyIndexing</A>. <em>MIME-type</em> is a
+<A HREF="#fancyindexing">FancyIndexing</A>. <EM>MIME-type</EM> is a
 valid content-type, such as <SAMP>text/html</SAMP>.
-<em>String</em> is enclosed in double quotes
-(<code>&quot;</code>).  This alternate text is displayed if the client is
+<EM>String</EM> is enclosed in double quotes
+(<CODE>&quot;</CODE>).  This alternate text is displayed if the client is
 image-incapable or has image loading disabled.
 
 <HR>
 
 <A name="adddescription"><h2>AddDescription</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddDescription} directive&gt; -->
-<strong>Syntax:</strong> AddDescription <em>string file file...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> AddDescription <EM>string file file...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 This sets the description to display for a file, for
-<A HREF="#fancyindexing">FancyIndexing</A>. <em>File</em> is a file
+<A HREF="#fancyindexing">FancyIndexing</A>. <EM>File</EM> is a file
 extension, partial filename, wild-card expression or full filename for files
-to describe. <em>String</em> is enclosed in double quotes
-(<code>&quot;</code>). Example:
-<blockquote><code>AddDescription "The planet Mars" /web/pics/mars.gif
-</code></blockquote><p><hr>
+to describe. <EM>String</EM> is enclosed in double quotes
+(<CODE>&quot;</CODE>). Example:
+<BLOCKQUOTE><CODE>AddDescription "The planet Mars" /web/pics/mars.gif
+</CODE></BLOCKQUOTE><P><HR>
 
 <A name="addicon"><h2>AddIcon</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddIcon} directive&gt; -->
-<strong>Syntax:</strong> AddIcon <em>icon name name ...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
-
-This sets the icon to display next to a file ending in <em>name</em> for
-<A HREF="#fancyindexing">FancyIndexing</A>. <em>Icon</em> is either a
+<STRONG>Syntax:</STRONG> AddIcon <EM>icon name name ...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
+
+This sets the icon to display next to a file ending in <EM>name</EM> for
+<A HREF="#fancyindexing">FancyIndexing</A>. <EM>Icon</EM> is either a
 (%-escaped) relative URL to the icon, or of the format
-(<em>alttext</em>,<em>url</em>) where <em>alttext</em> is the text tag given
-for an icon for non-graphical browsers.<p>
+(<EM>alttext</EM>,<EM>url</EM>) where <EM>alttext</EM> is the text tag given
+for an icon for non-graphical browsers.<P>
 
-<em>Name</em> is either ^^DIRECTORY^^ for directories, ^^BLANKICON^^ for
+<EM>Name</EM> is either ^^DIRECTORY^^ for directories, ^^BLANKICON^^ for
 blank lines (to format the list correctly), a file extension, a wildcard
 expression, a partial filename or a complete filename. Examples:
-<blockquote><code>
-AddIcon (IMG,/icons/image.xbm) .gif .jpg .xbm <br>
-AddIcon /icons/dir.xbm ^^DIRECTORY^^ <br>
+<BLOCKQUOTE><CODE>
+AddIcon (IMG,/icons/image.xbm) .gif .jpg .xbm <BR>
+AddIcon /icons/dir.xbm ^^DIRECTORY^^ <BR>
 AddIcon /icons/backup.xbm *~
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 <A HREF="#addiconbytype">AddIconByType</A> should be used in preference to
-AddIcon, when possible.<p><hr>
+AddIcon, when possible.<P><HR>
 
 <A name="addiconbyencoding"><h2>AddIconByEncoding</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddIconByEncoding} directive&gt; -->
-<strong>Syntax:</strong> AddIconByEncoding <em>icon mime-encoding mime-encoding
-...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> AddIconByEncoding <EM>icon mime-encoding mime-encoding
+...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 This sets the icon to display next to files with
-<em>mime-encoding</em> for <A HREF="#fancyindexing">FancyIndexing</A>.
-<em>Icon</em> is either a (%-escaped) relative URL to the icon, or of the
-format (<em>alttext</em>,<em>url</em>) where <em>alttext</em> is the text tag
-given for an icon for non-graphical browsers.<p>
+<EM>mime-encoding</EM> for <A HREF="#fancyindexing">FancyIndexing</A>.
+<EM>Icon</EM> is either a (%-escaped) relative URL to the icon, or of the
+format (<EM>alttext</EM>,<EM>url</EM>) where <EM>alttext</EM> is the text tag
+given for an icon for non-graphical browsers.<P>
 
-<em>Mime-encoding</em> is a wildcard expression matching required the
+<EM>Mime-encoding</EM> is a wildcard expression matching required the
 content-encoding. Examples:
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 AddIconByEncoding /icons/compress.xbm x-compress
-</code></blockquote><p><hr>
+</CODE></BLOCKQUOTE><P><HR>
 
 <A name="addiconbytype"><h2>AddIconByType</h2></A>
 <!--%plaintext &lt;?INDEX {\tt AddIconByType} directive&gt; -->
-<strong>Syntax:</strong> AddIconByType <em>icon mime-type mime-type ...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
-
-This sets the icon to display next to files of type <em>mime-type</em> for
-<A HREF="#fancyindexing">FancyIndexing</A>. <em>Icon</em> is either a
+<STRONG>Syntax:</STRONG> AddIconByType <EM>icon mime-type mime-type ...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
+
+This sets the icon to display next to files of type <EM>mime-type</EM> for
+<A HREF="#fancyindexing">FancyIndexing</A>. <EM>Icon</EM> is either a
 (%-escaped) relative URL to the icon, or of the format
-(<em>alttext</em>,<em>url</em>) where <em>alttext</em> is the text tag given
-for an icon for non-graphical browsers.<p>
-<em>Mime-type</em> is a wildcard expression matching required the mime types.
+(<EM>alttext</EM>,<EM>url</EM>) where <EM>alttext</EM> is the text tag given
+for an icon for non-graphical browsers.<P>
+<EM>Mime-type</EM> is a wildcard expression matching required the mime types.
 Examples:
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 AddIconByType (IMG,/icons/image.xbm) image/*
-</code></blockquote><p><hr>
+</CODE></BLOCKQUOTE><P><HR>
 
 <A name="defaulticon"><h2>DefaultIcon</h2></A>
 <!--%plaintext &lt;?INDEX {\tt DefaultIcon} directive&gt; -->
-<strong>Syntax:</strong> DefaultIcon <em>url</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> DefaultIcon <EM>url</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 The DefaultIcon directive sets the icon to display for files when no
 specific icon is known, for <A HREF="#fancyindexing">FancyIndexing</A>.
-<em>Url</em> is a (%-escaped) relative URL to the icon. Examples:
-<blockquote><code>
+<EM>Url</EM> is a (%-escaped) relative URL to the icon. Examples:
+<BLOCKQUOTE><CODE>
 DefaultIcon /icon/unknown.xbm
-</code></blockquote><p><hr>
+</CODE></BLOCKQUOTE><P><HR>
 
 <A name="fancyindexing"><h2>FancyIndexing</h2></A>
 <!--%plaintext &lt;?INDEX {\tt FancyIndexing} directive&gt; -->
-<strong>Syntax:</strong> FancyIndexing <em>boolean</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex
-<p>
+<STRONG>Syntax:</STRONG> FancyIndexing <EM>boolean</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex
+<P>
 The FancyIndexing directive sets the FancyIndexing option for a directory.
-<em>Boolean</em> can be <code>on</code> or <code>off</code>. The
+<EM>Boolean</EM> can be <CODE>on</CODE> or <CODE>off</CODE>. The
 <A HREF="#indexoptions">IndexOptions</A> directive should be used in
 preference.
-</p>
+</P>
 <BLOCKQUOTE>
  <STRONG>Note that the <SAMP>FancyIndexing</SAMP> and
  <SAMP>IndexOptions</SAMP> directives will override each other. You
  should use <SAMP>IndexOptions&nbsp;FancyIndexing</SAMP> in preference
  to the standalone <SAMP>FancyIndexing</SAMP> directive.</STRONG>
 </BLOCKQUOTE>
-<hr>
+<HR>
 
 <A name="headername"><h2>HeaderName</h2></A>
 <!--%plaintext &lt;?INDEX {\tt HeaderName} directive&gt; -->
-<strong>Syntax:</strong> HeaderName <em>filename</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> HeaderName <EM>filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 The HeaderName directive sets the name of the file that will be inserted
-at the top of the index listing. <em>Filename</em> is the name of the file
+at the top of the index listing. <EM>Filename</EM> is the name of the file
 to include, and is taken to be relative to the directory being indexed.
-The server first attempts to include <em>filename</em><code>.html</code>
-as an HTML document, otherwise it will include <em>filename</em> as plain
+The server first attempts to include <EM>filename</EM><CODE>.html</CODE>
+as an HTML document, otherwise it will include <EM>filename</EM> as plain
 text. Example:
-<blockquote><code>HeaderName HEADER</code></blockquote>
-when indexing the directory <code>/web</code>, the server will first look for
-the HTML file <code>/web/HEADER.html</code> and include it if found, otherwise
-it will include the plain text file <code>/web/HEADER</code>, if it exists.
+<BLOCKQUOTE><CODE>HeaderName HEADER</CODE></BLOCKQUOTE>
+when indexing the directory <CODE>/web</CODE>, the server will first look for
+the HTML file <CODE>/web/HEADER.html</CODE> and include it if found, otherwise
+it will include the plain text file <CODE>/web/HEADER</CODE>, if it exists.
 
-<p>See also <A HREF="#readmename">ReadmeName</A>.<p><hr>
+<P>See also <A HREF="#readmename">ReadmeName</A>.<P><HR>
 
 <A name="indexignore"><h2>IndexIgnore</h2></A>
 <!--%plaintext &lt;?INDEX {\tt IndexIgnore} directive&gt; -->
-<strong>Syntax:</strong> IndexIgnore <em>file file ...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> IndexIgnore <EM>file file ...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 The IndexIgnore directive adds to the list of files to hide when listing
-a directory. <em>File</em> is a file extension, partial filename,
+a directory. <EM>File</EM> is a file extension, partial filename,
 wildcard expression or full filename for files to ignore. Multiple
 IndexIgnore directives add to the list, rather than the replacing the list
-of ignored files. By default, the list contains `<code>.</code>'. Example:
-<blockquote><code>
+of ignored files. By default, the list contains `<CODE>.</CODE>'. Example:
+<BLOCKQUOTE><CODE>
 IndexIgnore README .htaccess *~
-</code></blockquote><p><hr>
+</CODE></BLOCKQUOTE><P><HR>
 
 <A name="indexoptions"><h2>IndexOptions</h2></A>
 <!--%plaintext &lt;?INDEX {\tt IndexOptions} directive&gt; -->
-<strong>Syntax:</strong> IndexOptions <em>option option ...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> IndexOptions <EM>option option ...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 The IndexOptions directive specifies the behavior of the directory indexing.
-<em>Option</em> can be one of
-<dl>
-<dt>FancyIndexing
-<dd><!--%plaintext &lt;?INDEX {\tt FancyIndexing} index option&gt; -->
+<EM>Option</EM> can be one of
+<DL>
+<DT>FancyIndexing
+<DD><!--%plaintext &lt;?INDEX {\tt FancyIndexing} index option&gt; -->
 This turns on fancy indexing of directories.
 <BLOCKQUOTE>
  <STRONG>Note that the <SAMP>FancyIndexing</SAMP> and
@@ -303,8 +303,8 @@ This turns on fancy indexing of directories.
  should use <SAMP>IndexOptions&nbsp;FancyIndexing</SAMP> in preference
  to the standalone <SAMP>FancyIndexing</SAMP> directive.</STRONG>
 </BLOCKQUOTE>
-<dt>IconHeight[=pixels] (<EM>Apache 1.3 and later</EM>)
-<dd>
+<DT>IconHeight[=pixels] (<EM>Apache 1.3 and later</EM>)
+<DD>
 <!--%plaintext &lt;?INDEX {\tt IconHeight} index option&gt; -->
 Presence of this option, when used with IconWidth, will cause the server
 to include <SAMP>HEIGHT</SAMP> and <SAMP>WIDTH</SAMP> attributes in the
@@ -313,13 +313,13 @@ precalculate the page layout without having to wait until all the
 images have been loaded.  If no value is given for the option, it
 defaults to the standard height of the icons supplied with the Apache
 software.
-<dt>IconsAreLinks
-<dd>
+<DT>IconsAreLinks
+<DD>
 <!--%plaintext &lt;?INDEX {\tt IconsAreLinks} index option&gt; -->
 This makes the icons part of the anchor for the filename, for
 fancy indexing.
-<dt>IconWidth[=pixels] (<EM>Apache 1.3 and later</EM>)
-<dd>
+<DT>IconWidth[=pixels] (<EM>Apache 1.3 and later</EM>)
+<DD>
 <!--%plaintext &lt;?INDEX {\tt IconWidth} index option&gt; -->
 Presence of this option, when used with IconHeight, will cause the server
 to include <SAMP>HEIGHT</SAMP> and <SAMP>WIDTH</SAMP> attributes in the
@@ -328,8 +328,8 @@ precalculate the page layout without having to wait until all the
 images have been loaded.  If no value is given for the option, it
 defaults to the standard width of the icons supplied with the Apache
 software.
-<dt>ScanHTMLTitles
-<dd><!--%plaintext &lt;?INDEX {\tt ScanHTMLTitles} index option&gt; -->
+<DT>ScanHTMLTitles
+<DD><!--%plaintext &lt;?INDEX {\tt ScanHTMLTitles} index option&gt; -->
 This enables the extraction of the title from HTML documents for fancy
 indexing. If the file does not have a description given by
 <A HREF="#adddescription">AddDescription</A> then httpd will read the
@@ -342,12 +342,12 @@ directory listing into links for sorting.  The default behaviour is
 for them to be links; selecting the column heading will sort the directory
 listing by the values in that column.
 <STRONG>Only available in Apache 1.3 and later.</STRONG>
-<dt>SuppressDescription
-<dd>
+<DT>SuppressDescription
+<DD>
 <!--%plaintext &lt;?INDEX {\tt SuppressDescription} index option&gt; -->
 This will suppress the file description in fancy indexing listings.
-<dt>SuppressHTMLPreamble
-<dd>
+<DT>SuppressHTMLPreamble
+<DD>
 <!--%plaintext &lt;?INDEX {\tt SuppressHTMLPreamble} index option&gt; -->
 If the directory actually contains a file specified by the
 <A
@@ -359,50 +359,50 @@ cetera</EM>).  The SuppressHTMLPreamble option disables this behaviour,
 causing the module to start the display with the header file contents.
 The header file must contain appropriate HTML instructions in this case.
 If there is no header file, the preamble is generated as usual.
-<dt>SuppressLastModified
-<dd>
+<DT>SuppressLastModified
+<DD>
 <!--%plaintext &lt;?INDEX {\tt SuppressLastModified} index option&gt; -->
 This will suppress the display of the last modification date, in fancy
 indexing listings.
-<dt>SuppressSize
-<dd>
+<DT>SuppressSize
+<DD>
 <!--%plaintext &lt;?INDEX {\tt SuppressSize} index option&gt; -->
 This will suppress the file size in fancy indexing listings.
-</dl>
+</DL>
 This default is that no options are enabled. If multiple IndexOptions
 could apply to a directory, then the most specific one is taken complete;
 the options are not merged. For example:
-<blockquote><code>
-&lt;Directory /web/docs&gt; <br>
-IndexOptions FancyIndexing <br>
-&lt;/Directory&gt;<br>
-&lt;Directory /web/docs/spec&gt; <br>
-IndexOptions ScanHTMLTitles <br>
+<BLOCKQUOTE><CODE>
+&lt;Directory /web/docs&gt; <BR>
+IndexOptions FancyIndexing <BR>
+&lt;/Directory&gt;<BR>
+&lt;Directory /web/docs/spec&gt; <BR>
+IndexOptions ScanHTMLTitles <BR>
 &lt;/Directory&gt;
-</code></blockquote>
-then only <code>ScanHTMLTitles</code> will be set for the /web/docs/spec
-directory.<p><hr>
+</CODE></BLOCKQUOTE>
+then only <CODE>ScanHTMLTitles</CODE> will be set for the /web/docs/spec
+directory.<P><HR>
 
 <A name="readmename"><h2>ReadmeName</h2></A>
 <!--%plaintext &lt;?INDEX {\tt ReadmeName} directive&gt; -->
-<strong>Syntax:</strong> ReadmeName <em>filename</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_autoindex<p>
+<STRONG>Syntax:</STRONG> ReadmeName <EM>filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_autoindex<P>
 
 The ReadmeName directive sets the name of the file that will be appended
-to the end of the index listing. <em>Filename</em> is the name of the file
+to the end of the index listing. <EM>Filename</EM> is the name of the file
 to include, and is taken to be relative to the directory being indexed.
-The server first attempts to include <em>filename</em><code>.html</code>
-as an HTML document, otherwise it will include <em>filename</em> as plain
+The server first attempts to include <EM>filename</EM><CODE>.html</CODE>
+as an HTML document, otherwise it will include <EM>filename</EM> as plain
 text. Example:
-<blockquote><code>ReadmeName README</code></blockquote>
-when indexing the directory <code>/web</code>, the server will first look for
-the HTML file <code>/web/README.html</code> and include it if found, otherwise
-it will include the plain text file <code>/web/README</code>, if it exists.
+<BLOCKQUOTE><CODE>ReadmeName README</CODE></BLOCKQUOTE>
+when indexing the directory <CODE>/web</CODE>, the server will first look for
+the HTML file <CODE>/web/README.html</CODE> and include it if found, otherwise
+it will include the plain text file <CODE>/web/README</CODE>, if it exists.
 
-<p>See also <A HREF="#headername">HeaderName</A>.<p>
+<P>See also <A HREF="#headername">HeaderName</A>.<P>
 
 
 <!--#include virtual="footer.html" -->
index 127ca3ef2b26337053967c3b438d9b3bc5e62114..9e311e334591670fc539c3027f82ce88658c93c4 100644 (file)
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache module mod_cern_meta</h1>
+<H1 ALIGN="CENTER">Apache module mod_cern_meta</H1>
 
-This module is contained in the <code>mod_cern_meta.c</code> file, and
+This module is contained in the <CODE>mod_cern_meta.c</CODE> file, and
 is not compiled in by default. It provides for CERN httpd metafile
 semantics. It is only available in Apache 1.1 and later.
 
@@ -30,64 +30,64 @@ There are many ways to manage meta information, this one was
 chosen because there is already a large number of CERN users
 who can exploit this module.
 
-<p>More information on the
-<a href="http://www.w3.org/pub/WWW/Daemon/User/Config/General.html#MetaDir
-">CERN metafile semantics</a> is available.
+<P>More information on the
+<A HREF="http://www.w3.org/pub/WWW/Daemon/User/Config/General.html#MetaDir
+">CERN metafile semantics</A> is available.
 
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#metafiles">MetaFiles</A>
-<li><A HREF="#metadir">MetaDir</A>
-<li><A HREF="#metasuffix">MetaSuffix</A>
-</ul>
+<UL>
+<LI><A HREF="#metafiles">MetaFiles</A>
+<LI><A HREF="#metadir">MetaDir</A>
+<LI><A HREF="#metasuffix">MetaSuffix</A>
+</UL>
 
-<hr>
+<HR>
 
 <h2><A name="metafiles">MetaFiles</A></h2>
-<strong>Syntax:</strong> MetaFiles <em>on/off</em><br>
-<strong>Default:</strong> <code>MetaFiles off</code><br>
-<strong>Context:</strong> per-directory config<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_cern_meta<br>
-<strong>Compatibility:</strong> MetaFiles is only available in Apache 1.3
-and later.<p>
+<STRONG>Syntax:</STRONG> MetaFiles <EM>on/off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MetaFiles off</CODE><BR>
+<STRONG>Context:</STRONG> per-directory config<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_cern_meta<BR>
+<STRONG>Compatibility:</STRONG> MetaFiles is only available in Apache 1.3
+and later.<P>
 
 Turns on/off Meta file processing on a per-directory basis. This option was introduced in Apache 1.3.
 
 <h2><A name="metadir">MetaDir</A></h2>
-<strong>Syntax:</strong> MetaDir <em>directory name</em><br>
-<strong>Default:</strong> <code>MetaDir .web</code><br>
-<strong>Context: (Apache prior to 1.3)</strong> server config<br>
-<strong>Context: (Apache 1.3)</strong> per-directory config<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_cern_meta<br>
-<strong>Compatibility:</strong> MetaDir is only available in Apache 1.1
-and later.<p>
+<STRONG>Syntax:</STRONG> MetaDir <EM>directory name</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MetaDir .web</CODE><BR>
+<STRONG>Context: (Apache prior to 1.3)</STRONG> server config<BR>
+<STRONG>Context: (Apache 1.3)</STRONG> per-directory config<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_cern_meta<BR>
+<STRONG>Compatibility:</STRONG> MetaDir is only available in Apache 1.1
+and later.<P>
 
 Specifies the name of the directory in which Apache can find
 meta information files.  The directory is usually a 'hidden'
 subdirectory of the directory that contains the file being
-accessed. Set to "<code>.</code>" to look in the same directory as the
+accessed. Set to "<CODE>.</CODE>" to look in the same directory as the
 file.
 
 <h2><A name="metasuffix">MetaSuffix</A></h2>
-<strong>Syntax:</strong> MetaSuffix <em>suffix</em><br>
-<strong>Default:</strong> <code>MetaSuffix .meta</code><br>
-<strong>Context: (Apache prior to 1.3)</strong> server config<br>
-<strong>Context: (Apache 1.3)</strong> per-directory config<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_cern_meta<br>
-<strong>Compatibility:</strong> MetaSuffix is only available in Apache 1.1
-and later.<p>
+<STRONG>Syntax:</STRONG> MetaSuffix <EM>suffix</EM><BR>
+<STRONG>Default:</STRONG> <CODE>MetaSuffix .meta</CODE><BR>
+<STRONG>Context: (Apache prior to 1.3)</STRONG> server config<BR>
+<STRONG>Context: (Apache 1.3)</STRONG> per-directory config<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_cern_meta<BR>
+<STRONG>Compatibility:</STRONG> MetaSuffix is only available in Apache 1.1
+and later.<P>
 
 Specifies the file name suffix for the file containing the
 meta information. For example, the default values for the two
-directives will cause a request to <code>
-DOCUMENT_ROOT/somedir/index.html</code> to look in
-<code>DOCUMENT_ROOT/somedir/.web/index.html.meta</code> and  will use
+directives will cause a request to <CODE>
+DOCUMENT_ROOT/somedir/index.html</CODE> to look in
+<CODE>DOCUMENT_ROOT/somedir/.web/index.html.meta</CODE> and  will use
 its contents to generate additional MIME header information.
 
-<p>
+<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index cb45cc853ffefe64b450d0a7cacbf1333276f31e..0447f881ddce00f89779dcc0d3d31b2f3c3b2e84 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache module mod_cgi</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache module mod_cgi</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
 >
 <!--#include virtual="header.html" -->
 
-<h1 ALIGN="CENTER">Module mod_cgi</h1>
+<h1 ALIGN="CENTER">Module mod_cgi</H1>
 
-This module is contained in the <code>mod_cgi.c</code> file, and
+This module is contained in the <CODE>mod_cgi.c</CODE> file, and
 is compiled in by default. It provides for execution of CGI scripts.
-Any file with mime type <code>application/x-httpd-cgi</code> will be
+Any file with mime type <CODE>application/x-httpd-cgi</CODE> will be
 processed by this module.
 <!--%plaintext &lt;?INDEX {\tt application/x-httpd-cgi} mime type&gt; -->
 <!--%plaintext &lt;?INDEX CGI scripts&gt; -->
 
 <h2>Summary</h2>
-Any file that has the mime type <code>application/x-httpd-cgi</code>
-or handler <code>cgi-script</code> (Apache 1.1 or later)
+Any file that has the mime type <CODE>application/x-httpd-cgi</CODE>
+or handler <CODE>cgi-script</CODE> (Apache 1.1 or later)
 will be treated as a CGI script, and run by the server, with its output
 being returned to the client. Files acquire this type either by
 having a name ending in an extension defined by the
 <A HREF="mod_mime.html#addtype">AddType</A> directive, or by being in
-a <A HREF="mod_alias.html#scriptalias">ScriptAlias</A> directory. <p>
+a <A HREF="mod_alias.html#scriptalias">ScriptAlias</A> directory. <P>
 
 When the server invokes a CGI script, it will add a variable called
-<code>DOCUMENT_ROOT</code> to the environment. This variable will contain the
+<CODE>DOCUMENT_ROOT</CODE> to the environment. This variable will contain the
 value of the <A HREF="core.html#documentroot">DocumentRoot</A>
 configuration variable.
 
@@ -41,21 +41,21 @@ configuration variable.
 The server will set the CGI environment variables as described in the
 <A HREF="http://hoohoo.ncsa.uiuc.edu/cgi/">CGI specification</A>, with the
 following provisions:
-<dl>
-<dt>REMOTE_HOST
-<dd>This will only be set if the server has not been compiled with
-<code>MINIMAL_DNS</code>.
-<dt>REMOTE_IDENT
-<dd>This will only be set if
-<A HREF="core.html#identitycheck">IdentityCheck</A> is set to <code>on</code>.
-<dt>REMOTE_USER
-<dd>This will only be set if the CGI script is subject to authentication.
-</dl>
+<DL>
+<DT>REMOTE_HOST
+<DD>This will only be set if the server has not been compiled with
+<CODE>MINIMAL_DNS</CODE>.
+<DT>REMOTE_IDENT
+<DD>This will only be set if
+<A HREF="core.html#identitycheck">IdentityCheck</A> is set to <CODE>on</CODE>.
+<DT>REMOTE_USER
+<DD>This will only be set if the CGI script is subject to authentication.
+</DL>
 <P>
 
-<hr>
+<HR>
 
-<h2><a name="cgi_debug">CGI Debugging</a></h2>
+<h2><A name="cgi_debug">CGI Debugging</A></h2>
 
 Debugging CGI scripts has traditionally been difficult, mainly because
 it has
@@ -66,7 +66,7 @@ which are failing to run properly. These directives, included in
 Apache 1.2 and later, provide
 more detailed logging of errors when they occur.
 
-<hr>
+<HR>
 
 <h2>CGI Logfile Format</h2>
 
@@ -75,53 +75,53 @@ properly.  Each CGI script which fails to operate causes several lines
 of information to be logged. The first two lines are always of the
 format:
 
-<pre>
-  %% [<i>time</i>] <i>request-line</i>
-  %% <i>HTTP-status</i> <i>CGI-script-filename</i>
-</pre>
+<PRE>
+  %% [<EM>time</EM>] <EM>request-line</EM>
+  %% <EM>HTTP-status</EM> <EM>CGI-script-filename</EM>
+</PRE>
 
 If the error is that CGI script cannot be run, the log file will
 contain
 an extra two lines:
 
-<pre>
+<PRE>
   %%error
-  <i>error-message</i>
-</pre>
+  <EM>error-message</EM>
+</PRE>
 
 Alternatively, if the error is the result of the script returning
 incorrect header information (often due to a bug in the script), the
 following information is logged:
 
-<pre>
+<PRE>
   %request
-  <i>All HTTP request headers received</i>
-  <i>POST or PUT entity (if any)</i>
+  <EM>All HTTP request headers received</EM>
+  <EM>POST or PUT entity (if any)</EM>
   %response
-  <i>All headers output by the CGI script</i>
+  <EM>All headers output by the CGI script</EM>
   %stdout
-  <i>CGI standard output</i>
+  <EM>CGI standard output</EM>
   %stderr
-  <i>CGI standard error</i>
-</pre>
+  <EM>CGI standard error</EM>
+</PRE>
 
 (The %stdout and %stderr parts may  be missing if the script did not
 output
 anything on standard output or standard error).
 
-<hr>
+<HR>
 
 <h2>Directives</h2>
 
-<h3><a name="scriptlog">ScriptLog</a></h3>
+<h3><A name="scriptlog">ScriptLog</A></h3>
 
-<b>Syntax:</b> ScriptLog <i>filename</i><br>
-<b>Default:</b> none<br>
-<b>Context:</b> resource config<br>
-<b>Status:</b> mod_cgi
-<p>
+<STRONG>Syntax:</STRONG> ScriptLog <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> none<BR>
+<STRONG>Context:</STRONG> resource config<BR>
+<STRONG>Status:</STRONG> mod_cgi
+<P>
 
-The <tt>ScriptLog</tt> directive sets the CGI script error logfile.
+The <TT>ScriptLog</TT> directive sets the CGI script error logfile.
 If no ScriptLog is given, no error log is created. If given, any
 CGI errors are logged into the filename given as argument. If this
 is a relative file or path it is taken relative to the server root.
@@ -135,34 +135,34 @@ script log in your main logs directory, do <STRONG>NOT</STRONG>
 change the directory permissions to make it writable by the user
 the child processes run as.</P>
 
-<p>Note that script logging is meant to be a debugging feature when
+<P>Note that script logging is meant to be a debugging feature when
 writing CGI scripts, and is not meant to be activated continuously on
 running servers. It is not optimized for speed or efficiency, and may
 have security problems if used in a manner other than that for which
-it was designed.</p>
+it was designed.</P>
 
-<h3><a name="scriptloglength">ScriptLogLength</a></h3>
+<h3><A name="scriptloglength">ScriptLogLength</A></h3>
 
-<b>Syntax:</b> ScriptLogLength <i>size</i><br>
-<b>Default:</b> 10385760<br>
-<b>Context:</b> resource config<br>
-<b>Status:</b> mod_cgi
-<p>
+<STRONG>Syntax:</STRONG> ScriptLogLength <EM>size</EM><BR>
+<STRONG>Default:</STRONG> 10385760<BR>
+<STRONG>Context:</STRONG> resource config<BR>
+<STRONG>Status:</STRONG> mod_cgi
+<P>
 
-<tt>ScriptLogLength</tt> can be used to limit the size of the CGI
+<TT>ScriptLogLength</TT> can be used to limit the size of the CGI
 script logfile.  Since the logfile logs a lot of information per CGI
 error (all request headers, all script output) it can grow to be a big
 file. To prevent problems due to unbounded growth, this directive can
 be used to set an maximum file-size for the CGI logfile. If the file
 exceeds this size, no more information will be written to it.
 
-<h3><a name="scriptlogbuffer">ScriptLogBuffer</a></h3>
+<h3><A name="scriptlogbuffer">ScriptLogBuffer</A></h3>
 
-<b>Syntax:</b> ScriptLogBuffer <i>size</i><br>
-<b>Default:</b> 1024<br>
-<b>Context:</b> resource config<br>
-<b>Status:</b> mod_cgi
-<p>
+<STRONG>Syntax:</STRONG> ScriptLogBuffer <EM>size</EM><BR>
+<STRONG>Default:</STRONG> 1024<BR>
+<STRONG>Context:</STRONG> resource config<BR>
+<STRONG>Status:</STRONG> mod_cgi
+<P>
 
 The size of any PUT or POST entity body that is logged to the file is
 limited, to prevent the log file growing too big too quickly if large
index 4d1c461d808f18665afcb454a66bf947dade0c5e..9fc99ab2d30437291e57c1f0e7ea3b1a47a3b642 100644 (file)
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Module mod_dir</H1>
 
-This module is contained in the <code>mod_dir.c</code> file, and
+This module is contained in the <CODE>mod_dir.c</CODE> file, and
 is compiled in by default.  It provides for "trailing slash" redirects and
 serving directory index files.
 
 <h2>Summary</h2>
 The index of a directory can come from one of two sources:
-<ul>
-<li>A file written by the user, typically called <code>index.html</code>.
+<UL>
+<LI>A file written by the user, typically called <CODE>index.html</CODE>.
 The <A HREF="#directoryindex">DirectoryIndex</A> directive sets
 the name of this file.
-This is controlled by <code>mod_dir</code>.
-<li>Otherwise, a listing generated by the server.  This is provided by
-<a href="mod_autoindex.html"><code>mod_autoindex</code></a>.
-</ul>
+This is controlled by <CODE>mod_dir</CODE>.
+<LI>Otherwise, a listing generated by the server.  This is provided by
+<A HREF="mod_autoindex.html"><CODE>mod_autoindex</CODE></A>.
+</UL>
 The two functions are separated so that you can completely remove
 (or replace) automatic index generation should you want to.
-<p>A "trailing slash" redirect is issued when the server receives a
+<P>A "trailing slash" redirect is issued when the server receives a
 request for a URL <SAMP>http://servername/foo/dirname</SAMP> where
 <SAMP>dirname</SAMP> is a directory.  Directories require a trailing
-slash, so <code>mod_dir</code> issues a redirect to
+slash, so <CODE>mod_dir</CODE> issues a redirect to
 <SAMP>http://servername/foo/dirname/</SAMP>.
 
 <h2>Directives</h2>
 
-<menu>
-<li><A HREF="#directoryindex">DirectoryIndex</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#directoryindex">DirectoryIndex</A>
+</MENU>
+<HR>
 
 <A name="directoryindex"><h2>DirectoryIndex</h2></A>
 <!--%plaintext &lt;?INDEX {\tt DirectoryIndex} directive&gt; -->
-<strong>Syntax:</strong> DirectoryIndex <em>local-url local-url ...</em><br>
-<strong>Default:</strong> <code>DirectoryIndex index.html</code><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_dir<p>
+<STRONG>Syntax:</STRONG> DirectoryIndex <EM>local-url local-url ...</EM><BR>
+<STRONG>Default:</STRONG> <CODE>DirectoryIndex index.html</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_dir<P>
 
 The DirectoryIndex directive sets the list of resources to look for,
 when the client requests an index of the directory by specifying a /
-at the end of the a directory name. <em>Local-url</em> is the
+at the end of the a directory name. <EM>Local-url</EM> is the
 (%-encoded) URL of a document on the server relative to the requested
 directory; it is usually the name of a file in the directory. Several
 URLs may be given, in which case the server will return the first one
@@ -65,19 +65,19 @@ listing of the directory.
 <P>
 
 Example:
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 DirectoryIndex index.html
-</code></blockquote>
-then a request for <code>http://myserver/docs/</code> would return
-<code>http://myserver/docs/index.html</code> if it exists, or would list
-the directory if it did not. <p>
+</CODE></BLOCKQUOTE>
+then a request for <CODE>http://myserver/docs/</CODE> would return
+<CODE>http://myserver/docs/index.html</CODE> if it exists, or would list
+the directory if it did not. <P>
 
 Note that the documents do not need to be relative to the directory;
-<blockquote><code>
-DirectoryIndex index.html index.txt /cgi-bin/index.pl</code></blockquote>
-would cause the CGI script <code>/cgi-bin/index.pl</code> to be executed
-if neither <code>index.html</code> or <code>index.txt</code> existed in
-a directory.<p><hr>
+<BLOCKQUOTE><CODE>
+DirectoryIndex index.html index.txt /cgi-bin/index.pl</CODE></BLOCKQUOTE>
+would cause the CGI script <CODE>/cgi-bin/index.pl</CODE> to be executed
+if neither <CODE>index.html</CODE> or <CODE>index.txt</CODE> existed in
+a directory.<P><HR>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 7d6de71d8f236cad97f5b27abef5fcf86d91057d..4283b138db437a2cb6d5ae8887ba831ba5c3be1b 100644 (file)
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache module mod_env</h1>
+<H1 ALIGN="CENTER">Apache module mod_env</H1>
 
-This module is contained in the <code>mod_env.c</code> file, and
+This module is contained in the <CODE>mod_env.c</CODE> file, and
 is not compiled in by default. It provides for
 passing environment variables to CGI/SSI scripts. Is is only available
 in Apache 1.1 and later.
@@ -29,63 +29,63 @@ useful to web-admins who wish to migrate from CERN to Apache without
 rewriting all their scripts
 
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#passenv">PassEnv</A>
-<li><A HREF="#setenv">SetEnv</A>
-<li><A HREF="#unsetenv">UnsetEnv</A>
-</ul>
+<UL>
+<LI><A HREF="#passenv">PassEnv</A>
+<LI><A HREF="#setenv">SetEnv</A>
+<LI><A HREF="#unsetenv">UnsetEnv</A>
+</UL>
 
-<hr>
+<HR>
 
 <h2><A name="passenv">PassEnv</A></h2>
-<strong>Syntax:</strong> PassEnv <em>variable variable ...</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_env<br>
-<strong>Compatibility:</strong> PassEnv is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> PassEnv <EM>variable variable ...</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_env<BR>
+<STRONG>Compatibility:</STRONG> PassEnv is only available in
+Apache 1.1 and later.<P>
 
 Specifies one or more environment variables to pass to CGI scripts
 from the server's own environment. Example:
-<pre>
+<PRE>
     PassEnv LD_LIBRARY_PATH
-</pre>
+</PRE>
 
 <HR>
 
 <h2><A name="setenv">SetEnv</A></h2>
-<strong>Syntax:</strong> SetEnv <em>variable value</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_env<br>
-<strong>Compatibility:</strong> SetEnv is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> SetEnv <EM>variable value</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_env<BR>
+<STRONG>Compatibility:</STRONG> SetEnv is only available in
+Apache 1.1 and later.<P>
 
 Sets an environment variable, which is then passed on to CGI
 scripts. Example:
-<pre>
+<PRE>
     SetEnv SPECIAL_PATH /foo/bin
-</pre>
+</PRE>
 
-<hr>
+<HR>
 
 <h2><A name="unsetenv">UnsetEnv</A></h2>
-<strong>Syntax:</strong> UnsetEnv <em>variable variable ...</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_env<br>
-<strong>Compatibility:</strong> UnsetEnv is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> UnsetEnv <EM>variable variable ...</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_env<BR>
+<STRONG>Compatibility:</STRONG> UnsetEnv is only available in
+Apache 1.1 and later.<P>
 
 Removes one or more environment variables from those passed on to
 CGI scripts. Example:
-<pre>
+<PRE>
     UnsetEnv LD_LIBRARY_PATH
-</pre>
+</PRE>
 
 
 
-<p>
+<P>
 <!--#include virtual="footer.html" -->
 </BODY>
 </HTML>
index 26004e37c0cc61739014b739726b994edd7a9b0e..f582dd45d25641da922a64ffe563b19aa1e79317 100644 (file)
@@ -12,7 +12,7 @@
   ALINK="#FF0000"
  >
   <!--#include virtual="header.html" -->
-  <H1 ALIGN="CENTER">Module mod_example</h1>
+  <H1 ALIGN="CENTER">Module mod_example</H1>
   <P>
   This module is contained in the <CODE>modules/mod_example.c</CODE> file, and
   <STRONG>is not</STRONG> compiled in by default.  It illustrates many of
index df2782469aa3779db2973ab84d5d187ed67105fe..a6f1914fe2c0d372c9e5b988d8342ffdc13df9c1 100644 (file)
   <STRONG>Syntax:</STRONG> ExpiresActive <EM>boolean</EM>
   <BR>
   <STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess
-  <br>
+  <BR>
   <STRONG>Override:</STRONG> Indexes
-  <br>
+  <BR>
   <STRONG>Status:</STRONG> Extension
-  <br>
+  <BR>
   <STRONG>Module:</STRONG> mod_expires
   </P>
   <P>
   <STRONG>Syntax:</STRONG> ExpiresByType <EM>mime-type &lt;code&gt;seconds</EM>
   <BR>
   <STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess
-  <br>
+  <BR>
   <STRONG>Override:</STRONG> Indexes
-  <br>
+  <BR>
   <STRONG>Status:</STRONG> Extension
-  <br>
+  <BR>
   <STRONG>Module:</STRONG> mod_expires
   </P>
   <P>
   <STRONG>Syntax:</STRONG> ExpiresDefault <EM>&lt;code&gt;seconds</EM>
   <BR>
   <STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess
-  <br>
+  <BR>
   <STRONG>Override:</STRONG> Indexes
-  <br>
+  <BR>
   <STRONG>Status:</STRONG> Extension
-  <br>
+  <BR>
   <STRONG>Module:</STRONG> mod_expires
   </P>
   <P>
index 12b8490cdf23c4a5ac454c0436e84ce511e7f632..e5745b2bbcbcd739c84accb7230bbacf8d18a03d 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Module mod_headers</h1>
+<h1 ALIGN="CENTER">Module mod_headers</H1>
 
 The optional headers module allows for the customization of HTTP
 response headers. Headers can be merged, replaced or removed. The
 directives described in this document are only available if Apache is
-compiled with <b>mod_headers.c</b>.
+compiled with <STRONG>mod_headers.c</STRONG>.
 
-<hr>
+<HR>
 
 <h2>Directive</h2>
-<ul>
-<li><A HREF="#header">Header</A>
-</ul>
+<UL>
+<LI><A HREF="#header">Header</A>
+</UL>
 
-<hr>
+<HR>
 
 <h2><A name="header">Header</A></h2>
-<strong>Syntax:</strong> Header [ set | append | add ] <em>header</em> <em>value</em><br>
-<strong>Syntax:</strong> Header unset <em>header</em><br>
-<strong>Context:</strong> server config, virtual host, access.conf, .htaccess<br>
-<strong>Status:</strong> optional<br>
-<strong>Module:</strong> mod_header<p>
+<STRONG>Syntax:</STRONG> Header [ set | append | add ] <EM>header</EM> <EM>value</EM><BR>
+<STRONG>Syntax:</STRONG> Header unset <EM>header</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, access.conf, .htaccess<BR>
+<STRONG>Status:</STRONG> optional<BR>
+<STRONG>Module:</STRONG> mod_header<P>
 
 This directive can replace, merge or remove HTTP response headers. The
 action it performs is determined by the first argument. This can be one
 of the following values:
 
-<ul>
-<li><b>set</b><br>
+<UL>
+<LI><STRONG>set</STRONG><BR>
   The response header is set, replacing any previous header with this name
 
-<li><b>append</b><br>
+<LI><STRONG>append</STRONG><BR>
   The response header is appended to any existing header of the same
   name. When a new value is merged onto an existing header it is
   separated from the existing header with a comma. This is the HTTP standard
   way of giving a header multiple values.
 
-<li><b>add</b><br>
+<LI><STRONG>add</STRONG><BR>
   The response header is added to the existing set of headers, even if
   this header already exists. This can result in two (or more) headers
   having the same name. This can lead to unforeseen consequences, and in
   general "append" should be used instead.
 
-<li><b>unset</b><br>
+<LI><STRONG>unset</STRONG><BR>
   The response header of this name is removed, if it exists. If there are
   multiple headers of the same name, only the first one set will be removed.
-</ul>
+</UL>
 
 This argument is followed by a header name, which can include the
 final colon, but it is not required. Case is ignored. For
@@ -73,25 +73,25 @@ The Header directive can occur almost anywhere within the server
 configuration. It is valid in the main server config and virtual host
 sections, inside &lt;Directory&gt;, &lt;Location&gt; and &lt;Files&gt;
 sections, and within .htaccess files.
-<p>
+<P>
 The Header directives are processed in the following order:
-<ol>
-<li>main server
-<li>virtual host
-<li>&lt;Directory&gt; sections and .htaccess
-<li>&lt;Location&gt;
-<li>&lt;Files&gt;
-</ol>
+<OL>
+<LI>main server
+<LI>virtual host
+<LI>&lt;Directory&gt; sections and .htaccess
+<LI>&lt;Location&gt;
+<LI>&lt;Files&gt;
+</OL>
 
 Order is important. These two headers have a different effect if reversed:
-<pre>
+<PRE>
 Header append Author "John P. Doe"
 Header unset Author
-</pre>
+</PRE>
 
 This way round, the Author header is not set. If reversed, the Author
 header is set to "John P. Doe".
-<p>
+<P>
 
 The Header directives are processed just before the response is sent
 by its handler. These means that some headers that are added just
index 08ca89a18cb07c25f7a5e3edbdd8aad9ad09c2d5..eb647df2414a92acb0b4136fa4f0c39a6ee7538e 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache module mod_imap</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache module mod_imap</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Module mod_imap</h1>
+<h1 ALIGN="CENTER">Module mod_imap</H1>
 
-This module is contained in the <code>mod_imap.c</code> file, and is
-compiled in by default. It provides for <code>.map</code> files,
-replacing the functionality of the <code>imagemap</code> CGI
+This module is contained in the <CODE>mod_imap.c</CODE> file, and is
+compiled in by default. It provides for <CODE>.map</CODE> files,
+replacing the functionality of the <CODE>imagemap</CODE> CGI
 program. Any directory or document type configured to use the handler
-<code>imap-file</code> (using either <code><A
-HREF="mod_mime.html#addhandler">AddHandler</A> </code> or <code><A
-HREF="mod_mime.html#sethandler">SetHandler</A></code>) will be
+<CODE>imap-file</CODE> (using either <CODE><A
+HREF="mod_mime.html#addhandler">AddHandler</A> </CODE> or <CODE><A
+HREF="mod_mime.html#sethandler">SetHandler</A></CODE>) will be
 processed by this module.
 
 <h2>Summary</h2>
 
 This module is in the default Apache distribution. The following directive will
-activate files ending with <code>.map</code> as imagemap files:
+activate files ending with <CODE>.map</CODE> as imagemap files:
 
-<blockquote><code>AddHandler imap-file map</code></blockquote>
+<BLOCKQUOTE><CODE>AddHandler imap-file map</CODE></BLOCKQUOTE>
 
 Note that the following is still supported:
 
- <blockquote><code>AddType application/x-httpd-imap map</code></blockquote>
+ <BLOCKQUOTE><CODE>AddType application/x-httpd-imap map</CODE></BLOCKQUOTE>
 
 However, we are trying to phase out "magic MIME types" so we are deprecating
 this method.
@@ -42,111 +42,111 @@ this method.
 The imagemap module adds some new features that were not
 possible with previously distributed imagemap programs.<P>
 
-<ul>
+<UL>
 <LI>URL references relative to the Referer: information.
 <LI>Default &lt;BASE&gt; assignment through a new map directive
-<code>base</code>.
-<LI>No need for <code>imagemap.conf</code> file.
+<CODE>base</CODE>.
+<LI>No need for <CODE>imagemap.conf</CODE> file.
 <LI>Point references.
 <LI>Configurable generation of imagemap menus.
-</ul>
+</UL>
 <P>
 
 <h2>Configuration Directives</h2>
-<ul>
-<li><A HREF="#imapmenu">ImapMenu</A>
-<li><A HREF="#imapdefault">ImapDefault</A>
-<li><A HREF="#imapbase">ImapBase</A>
-</ul>
+<UL>
+<LI><A HREF="#imapmenu">ImapMenu</A>
+<LI><A HREF="#imapdefault">ImapDefault</A>
+<LI><A HREF="#imapbase">ImapBase</A>
+</UL>
 
 
-<p>
+<P>
 
 <h3><A name="imapmenu">ImapMenu</A></h3>
-<strong>Syntax:</strong> ImapMenu <code>{none, formatted, semi-formatted,
-                                                      unformatted}</code><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Module:</strong> mod_imap.c<br>
-<strong>Compatibility:</strong> ImapMenu is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ImapMenu <CODE>{none, formatted, semi-formatted,
+                                                      unformatted}</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Module:</STRONG> mod_imap.c<BR>
+<STRONG>Compatibility:</STRONG> ImapMenu is only available in Apache
+1.1 and later.<P>
 
 The ImapMenu directive determines the action taken if an imagemap file
 is called without valid coordinates.
-<dl>
-  <dt><code>none</code>
-  <dd>If ImapMenu is
-       <code>none</code>, no menu is generated, and the <code>default</code>
+<DL>
+  <DT><CODE>none</CODE>
+  <DD>If ImapMenu is
+       <CODE>none</CODE>, no menu is generated, and the <CODE>default</CODE>
        action is performed.
-  <dt><code>formatted</code>
-  <dd>A <code>formatted</code> menu is the simplest menu.  Comments
+  <DT><CODE>formatted</CODE>
+  <DD>A <CODE>formatted</CODE> menu is the simplest menu.  Comments
        in the imagemap file are ignored.  A level one header is
        printed, then an hrule, then the links each on a separate line.
        The menu has a consistent, plain look close to that of
        a directory listing.
-  <dt><code>semiformatted</code>
-  <dd>In the <code>semiformatted</code> menu, comments are printed
+  <DT><CODE>semiformatted</CODE>
+  <DD>In the <CODE>semiformatted</CODE> menu, comments are printed
        where they occur in the imagemap file.  Blank lines are turned
        into HTML breaks.  No header or hrule is printed, but otherwise
-       the menu is the same as a <code>formatted</code> menu.
-  <dt><code>unformatted</code>
-  <dd>Comments are printed, blank lines are ignored.  Nothing is
+       the menu is the same as a <CODE>formatted</CODE> menu.
+  <DT><CODE>unformatted</CODE>
+  <DD>Comments are printed, blank lines are ignored.  Nothing is
        printed that does not appear in the imagemap file.  All breaks
        and headers must be included as comments in the imagemap file.
        This gives you the most flexibility over the appearance of your
        menus, but requires you to treat your map files as HTML instead
        of plaintext.
-</dl>
+</DL>
 
-<p>
+<P>
 
 <h3><A name="imapdefault">ImapDefault</A></h3>
-<strong>Syntax:</strong> ImapDefault <code>{error, nocontent,
-                                                 map, referer, URL}</code><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Module:</strong> mod_imap.c<br>
-<strong>Compatibility:</strong> ImapDefault is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ImapDefault <CODE>{error, nocontent,
+                                                 map, referer, URL}</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Module:</STRONG> mod_imap.c<BR>
+<STRONG>Compatibility:</STRONG> ImapDefault is only available in Apache
+1.1 and later.<P>
 
 
-The ImapDefault directive sets the default <code>default</code> used in
-the imagemap files.  It's value is overridden by a <code>default</code>
+The ImapDefault directive sets the default <CODE>default</CODE> used in
+the imagemap files.  It's value is overridden by a <CODE>default</CODE>
 directive within the imagemap file.  If not present, the
-<code>default</code> action is <code>nocontent</code>, which means
-that a <code>204 No Content</code> is sent to the client.  In this
+<CODE>default</CODE> action is <CODE>nocontent</CODE>, which means
+that a <CODE>204 No Content</CODE> is sent to the client.  In this
 case, the client should continue to display the original page.
 
-<p>
+<P>
 
 <h3><A name="imapbase">ImapBase</A></h3>
-<strong>Syntax:</strong> ImapBase <code>{map, referer, URL}</code><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Indexes<br>
-<strong>Module:</strong> mod_imap.c<br>
-<strong>Compatibility:</strong> ImapBase is only available in Apache
-1.1 and later.<p>
-
-The ImapBase directive sets the default <code>base</code> used in
-the imagemap files.  It's value is overridden by a <code>base</code>
+<STRONG>Syntax:</STRONG> ImapBase <CODE>{map, referer, URL}</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Indexes<BR>
+<STRONG>Module:</STRONG> mod_imap.c<BR>
+<STRONG>Compatibility:</STRONG> ImapBase is only available in Apache
+1.1 and later.<P>
+
+The ImapBase directive sets the default <CODE>base</CODE> used in
+the imagemap files.  It's value is overridden by a <CODE>base</CODE>
 directive within the imagemap file.  If not present, the
-<code>base</code> defaults to <code>http://servername/</code>.
+<CODE>base</CODE> defaults to <CODE>http://servername/</CODE>.
 
-<hr>
-<p>
+<HR>
+<P>
 
 <h2>Imagemap File</h2>
 The lines in the imagemap files can have one of several formats:
-<blockquote>
-<code>directive value [x,y ...]</code><br>
-<code>directive value "Menu text" [x,y ...]</code><br>
-<code>directive value x,y ... "Menu text"</code><br>
-</blockquote>
-The directive is one of <code>base</code>, <code>default</code>,
-<code>poly</code>, <code>circle</code>, <code>rect</code>, or
-<code>point</code>.  The value is an absolute or relative URL, or one
+<BLOCKQUOTE>
+<CODE>directive value [x,y ...]</CODE><BR>
+<CODE>directive value "Menu text" [x,y ...]</CODE><BR>
+<CODE>directive value x,y ... "Menu text"</CODE><BR>
+</BLOCKQUOTE>
+The directive is one of <CODE>base</CODE>, <CODE>default</CODE>,
+<CODE>poly</CODE>, <CODE>circle</CODE>, <CODE>rect</CODE>, or
+<CODE>point</CODE>.  The value is an absolute or relative URL, or one
 of the special values listed below.  The coordinates are
-<code>x,y</code> pairs separated by whitespace.  The quoted text is
+<CODE>x,y</CODE> pairs separated by whitespace.  The quoted text is
 used as the text of the link if a imagemap menu is generated.  Lines
 beginning with '#' are comments.
 
@@ -154,128 +154,128 @@ beginning with '#' are comments.
 There are six directives allowed in the imagemap file.  The directives
 can come in any order, but are processed in the order they are found
 in the imagemap file.
-<dl>
-<dt><code>base</code> Directive
-<dd>Has the effect of <code>&lt;BASE href="value"&gt;</code>.  The
+<DL>
+<DT><CODE>base</CODE> Directive
+<DD>Has the effect of <CODE>&lt;BASE HREF="value"&gt;</CODE>.  The
      non-absolute URLs of the map-file are taken relative to this value.
-     The <code>base</code> directive overrides ImapBase as set in a
+     The <CODE>base</CODE> directive overrides ImapBase as set in a
      .htaccess file or in the server configuration files.  In the absence
-     of an ImapBase configuration directive, <code>base</code> defaults to
-     <code>http://server_name/</code>. <br>
-     <code>base_uri</code> is synonymous with <code>base</code>.  Note that
+     of an ImapBase configuration directive, <CODE>base</CODE> defaults to
+     <CODE>http://server_name/</CODE>. <BR>
+     <CODE>base_uri</CODE> is synonymous with <CODE>base</CODE>.  Note that
      a trailing slash on the URL is significant.
-<p>
-<dt><code>default</code> Directive
-<dd>The action taken if the coordinates given do not fit any of the
-     <code>poly</code>, <code>circle</code> or <code>rect</code>
-     directives, and there are no <code>point</code> directives.  Defaults
-     to <code>nocontent</code> in the absence of an ImapDefault
-     configuration setting, causing a status code of <code>204 No
-     Content</code> to be returned.  The client should keep the same
+<P>
+<DT><CODE>default</CODE> Directive
+<DD>The action taken if the coordinates given do not fit any of the
+     <CODE>poly</CODE>, <CODE>circle</CODE> or <CODE>rect</CODE>
+     directives, and there are no <CODE>point</CODE> directives.  Defaults
+     to <CODE>nocontent</CODE> in the absence of an ImapDefault
+     configuration setting, causing a status code of <CODE>204 No
+     Content</CODE> to be returned.  The client should keep the same
      page displayed.
-<p>
-<dt><code>poly</code> Directive
-<dd>Takes three to one-hundred points, and is obeyed if the user selected
+<P>
+<DT><CODE>poly</CODE> Directive
+<DD>Takes three to one-hundred points, and is obeyed if the user selected
      coordinates fall within the polygon defined by these points.
-<p>
-<dt><code>circle</code>
-<dd>Takes the center coordinates of a circle and a point on the circle. Is
+<P>
+<DT><CODE>circle</CODE>
+<DD>Takes the center coordinates of a circle and a point on the circle. Is
      obeyed if the user selected point is with the circle.
-<p>
-<dt><code>rect</code> Directive
-<dd>Takes the coordinates of two opposing corners of a rectangle.  Obeyed
+<P>
+<DT><CODE>rect</CODE> Directive
+<DD>Takes the coordinates of two opposing corners of a rectangle.  Obeyed
      if the point selected is within this rectangle.
-<p>
-<dt><code>point</code> Directive
-<dd>Takes a single point.  The point directive closest to the user
+<P>
+<DT><CODE>point</CODE> Directive
+<DD>Takes a single point.  The point directive closest to the user
      selected point is obeyed if no other directives are satisfied.
-     Note that <code>default</code> will not be followed if a
-     <code>point</code> directive is present and valid coordinates are
+     Note that <CODE>default</CODE> will not be followed if a
+     <CODE>point</CODE> directive is present and valid coordinates are
      given.
-</dl>
+</DL>
 
 
 
 <h3>Values</h3>
 The values for each of the directives can any of the following:
-<dl>
-  <dt>a URL
-  <dd>The URL can be relative or absolute URL.  Relative URLs can
+<DL>
+  <DT>a URL
+  <DD>The URL can be relative or absolute URL.  Relative URLs can
        contain '..' syntax and will be resolved relative to the
-       <code>base</code> value. <br>
-       <code>base</code> itself will not resolved according to the current
-       value. A statement <code>base mailto:</code> will work properly, though.
-<p>
-  <dt><code>map</code>
-  <dd>Equivalent to the URL of the imagemap file itself.  No
+       <CODE>base</CODE> value. <BR>
+       <CODE>base</CODE> itself will not resolved according to the current
+       value. A statement <CODE>base mailto:</CODE> will work properly, though.
+<P>
+  <DT><CODE>map</CODE>
+  <DD>Equivalent to the URL of the imagemap file itself.  No
        coordinates are sent with this, so a menu will be generated
        unless ImapMenu is set to 'none'.
-<p>
-  <dt><code>menu</code>
-  <dd>Synonymous with <code>map</code>.
-<p>
-  <dt><code>referer</code>
-  <dd>Equivalent to the URL of the referring document.
-       Defaults to <code>http://servername/</code> if no Referer:
+<P>
+  <DT><CODE>menu</CODE>
+  <DD>Synonymous with <CODE>map</CODE>.
+<P>
+  <DT><CODE>referer</CODE>
+  <DD>Equivalent to the URL of the referring document.
+       Defaults to <CODE>http://servername/</CODE> if no Referer:
        header was present.
-<p>
-  <dt><code>nocontent</code>
-  <dd>Sends a status code of <code>204 No Content</code>,
+<P>
+  <DT><CODE>nocontent</CODE>
+  <DD>Sends a status code of <CODE>204 No Content</CODE>,
        telling the client to keep the same page displayed.  Valid for
-       all but <code>base</code>.
-<p>
-  <dt><code>error</code>
-  <dd>Fails with a <code>500 Server Error</code>.  Valid for all but
-       <code>base</code>, but sort of silly for anything but
-       <code>default</code>.
-</dl>
+       all but <CODE>base</CODE>.
+<P>
+  <DT><CODE>error</CODE>
+  <DD>Fails with a <CODE>500 Server Error</CODE>.  Valid for all but
+       <CODE>base</CODE>, but sort of silly for anything but
+       <CODE>default</CODE>.
+</DL>
 
 <h3>Coordinates</h3>
-<dl>
-  <dt><code>0,0 200,200</code>
-  <dd>A coordinate consists of an <tt>x</tt> and a <tt>y</tt> value
+<DL>
+  <DT><CODE>0,0 200,200</CODE>
+  <DD>A coordinate consists of an <TT>x</TT> and a <TT>y</TT> value
        separated by a comma.  The coordinates are separated from each other
        by whitespace.  To accommodate the way Lynx handles imagemaps, should a
-       user select the coordinate <code>0,0</code>, it is as if
+       user select the coordinate <CODE>0,0</CODE>, it is as if
        no coordinate had been selected.
-</dl>
+</DL>
 
 <h3>Quoted Text</h3>
-<dl>
-  <dt><code>"Menu Text"</code>
-  <dd>After the value or after the coordinates, the line optionally may
+<DL>
+  <DT><CODE>"Menu Text"</CODE>
+  <DD>After the value or after the coordinates, the line optionally may
        contain text within double quotes.  This string is used as the
-       text for the link if a menu is generated:<br>
-     <code>&lt;a href="http://foo.com/"&gt;Menu text&lt;/a&gt;</code><br>
+       text for the link if a menu is generated:<BR>
+     <CODE>&lt;a HREF="http://foo.com/"&gt;Menu text&lt;/a&gt;</CODE><BR>
        If no quoted text is present, the name of the link will be used
-       as the text:<br>
-     <code>&lt;a href="http://foo.com/"&gt;http://foo.com&lt;/a&gt;</code><br>
+       as the text:<BR>
+     <CODE>&lt;a HREF="http://foo.com/"&gt;http://foo.com&lt;/a&gt;</CODE><BR>
        It is impossible to escape double quotes within this text.
-</dl>
+</DL>
 
-<hr>
+<HR>
 
 <h2>Example Mapfile</h2>
-<blockquote><code>
-#Comments are printed in a 'formatted' or 'semiformatted' menu. <br>
-#And can contain html tags. &lt;hr&gt; <br>
-base referer  <br>
-poly map "Could I have a menu, please?"  0,0 0,10 10,10 10,0 <br>
-rect .. 0,0 77,27 "the directory of the referer"<br>
-circle http://www.inetnebr.com/lincoln/feedback/ 195,0 305,27 <br>
-rect another_file "in same directory as referer" 306,0 419,27  <br>
-point http://www.zyzzyva.com/ 100,100 <br>
-point http://www.tripod.com/  200,200 <br>
-rect mailto:nate@tripod.com 100,150 200,0 "Bugs?" <br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+#Comments are printed in a 'formatted' or 'semiformatted' menu. <BR>
+#And can contain html tags. &lt;hr&gt; <BR>
+base referer  <BR>
+poly map "Could I have a menu, please?"  0,0 0,10 10,10 10,0 <BR>
+rect .. 0,0 77,27 "the directory of the referer"<BR>
+circle http://www.inetnebr.com/lincoln/feedback/ 195,0 305,27 <BR>
+rect another_file "in same directory as referer" 306,0 419,27  <BR>
+point http://www.zyzzyva.com/ 100,100 <BR>
+point http://www.tripod.com/  200,200 <BR>
+rect mailto:nate@tripod.com 100,150 200,0 "Bugs?" <BR>
+</CODE></BLOCKQUOTE>
 <P>
 
 <h2>Referencing your mapfile</h2>
-<blockquote><code>
-&lt;A HREF="/maps/imagemap1.map"&gt; <br>
-&lt;IMG ISMAP SRC="/images/imagemap1.gif"&gt; <br>
+<BLOCKQUOTE><CODE>
+&lt;A HREF="/maps/imagemap1.map"&gt; <BR>
+&lt;IMG ISMAP SRC="/images/imagemap1.gif"&gt; <BR>
 &lt;/A&gt;
-</code></blockquote><p>
+</CODE></BLOCKQUOTE><P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 939d8c33befba93971a211c12fbb5b0589993048..81647ed873581cb447a0361245cf755a14a91599 100644 (file)
@@ -15,7 +15,7 @@
 <!--#include virtual="header.html" -->
 <H1 ALIGN="CENTER">Module mod_include</H1>
 
-This module is contained in the <code>mod_include.c</code> file, and
+This module is contained in the <CODE>mod_include.c</CODE> file, and
 is compiled in by default. It provides for server-parsed html
 documents. Several directives beyond the original NCSA definition have been
 included in Apache 1.2 - these are flagged below with the phrase
@@ -49,107 +49,107 @@ directive can be used to parse normal (<CODE>text/html</CODE>) files,
 based on file permissions.  <P>
 
 For backwards compatibility, documents with mime type
-<code>text/x-server-parsed-html</code> or
-<code>text/x-server-parsed-html3</code> will also be parsed
-(and the resulting output given the mime type <code>text/html</code>).
+<CODE>text/x-server-parsed-html</CODE> or
+<CODE>text/x-server-parsed-html3</CODE> will also be parsed
+(and the resulting output given the mime type <CODE>text/html</CODE>).
 
 <h2>Basic Elements</h2>
 
 The document is parsed as an HTML document, with special commands embedded
 as SGML comments. A command has the syntax:
 
-<blockquote><code>
-&lt;!--#</code><em>element attribute=value attribute=value ...</em>
-<code> --&gt;
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+&lt;!--#</CODE><EM>element attribute=value attribute=value ...</EM>
+<CODE> --&gt;
+</CODE></BLOCKQUOTE>
 
 The value will often be enclosed in double quotes; many commands only allow
 a single attribute-value pair.  Note that the comment terminator
 (<SAMP>--&gt;</SAMP>) should be preceded by whitespace to ensure that it
 isn't considered part of an SSI token.
-<p>
-The allowed elements are:<p>
+<P>
+The allowed elements are:<P>
 
-<dl>
+<DL>
 
-<dt><strong>config</strong>
-<dd>
+<DT><STRONG>config</STRONG>
+<DD>
 This command controls various aspects of the parsing. The valid attributes
 are:
-<dl>
-<dt>errmsg
-<dd>The value is a message that is sent back to the client if an error occurs
+<DL>
+<DT>errmsg
+<DD>The value is a message that is sent back to the client if an error occurs
 whilst parsing the document.
-<dt>sizefmt
-<dd>The value sets the format to be used which displaying the size of a file.
-Valid values are <code>bytes</code> for a count in bytes, or
-<code>abbrev</code> for a count in Kb or Mb as appropriate.
-<dt>timefmt
-<dd>The value is a string to be used by the <code>strftime(3)</code> library
+<DT>sizefmt
+<DD>The value sets the format to be used which displaying the size of a file.
+Valid values are <CODE>bytes</CODE> for a count in bytes, or
+<CODE>abbrev</CODE> for a count in Kb or Mb as appropriate.
+<DT>timefmt
+<DD>The value is a string to be used by the <CODE>strftime(3)</CODE> library
 routine when printing dates.
-</dl>
+</DL>
 
-<dt><strong>echo</strong>
-<dd>
+<DT><STRONG>echo</STRONG>
+<DD>
 This command prints one of the include variables, defined below.
-If the variable is unset, it is printed as <code>(none)</code>.
-Any dates printed are subject to the currently configured <code>timefmt</code>.
+If the variable is unset, it is printed as <CODE>(none)</CODE>.
+Any dates printed are subject to the currently configured <CODE>timefmt</CODE>.
 Attributes:
-<dl>
-<dt>var
-<dd>The value is the name of the variable to print.
-</dl>
+<DL>
+<DT>var
+<DD>The value is the name of the variable to print.
+</DL>
 
-<dt><strong>exec</strong>
-<dd>
+<DT><STRONG>exec</STRONG>
+<DD>
 The exec command executes a given shell command or CGI script.
 The IncludesNOEXEC <A HREF="core.html#options">Option</A> disables this command
 completely. The valid attributes are:
-<dl>
-<dt>cgi
-<dd>
+<DL>
+<DT>cgi
+<DD>
 The value specifies a (%-encoded) URL relative path to the CGI script.
 If the path does not begin with a (/), then it is taken to be relative to
 the current document. The document referenced by this path is invoked
 as a CGI script, even if the server would not normally recognize it as
 such. However, the directory containing the script must be enabled for
 CGI scripts (with <A HREF="mod_alias.html#scriptalias">ScriptAlias</A>
-or the ExecCGI <A HREF="core.html#options">Option</A>).<p>
+or the ExecCGI <A HREF="core.html#options">Option</A>).<P>
 The CGI script is given the PATH_INFO and query string (QUERY_STRING) of the
 original request from the client; these cannot be specified in the URL path.
 The include variables will be available to the script in addition to the
-standard <A HREF="mod_cgi.html">CGI</A> environment.<p>
+standard <A HREF="mod_cgi.html">CGI</A> environment.<P>
 If the script returns a Location: header instead of output, then this
-will be translated into an HTML anchor.<p>
-The <code>include virtual</code> element should be used in preference to
-<code>exec cgi</code>.
-<dt>cmd
-<dd>The server will execute the given string using <code>/bin/sh</code>.
+will be translated into an HTML anchor.<P>
+The <CODE>include virtual</CODE> element should be used in preference to
+<CODE>exec cgi</CODE>.
+<DT>cmd
+<DD>The server will execute the given string using <CODE>/bin/sh</CODE>.
 The include variables are available to the command.
-</dl>
+</DL>
 
-<dt><strong>fsize</strong>
-<dd>
+<DT><STRONG>fsize</STRONG>
+<DD>
 This command prints the size of the specified file, subject to the
-<code>sizefmt</code> format specification. Attributes:
-<dl>
-<dt>file
-<dd>The value is a path relative to the directory containing the current
+<CODE>sizefmt</CODE> format specification. Attributes:
+<DL>
+<DT>file
+<DD>The value is a path relative to the directory containing the current
 document being parsed.
-<dt>virtual
-<dd>The value is a (%-encoded) URL-path relative to the current document being
+<DT>virtual
+<DD>The value is a (%-encoded) URL-path relative to the current document being
 parsed. If it does not begin with a slash (/) then it is taken to be relative
 to the current document.
-</dl>
+</DL>
 
-<dt><strong>flastmod</strong>
-<dd>
+<DT><STRONG>flastmod</STRONG>
+<DD>
 This command prints the last modification date of the specified file,
-subject to the <code>timefmt</code> format specification. The attributes are
-the same as for the <code>fsize</code> command.
+subject to the <CODE>timefmt</CODE> format specification. The attributes are
+the same as for the <CODE>fsize</CODE> command.
 
-<dt><strong>include</strong>
-<dd>
+<DT><STRONG>include</STRONG>
+<DD>
 This command inserts the text of another document or file into the parsed
 file. Any included file is subject to the usual access control. If the
 directory containing the parsed file has the
@@ -159,68 +159,68 @@ to be executed, then it will not be included; this prevents the execution of
 CGI scripts. Otherwise CGI scripts are invoked as normal using the complete
 URL given in the command, including any query string.
 <!--%plaintext &lt;?INDEX CGI scripts, {\tt include} element and&gt; -->
-<p>
+<P>
 
 An attribute defines the location of the document; the inclusion is done for
 each attribute given to the include command. The valid attributes are:
-<dl>
-<dt>file
-<dd>The value is a path relative to the directory containing the current
-document being parsed. It cannot contain <code>../</code>, nor can it be an
-absolute path. The <code>virtual</code> attribute should always be used
+<DL>
+<DT>file
+<DD>The value is a path relative to the directory containing the current
+document being parsed. It cannot contain <CODE>../</CODE>, nor can it be an
+absolute path. The <CODE>virtual</CODE> attribute should always be used
 in preference to this one.
-<dt>virtual
-<dd>The value is a (%-encoded) URL relative to the current document being
+<DT>virtual
+<DD>The value is a (%-encoded) URL relative to the current document being
 parsed. The URL cannot contain a scheme or hostname, only a path and
 an optional query string. If it does not begin with a slash (/) then it
 is taken to be relative to the current document.
-</dl>
+</DL>
 A URL is constructed from the attribute, and the output the server
 would return if the URL were accessed by the client is included in the parsed
 output. Thus included files can be nested.
 
-<dt><strong>printenv</strong>
-<dd>This prints out a listing of all existing variables and their values.
+<DT><STRONG>printenv</STRONG>
+<DD>This prints out a listing of all existing variables and their values.
     No attributes.
-<dd>For example: <code>&lt;!--#printenv --&gt;</code>
-<dd>Apache 1.2 and above.
-
-<dt><strong>set</strong>
-<dd>This sets the value of a variable.  Attributes:
-<dl>
-<dt>var
-<dd>The name of the variable to set.
-<dt>value
-<dd>The value to give a variable.
-</dl>
+<DD>For example: <CODE>&lt;!--#printenv --&gt;</CODE>
+<DD>Apache 1.2 and above.
+
+<DT><STRONG>set</STRONG>
+<DD>This sets the value of a variable.  Attributes:
+<DL>
+<DT>var
+<DD>The name of the variable to set.
+<DT>value
+<DD>The value to give a variable.
+</DL>
 For example:
   <CODE>&lt;!--#set var="category" value="help" --&gt;</CODE>
-<dd>Apache 1.2 and above.
+<DD>Apache 1.2 and above.
 
-</dl>
+</DL>
 
 <h2>Include Variables</h2>
 
 In addition to the variables in the standard CGI environment, these are
-available for the <code>echo</code> command, for <code>if</code> and
-<code>elif</code>, and to any program invoked by the document.
-
-<dl>
-<dt>DATE_GMT
-<dd>The current date in Greenwich Mean Time.
-<dt>DATE_LOCAL
-<dd>The current date in the local time zone.
-<dt>DOCUMENT_NAME
-<dd>The filename (excluding directories) of the document requested by the
+available for the <CODE>echo</CODE> command, for <CODE>if</CODE> and
+<CODE>elif</CODE>, and to any program invoked by the document.
+
+<DL>
+<DT>DATE_GMT
+<DD>The current date in Greenwich Mean Time.
+<DT>DATE_LOCAL
+<DD>The current date in the local time zone.
+<DT>DOCUMENT_NAME
+<DD>The filename (excluding directories) of the document requested by the
 user.
-<dt>DOCUMENT_URI
-<dd>The (%-decoded) URL path of the document requested by the user. Note that
-in the case of nested include files, this is <em>not</em> then URL for the
+<DT>DOCUMENT_URI
+<DD>The (%-decoded) URL path of the document requested by the user. Note that
+in the case of nested include files, this is <EM>not</EM> then URL for the
 current document.
-<dt>LAST_MODIFIED
-<dd>The last modification date of the document requested by the user.
-</dl>
-<p>
+<DT>LAST_MODIFIED
+<DD>The last modification date of the document requested by the user.
+</DL>
+<P>
 
 <H2>Variable Substitution</H2>
 <P> Variable substitution is done within quoted strings in most cases
@@ -350,44 +350,44 @@ elements are:
     <EM>'string1    string2'</EM> results in <EM>string1    string2</EM>
 </PRE>
 
-<hr>
+<HR>
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#xbithack">XBitHack</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#xbithack">XBitHack</A>
+</UL>
+<HR>
 
 
 <h2><A name="xbithack">XBitHack</A></h2>
 <!--%plaintext &lt;?INDEX {\tt XBitHack} directive&gt; -->
-<strong>Syntax:</strong> XBitHack <em>status</em><br>
-<strong>Default:</strong> <code>XBitHack off</code><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> Options<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_include<p>
+<STRONG>Syntax:</STRONG> XBitHack <EM>status</EM><BR>
+<STRONG>Default:</STRONG> <CODE>XBitHack off</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> Options<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_include<P>
 
 The XBitHack directives controls the parsing of ordinary html documents.
 This directive only affects files associated with the MIME type
 <CODE>text/html</CODE>.
-<em>Status</em> can have the following values:
-<dl>
-<dt>off
-<dd>No special treatment of executable files.
-<dt>on
-<dd>Any file that has the user-execute bit set will be treated as a
+<EM>Status</EM> can have the following values:
+<DL>
+<DT>off
+<DD>No special treatment of executable files.
+<DT>on
+<DD>Any file that has the user-execute bit set will be treated as a
 server-parsed html document.
-<dt>full
-<dd>As for <code>on</code> but also test the group-execute bit. If it
+<DT>full
+<DD>As for <CODE>on</CODE> but also test the group-execute bit. If it
 is set, then set the Last-modified date of the returned file to be the
 last modified time of the file. If it is not set, then no last-modified date
 is sent. Setting this bit allows clients and proxies to cache the result of
 the request.
-<p><STRONG>Note:</STRONG> you would not want to use this, for example, when you
-<code>#include</code> a CGI that produces different output on each hit
+<P><STRONG>Note:</STRONG> you would not want to use this, for example, when you
+<CODE>#include</CODE> a CGI that produces different output on each hit
 (or potentially depends on the hit).
-</dl>
-<p>
+</DL>
+<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 984a68b12c930c5c87aa47152ec17846d0ece20d..d6728e7d03f813f4127197a34d38879d68bbe4b0 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache module mod_info</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache module mod_info</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Module mod_info</h1>
+<h1 ALIGN="CENTER">Module mod_info</H1>
 
-This module is contained in the <code>mod_info.c</code> file.  It
+This module is contained in the <CODE>mod_info.c</CODE> file.  It
 provides a comprehensive overview of the server configuration
 including all installed modules and directives in the configuration
 files.  This module is not compiled into the
@@ -34,7 +34,7 @@ AddModule modules/standard/mod_info.o
 
 <HR>
 <P>
-To configure it, add the following to your <code>access.conf</code> file.
+To configure it, add the following to your <CODE>access.conf</CODE> file.
 
 <PRE>
 &lt;Location /server-info&gt;
@@ -50,9 +50,9 @@ clause inside the
 <A
  HREF="core.html#location"
 >location</A>
-directive to limit access to your server configuration information.<p>
+directive to limit access to your server configuration information.<P>
 Once configured, the server information is obtained by accessing
-<tt>http://your.host.dom/server-info</tt><p>
+<TT>http://your.host.dom/server-info</TT><P>
 <BLOCKQUOTE>
  <STRONG>
   Note that the configuration files are read by the module at run-time,
index e3d87e8c718e179ca0edd628d6bad48efe239767..a8e3233932096fd20515f238f5ef4476d9a87cfe 100644 (file)
 >
 <!--#include virtual="header.html" -->
 
-<H1 ALIGN="CENTER">Module mod_isapi</h1>
+<H1 ALIGN="CENTER">Module mod_isapi</H1>
 
-<p>This module is contained in the <code>mod_isapi.c</code> file, and is
+<P>This module is contained in the <CODE>mod_isapi.c</CODE> file, and is
    compiled in by default. It provides support for ISAPI Extensions when
    running under Microsoft Windows. Any document with a handler of
-   <code>isapi-isa</code> will be processed by this module.
+   <CODE>isapi-isa</CODE> will be processed by this module.
 
 <h2>Purpose</h2>
 
-<p>This module implements the <a
-   href="http://www.microsoft.com/win32dev/apiext/isapimrg.htm">ISAPI
-   Extension</a> API. It allows Internet Server Applications (i.e., ISAPI
+<P>This module implements the <A
+   HREF="http://www.microsoft.com/win32dev/apiext/isapimrg.htm">ISAPI
+   Extension</A> API. It allows Internet Server Applications (i.e., ISAPI
    Extensions) to be used with Apache for Windows.
 
 <h2>Usage</h2>
 
-<p>In the server configuration file, add a handler called
-   <code>isapi-isa</code>, and map it to files with a <code>.DLL</code>
-   extension. In other words:</p>
-<pre>
+<P>In the server configuration file, add a handler called
+   <CODE>isapi-isa</CODE>, and map it to files with a <CODE>.DLL</CODE>
+   extension. In other words:</P>
+<PRE>
     AddHandler isapi-isa dll
-</pre>
-<p>Now simply place the ISA DLLs into your document root, and they will
-   be loaded when their URLs are accessed.</p>
+</PRE>
+<P>Now simply place the ISA DLLs into your document root, and they will
+   be loaded when their URLs are accessed.</P>
 
-<p>ISAPI Extensions are governed by the same restrictions as CGI
-   scripts. That is, <code>Options ExecCGI</code> must be active in the
-   directory that contains the ISA.</p>
+<P>ISAPI Extensions are governed by the same restrictions as CGI
+   scripts. That is, <CODE>Options ExecCGI</CODE> must be active in the
+   directory that contains the ISA.</P>
 
 <h2>Notes</h2>
 
-<p>Apache's ISAPI implementation conforms to all of the ISAPI 2.0
+<P>Apache's ISAPI implementation conforms to all of the ISAPI 2.0
    specification, except for the "Microsoft-specific" extensions dealing
    with asynchronous I/O. Apache's I/O model does not allow asynchronous
    reading and writing in a manner that the ISAPI could access. If an ISA
    tries to access async I/O, a message will be place in the error log,
    to help with debugging.
 
-<p>Some servers, like Microsoft IIS, load the ISA into the server, and
+<P>Some servers, like Microsoft IIS, load the ISA into the server, and
    keep it loaded until memory usage is too high, and it is
    unloaded. Apache currently loads and unloads the ISA for each
    request. This is inefficient, but Apache's request model makes this
    method the only method that currently works. A future release may use
    a more effective loading method.
 
-<p>Apache 1.3a1 currently limits POST and PUT input to 48k per
+<P>Apache 1.3a1 currently limits POST and PUT input to 48k per
    request. This is to work around a problem with the ISAPI implementation
    that could result in a denial of service attack. It is expected that
    support for larger uploads will be added soon.
 
-<p>Also, remember that while Apache supports ISAPI Extensions, it does
+<P>Also, remember that while Apache supports ISAPI Extensions, it does
    not support ISAPI Filters. Support for filters may be added at a later
-   date, but no support is planned at this time.</p>
+   date, but no support is planned at this time.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 9e8fa50855c6f6661faff2b3fdb5807a056ee266..2a43155c254f515f1b73e8ee82772b8363da044c 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_log_agent</h1>
+<H1 ALIGN="CENTER">Module mod_log_agent</H1>
 
-This module is contained in the <code>mod_log_agent.c</code> file, and is not
+This module is contained in the <CODE>mod_log_agent.c</CODE> file, and is not
 compiled in by default. It provides for logging of the client user agents.
 
 
-<ul>
-<li><A HREF="#agentlog">AgentLog</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#agentlog">AgentLog</A>
+</UL>
+<HR>
 
 
 <h2><A name="agentlog">AgentLog</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AgentLog} directive&gt; -->
-<strong>Syntax:</strong> AgentLog <em>file-pipe</em><br>
-<strong>Default:</strong> <code>AgentLog logs/agent_log</code><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_log_agent<p>
+<STRONG>Syntax:</STRONG> AgentLog <EM>file-pipe</EM><BR>
+<STRONG>Default:</STRONG> <CODE>AgentLog logs/agent_log</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_log_agent<P>
 
 The AgentLog directive sets the name of the file to which the server will
-log the UserAgent header of incoming requests. <em>File-pipe</em> is one
+log the UserAgent header of incoming requests. <EM>File-pipe</EM> is one
 of
-<dl><dt>A filename
-<dd>A filename relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
-<dt> `|' followed by a command
-<dd>A program to receive the agent log information on its standard input.
+<DL><DT>A filename
+<DD>A filename relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
+<DT> `|' followed by a command
+<DD>A program to receive the agent log information on its standard input.
 Note the a new program will not be started for a VirtualHost if it inherits
 the AgentLog from the main server.
-</dl>
-<strong>Security:</strong> if a program is used, then it will be
+</DL>
+<STRONG>Security:</STRONG> if a program is used, then it will be
 run under the user who started httpd. This will be root if the server
-was started by root; be sure that the program is secure.<p>
+was started by root; be sure that the program is secure.<P>
 
-<strong>Security:</strong> See the <A
+<STRONG>Security:</STRONG> See the <A
 HREF="../misc/security_tips.html">security tips</A> document for
 details on why your security could be compromised if the directory
 where logfiles are stored is writable by anyone other than the user
 that starts the server.<P>
 
-This directive is provided for compatibility with NCSA 1.4.<p>
+This directive is provided for compatibility with NCSA 1.4.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index c0a9369096a1503cf457b98f323eb9220040bfe8..489148989f706df857721e14cc3e92d3427eee8e 100644 (file)
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_log_config</h1>
+<H1 ALIGN="CENTER">Module mod_log_config</H1>
 
-This module is contained in the <code>mod_log_config.c</code> file,
+This module is contained in the <CODE>mod_log_config.c</CODE> file,
 and is compiled in by default in Apache 1.2. mod_log_config replaces
 mod_log_common in Apache 1.2. Prior to version 1.2, mod_log_config was
 an optional module. It provides for logging of the requests made to
@@ -23,84 +23,84 @@ the server, using the Common Log Format or a user-specified format.
 
 <h2>Summary</h2>
 
-Three directives are provided by this module: <code>TransferLog</code>
-to create a log file, <code>LogFormat</code> to set a custom format,
-and <code>CustomLog</code> to define a log file and format in one go.
-The <code>TransferLog</code> and <code>CustomLog</code> directives can
+Three directives are provided by this module: <CODE>TransferLog</CODE>
+to create a log file, <CODE>LogFormat</CODE> to set a custom format,
+and <CODE>CustomLog</CODE> to define a log file and format in one go.
+The <CODE>TransferLog</CODE> and <CODE>CustomLog</CODE> directives can
 be used multiple times in each server to cause each request to be
 logged to multiple files.
 <P>
 
 <h3>Compatibility notes</h3>
 
-<ul>
-<li>This module is based on mod_log_config distributed with
+<UL>
+<LI>This module is based on mod_log_config distributed with
 previous Apache releases, now updated to handle multiple logs.
 There is now no need to re-configure Apache to use configuration log
 formats.
 
-<li>The module also implements the <code>CookieLog</code> directive,
-used to log user-tracking information created by <a
-href="mod_usertrack.html">mod_usertrack</a>. The use of
-<code>CookieLog</code> is deprecated, and a <code>CustomLog</code>
+<LI>The module also implements the <CODE>CookieLog</CODE> directive,
+used to log user-tracking information created by <A
+HREF="mod_usertrack.html">mod_usertrack</A>. The use of
+<CODE>CookieLog</CODE> is deprecated, and a <CODE>CustomLog</CODE>
 should be defined to log user-tracking information instead.
 
-</ul>
+</UL>
 
 <h2>Log File Formats</h2>
 
-Unless told otherwise with <tt>LogFormat</tt> the log files created by
-<tt>TransferLog</tt> will be in standard "Common Log Format"
+Unless told otherwise with <TT>LogFormat</TT> the log files created by
+<TT>TransferLog</TT> will be in standard "Common Log Format"
 (CLF). The contents of each line in a CLF file are explained
 below. Alternatively, the log file can be customized (and if multiple
 log files are used, each can have a different format). Custom formats
-are set with <code>LogFormat</code> and <code>CustomLog</code>.
+are set with <CODE>LogFormat</CODE> and <CODE>CustomLog</CODE>.
 
 <h3>Common Log Format</h3>
 
 The Common Log Format (CLF) file contains a separate line for each
 request. A line is composed of several tokens separated by spaces:
 
-<blockquote>
+<BLOCKQUOTE>
 host ident authuser date request status bytes
-</blockquote>
+</BLOCKQUOTE>
 If a token does not have a value then it is represented by a hyphen (-).
 The meanings and values of these tokens are as follows:
-<dl>
-<dt>host
-<dd>The fully-qualified domain name of the client, or its IP number if the
+<DL>
+<DT>host
+<DD>The fully-qualified domain name of the client, or its IP number if the
 name is not available.
-<dt>ident
-<dd>If <A HREF="core.html#identitycheck">IdentityCheck</A> is enabled and the
+<DT>ident
+<DD>If <A HREF="core.html#identitycheck">IdentityCheck</A> is enabled and the
 client machine runs identd, then this is the identity information reported
 by the client.
-<dt>authuser
-<dd>If the request was for an password protected document, then this is
+<DT>authuser
+<DD>If the request was for an password protected document, then this is
 the userid used in the request.
-<dt>date
-<dd>The date and time of the request, in the following format:
-<dl><dd><blockquote><code> date = [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></dl>
-<dt>request
-<dd>The request line from the client, enclosed in double quotes
-(<code>&quot;</code>).
-<dt>status
-<dd>The three digit status code returned to the client.
-<dt>bytes
-<dd>The number of bytes in the object returned to the client, not including
+<DT>date
+<DD>The date and time of the request, in the following format:
+<DL><DD><BLOCKQUOTE><CODE> date = [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></DL>
+<DT>request
+<DD>The request line from the client, enclosed in double quotes
+(<CODE>&quot;</CODE>).
+<DT>status
+<DD>The three digit status code returned to the client.
+<DT>bytes
+<DD>The number of bytes in the object returned to the client, not including
 any headers.
-</dl>
+</DL>
 
 <h3><A NAME="formats">Custom Log Formats</A></h3>
 
-The format argument to the <code>LogFormat</code> and
-<code>CustomLog</code> is a string. This string is logged to the log
+The format argument to the <CODE>LogFormat</CODE> and
+<CODE>CustomLog</CODE> is a string. This string is logged to the log
 file for each request. It can contain literal characters copied into
 the log files, and `%' directives which are replaced in the log file
 by the values as follows:
@@ -129,7 +129,7 @@ by the values as follows:
 %...v:          The name of the server (i.e. which virtual host?)
 </PRE>
 
-The `...' can be nothing at all (e.g. <code>"%h %u %r %s %b"</code>), or it can
+The `...' can be nothing at all (e.g. <CODE>"%h %u %r %s %b"</CODE>), or it can
 indicate conditions for inclusion of the item (which will cause it
 to be replaced with `-' if the condition is not met).  Note that
 there is no escaping performed on the strings from %r, %...i and
@@ -144,18 +144,18 @@ The forms of condition are a list of HTTP status codes, which may
 or may not be preceded by `!'.  Thus, `%400,501{User-agent}i' logs
 User-agent: on 400 errors and 501 errors (Bad Request, Not
 Implemented) only; `%!200,304,302{Referer}i' logs Referer: on all
-requests which did <b>not</b> return some sort of normal status.
+requests which did <STRONG>not</STRONG> return some sort of normal status.
 
 <P>
 
-Note that the common log format is defined by the string <code>"%h %l
-%u %t \"%r\" %s %b"</code>, which can be used as the basis for
+Note that the common log format is defined by the string <CODE>"%h %l
+%u %t \"%r\" %s %b"</CODE>, which can be used as the basis for
 extending for format if desired (e.g. to add extra fields at the end).
-NCSA's extended/combined log format would be <code>"%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\""</code>.
+NCSA's extended/combined log format would be <CODE>"%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\""</CODE>.
 
 <h2>Using Multiple Log Files</h2>
 
-The <code>TransferLog</code> and <code>CustomLog</code> directives can
+The <CODE>TransferLog</CODE> and <CODE>CustomLog</CODE> directives can
 be given more than once to log requests to multiple log files. Each
 request will be logged to all the log files defined by either of these
 directives.
@@ -163,13 +163,13 @@ directives.
 <h3>Use with Virtual Hosts</h3>
 
 If a &lt;VirtualHost&gt; section does not contain any
-<tt>TransferLog</tt> or <tt>CustomLog</tt> directives, the
+<TT>TransferLog</TT> or <TT>CustomLog</TT> directives, the
 logs defined for the main server will be used. If it does
 contain one or more of these directives, requests serviced by
 this virtual host will only be logged in the log files defined
 within its definition, not in any of the main server's log files.
 See the examples below.
-<p>
+<P>
 
 <h2>Security Considerations</h2>
 
@@ -177,36 +177,36 @@ See the <A HREF="../misc/security_tips.html#security">security tips</A>
 document for details on why your security could be compromised if the
 directory where logfiles are stored is writable by anyone other than
 the user that starts the server.
-<p>
+<P>
 <h2>Directives</h2>
 
-<ul>
-<li><A HREF="#cookielog">CookieLog</A>
+<UL>
+<LI><A HREF="#cookielog">CookieLog</A>
 <LI><A HREF="#customlog">CustomLog</A>
-<li><A HREF="#logformat">LogFormat</A>
-<li><A HREF="#transferlog">TransferLog</A>
-</ul>
-<hr>
+<LI><A HREF="#logformat">LogFormat</A>
+<LI><A HREF="#transferlog">TransferLog</A>
+</UL>
+<HR>
 
 
 <h2><A name="cookielog">CookieLog</A></h2>
 <!--%plaintext &lt;?INDEX {\tt CookieLog} directive&gt; -->
-<strong>Syntax:</strong> CookieLog <em>filename</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Module:</strong> mod_cookies<br>
-<strong>Compatibility:</strong> Only available in Apache 1.2 and above<p>
+<STRONG>Syntax:</STRONG> CookieLog <EM>filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Module:</STRONG> mod_cookies<BR>
+<STRONG>Compatibility:</STRONG> Only available in Apache 1.2 and above<P>
 
 The CookieLog directive sets the filename for logging of cookies.
 The filename is relative to the <A
 HREF="core.html#serverroot">ServerRoot</A>. This directive is included
-only for compatibility with <a
-href="mod_cookies.html">mod_cookies</a>, and is deprecated.
-<p>
+only for compatibility with <A
+HREF="mod_cookies.html">mod_cookies</A>, and is deprecated.
+<P>
 
 <HR>
 <H2><A NAME="customlog">CustomLog</A></H2>
-<STRONG>Syntax:</STRONG> CustomLog <em>file-pipe</em>
-    <em>format-or-nickname</em><BR>
+<STRONG>Syntax:</STRONG> CustomLog <EM>file-pipe</EM>
+    <EM>format-or-nickname</EM><BR>
 <STRONG>Context:</STRONG> server config, virtual host<BR>
 <STRONG>Status:</STRONG> Base<BR>
 <STRONG>Compatibility: </STRONG> Nickname only available in Apache 1.3
@@ -226,7 +226,7 @@ server root.
 <P>
 The format argument specifies a format for each line of the log file.
 The options available for the format are exactly the same as for
-the argument of the <tt>LogFormat</tt> directive. If the format
+the argument of the <TT>LogFormat</TT> directive. If the format
 includes any spaces (which it will do in almost all cases) it
 should be enclosed in double quotes.
 </P>
@@ -241,16 +241,16 @@ directive.
 <HR>
 <h2><A name="logformat">LogFormat</A></h2>
 <!--%plaintext &lt;?INDEX {\tt LogFormat} directive&gt; -->
-<strong>Syntax:</strong> LogFormat <em>format</em> [<EM>nickname</EM>]
-<br>
-<strong>Default:</strong> <code>LogFormat &quot;%h %l %u %t \&quot;%r\&quot;
-%s %b&quot;</code><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
+<STRONG>Syntax:</STRONG> LogFormat <EM>format</EM> [<EM>nickname</EM>]
+<BR>
+<STRONG>Default:</STRONG> <CODE>LogFormat &quot;%h %l %u %t \&quot;%r\&quot;
+%s %b&quot;</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
 <STRONG>Compatibility: </STRONG> Nickname only available in Apache 1.3
     or later
 <BR>
-<strong>Module:</strong> mod_log_config
+<STRONG>Module:</STRONG> mod_log_config
 <P>
 This sets the format of the default logfile named by the
 <A
@@ -275,14 +275,14 @@ nothing else</STRONG> -- that is, it <EM>only</EM> defines the nickname,
 it doesn't actually apply the format and make it the default.
 </P>
 
-<hr>
+<HR>
 <h2><A name="transferlog">TransferLog</A></h2>
 <!--%plaintext &lt;?INDEX {\tt TransferLog} directive&gt; -->
-<strong>Syntax:</strong> TransferLog <em>file-pipe</em><br>
-<strong>Default:</strong> none<br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_log_config<p>
+<STRONG>Syntax:</STRONG> TransferLog <EM>file-pipe</EM><BR>
+<STRONG>Default:</STRONG> none<BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_log_config<P>
 
 The TransferLog directive adds a log file in the format defined by the
 most recent
@@ -291,18 +291,18 @@ most recent
 ><SAMP>LogFormat</SAMP></A>
 directive, or Common Log Format if no other default format has been
 specified.
-<em>File-pipe</em> is one
+<EM>File-pipe</EM> is one
 of
-<dl><dt>A filename
-<dd>A filename relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
-<dt> `|' followed by a command
-<dd>A program to receive the agent log information on its standard input.
+<DL><DT>A filename
+<DD>A filename relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
+<DT> `|' followed by a command
+<DD>A program to receive the agent log information on its standard input.
 Note the a new program will not be started for a VirtualHost if it inherits
 the TransferLog from the main server.
-</dl>
-<strong>Security:</strong> if a program is used, then it will be
+</DL>
+<STRONG>Security:</STRONG> if a program is used, then it will be
 run under the user who started httpd. This will be root if the server
-was started by root; be sure that the program is secure.<p>
+was started by root; be sure that the program is secure.<P>
 
 
 <!--#include virtual="footer.html" -->
index 8a5146491a6b7bb4d252b997689e073fceed42bd..d98228f4e9811d429a1ddbe40e38deed58b677fc 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_log_referer</h1>
+<H1 ALIGN="CENTER">Module mod_log_referer</H1>
 
-This module is contained in the <code>mod_log_referer.c</code> file, and is not
+This module is contained in the <CODE>mod_log_referer.c</CODE> file, and is not
 compiled in by default. It provides for logging of the documents which
 reference documents on the server.
 
 <h2>Log file format</h2>
 The log file contains a separate line for each refer. Each line has the
 format
-<blockquote><em>uri</em> <code>-&gt;</code> <em>document</em></blockquote>
-where <em>uri</em> is the (%-escaped) URI for the document that references
-the one requested by the client, and <em>document</em> is the (%-decoded)
+<BLOCKQUOTE><EM>uri</EM> <CODE>-&gt;</CODE> <EM>document</EM></BLOCKQUOTE>
+where <EM>uri</EM> is the (%-escaped) URI for the document that references
+the one requested by the client, and <EM>document</EM> is the (%-decoded)
 local URL to the document being referred to.
 
 
 <h2>Directives</h2>
-<ul>
-<li><A HREF="#refererignore">RefererIgnore</A>
-<li><A HREF="#refererlog">RefererLog</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#refererignore">RefererIgnore</A>
+<LI><A HREF="#refererlog">RefererLog</A>
+</UL>
+<HR>
 
 
 <h2><A name="refererignore">RefererIgnore</A></h2>
 <!--%plaintext &lt;?INDEX {\tt RefererIgnore} directive&gt; -->
-<strong>Syntax:</strong> RefererIgnore <em>string string ...</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_log_referer<p>
+<STRONG>Syntax:</STRONG> RefererIgnore <EM>string string ...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_log_referer<P>
 
 The RefererIgnore directive adds to the list of strings to ignore in
 Referer headers. If any of the strings in the list is contained in
 the Referer header, then no referrer information will be logged for the
 request. Example:
-<blockquote><code>RefererIgnore www.ncsa.uiuc.edu</code></blockquote>
+<BLOCKQUOTE><CODE>RefererIgnore www.ncsa.uiuc.edu</CODE></BLOCKQUOTE>
 This avoids logging references from www.ncsa.uiuc.edu.
-<p><hr>
+<P><HR>
 
 
 <h2><A name="refererlog">RefererLog</A></h2>
 <!--%plaintext &lt;?INDEX {\tt RefererLog} directive&gt; -->
-<strong>Syntax:</strong> RefererLog <em>file-pipe</em><br>
-<strong>Default:</strong> <code>RefererLog logs/referer_log</code><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Extension<br>
-<strong>Module:</strong> mod_log_referer<p>
+<STRONG>Syntax:</STRONG> RefererLog <EM>file-pipe</EM><BR>
+<STRONG>Default:</STRONG> <CODE>RefererLog logs/referer_log</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Extension<BR>
+<STRONG>Module:</STRONG> mod_log_referer<P>
 
 The RefererLog directive sets the name of the file to which the server will
-log the Referer header of incoming requests. <em>File-pipe</em> is one
+log the Referer header of incoming requests. <EM>File-pipe</EM> is one
 of
-<dl><dt>A filename
-<dd>A filename relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
-<dt> `|' followed by a command
-<dd>A program to receive the referrer log information on its standard input.
+<DL><DT>A filename
+<DD>A filename relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
+<DT> `|' followed by a command
+<DD>A program to receive the referrer log information on its standard input.
 Note the a new program will not be started for a VirtualHost if it inherits
 the RefererLog from the main server.
-</dl>
-<strong>Security:</strong> if a program is used, then it will be
+</DL>
+<STRONG>Security:</STRONG> if a program is used, then it will be
 run under the user who started httpd. This will be root if the server
-was started by root; be sure that the program is secure.<p>
+was started by root; be sure that the program is secure.<P>
 
-<strong>Security:</strong> See the <A
+<STRONG>Security:</STRONG> See the <A
 HREF="../misc/security_tips.html">security tips</A> document for
 details on why your security could be compromised if the directory
 where logfiles are stored is writable by anyone other than the user
 that starts the server.<P>
 
-This directive is provided for compatibility with NCSA 1.4.<p>
+This directive is provided for compatibility with NCSA 1.4.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index cc3fe664d23986c23755e5174f0550667f3020b4..e71bd844e3fb436377c1a479820e02c63be014f3 100644 (file)
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_mime</h1>
+<H1 ALIGN="CENTER">Module mod_mime</H1>
 
-This module is contained in the <code>mod_mime.c</code> file, and is
+This module is contained in the <CODE>mod_mime.c</CODE> file, and is
 compiled in by default. It provides for determining the types of files
 from the filename.
 
@@ -55,190 +55,190 @@ extensions to the left of the unknown extension. So, for example, if
 the extensions fr and html are mapped to the appropriate language and
 type but extension xxx is not assigned to anything, then the file
 <CODE>welcome.fr.xxx.html</CODE> will be associated with content-type
-text/html but <i>no</i> language.
+text/html but <EM>no</EM> language.
 
 <P>
 
 Note that changing the type or encoding of a file does not change the
-value of the <code>Last-Modified</code> header. Thus, previously cached
+value of the <CODE>Last-Modified</CODE> header. Thus, previously cached
 copies may still be used by a client or proxy, with the previous headers.
 
 <P>
 
 Please note that changing a file's type or encoding does not change
-the value of the <code>Last-Modified</code> header. Previously cached
+the value of the <CODE>Last-Modified</CODE> header. Previously cached
 copies may still be used by a client or proxy.
 
 <P>
 
 <h2> Directives</h2>
-<ul>
-<li><A HREF="#addencoding">AddEncoding</A>
-<li><A HREF="#addhandler">AddHandler</A>
-<li><A HREF="#addlanguage">AddLanguage</A>
-<li><A HREF="#addtype">AddType</A>
-<li><A HREF="#forcetype">ForceType</A>
-<li><A HREF="#sethandler">SetHandler</A>
-<li><A HREF="#typesconfig">TypesConfig</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#addencoding">AddEncoding</A>
+<LI><A HREF="#addhandler">AddHandler</A>
+<LI><A HREF="#addlanguage">AddLanguage</A>
+<LI><A HREF="#addtype">AddType</A>
+<LI><A HREF="#forcetype">ForceType</A>
+<LI><A HREF="#sethandler">SetHandler</A>
+<LI><A HREF="#typesconfig">TypesConfig</A>
+</UL>
+<HR>
 
 
 <h2><A name="addencoding">AddEncoding</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AddEncoding} directive&gt; -->
-<strong>Syntax:</strong> AddEncoding <em>mime-enc extension extension...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<p>
+<STRONG>Syntax:</STRONG> AddEncoding <EM>mime-enc extension extension...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<P>
 
 The AddEncoding directive adds to the list of filename extensions which
-filenames may end in for the specified encoding type. <em>Mime-enc</em>
-is the mime encoding to use for documents ending in <em>extension</em>.
+filenames may end in for the specified encoding type. <EM>Mime-enc</EM>
+is the mime encoding to use for documents ending in <EM>extension</EM>.
 Example:
-<blockquote><code>
-AddEncoding x-gzip gz<br>
+<BLOCKQUOTE><CODE>
+AddEncoding x-gzip gz<BR>
 AddEncoding x-compress Z
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 
 This will cause files ending in .gz to be marked as encoded using the x-gzip
-encoding, and .Z files to be marked as encoded with x-compress.<p><hr>
-
-<h2><a name="addhandler">AddHandler</a></h2>
-
-<strong>Syntax:</strong> AddHandler <em>handler-name extension extension...</em><br>
-<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<br>
-<strong>Compatibility:</strong> AddHandler is only available in Apache
-1.1 and later<p>
-
-<p>AddHandler maps the filename extensions <em>extension</em> to the
-<a href="../handler.html">handler</a>
-<em>handler-name</em>. For example, to activate CGI scripts
-with the file extension "<code>.cgi</code>", you might use:
-<pre>
+encoding, and .Z files to be marked as encoded with x-compress.<P><HR>
+
+<h2><A name="addhandler">AddHandler</A></h2>
+
+<STRONG>Syntax:</STRONG> AddHandler <EM>handler-name extension extension...</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<BR>
+<STRONG>Compatibility:</STRONG> AddHandler is only available in Apache
+1.1 and later<P>
+
+<P>AddHandler maps the filename extensions <EM>extension</EM> to the
+<A HREF="../handler.html">handler</A>
+<EM>handler-name</EM>. For example, to activate CGI scripts
+with the file extension "<CODE>.cgi</CODE>", you might use:
+<PRE>
     AddHandler cgi-script cgi
-</pre>
+</PRE>
 
-<p>Once that has been put into your srm.conf or httpd.conf file, any
-file ending with "<code>.cgi</code>" will be treated as a CGI
-program.</p>
+<P>Once that has been put into your srm.conf or httpd.conf file, any
+file ending with "<CODE>.cgi</CODE>" will be treated as a CGI
+program.</P>
 <HR>
 
 <h2><A name="addlanguage">AddLanguage</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AddLanguage} directive&gt; -->
-<strong>Syntax:</strong> AddLanguage <em>mime-lang extension extension...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<p>
+<STRONG>Syntax:</STRONG> AddLanguage <EM>mime-lang extension extension...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<P>
 
 The AddLanguage directive adds to the list of filename extensions which
-filenames may end in for the specified content language. <em>Mime-lang</em>
-is the mime language of files with names ending <em>extension</em>,
+filenames may end in for the specified content language. <EM>Mime-lang</EM>
+is the mime language of files with names ending <EM>extension</EM>,
 after any content encoding extensions have been removed. Example:
-<blockquote><code>
-AddEncoding x-compress Z<br>
-AddLanguage en .en<br>
-AddLanguage fr .fr<br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+AddEncoding x-compress Z<BR>
+AddLanguage en .en<BR>
+AddLanguage fr .fr<BR>
+</CODE></BLOCKQUOTE>
 
-Then the document <code>xxxx.en.Z</code> will be treated as being a compressed
+Then the document <CODE>xxxx.en.Z</CODE> will be treated as being a compressed
 English document. Although the content language is reported to the client,
 the browser is unlikely to use this information. The AddLanguage directive
 is more useful for content negotiation, where the server returns one
-from several documents based on the client's language preference.<p><hr>
+from several documents based on the client's language preference.<P><HR>
 
 <h2><A name="addtype">AddType</A></h2>
 <!--%plaintext &lt;?INDEX {\tt AddType} directive&gt; -->
-<strong>Syntax:</strong> AddType <em>mime-type extension extension...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<p>
+<STRONG>Syntax:</STRONG> AddType <EM>mime-type extension extension...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<P>
 
 The AddType directive adds to the list of filename extensions which
-filenames may end in for the specified content type. <em>Mime-enc</em>
-is the mime type to use for documents ending in <em>extension</em>.
+filenames may end in for the specified content type. <EM>Mime-enc</EM>
+is the mime type to use for documents ending in <EM>extension</EM>.
 after content-encoding and language extensions have been removed. Example:
-<blockquote><code>
+<BLOCKQUOTE><CODE>
 AddType image/gif GIF
-</code></blockquote>
+</CODE></BLOCKQUOTE>
 It is recommended that new mime types be added using the AddType directive
-rather than changing the <A HREF="#typesconfig">TypesConfig</A> file.<p>
+rather than changing the <A HREF="#typesconfig">TypesConfig</A> file.<P>
 Note that, unlike the NCSA httpd, this directive cannot be used to set the
-type of particular files.<p><hr>
+type of particular files.<P><HR>
 
-<h2><a name="forcetype">ForceType</a></h2>
+<h2><A name="forcetype">ForceType</A></h2>
 
-<strong>Syntax:</strong> ForceType <em>media type</em><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<br>
-<strong>Compatibility:</strong> ForceType is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ForceType <EM>media type</EM><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<BR>
+<STRONG>Compatibility:</STRONG> ForceType is only available in Apache
+1.1 and later.<P>
 
-<p>When placed into an <code>.htaccess</code> file or a
-<code>&lt;Directory&gt;</code> or <code>&lt;Location&gt;</code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE>&lt;Directory&gt;</CODE> or <CODE>&lt;Location&gt;</CODE> section,
 this directive forces all matching files to be served
-as the content type given by <em>media type</em>. For example, if you
+as the content type given by <EM>media type</EM>. For example, if you
 had a directory full of GIF files, but did not want to label them all with
 ".gif", you might want to use:
-<pre>
+<PRE>
     ForceType image/gif
-</pre>
-<p>Note that this will override any filename extensions that might
-media type.</p>
+</PRE>
+<P>Note that this will override any filename extensions that might
+media type.</P>
 
-<h2><a name="sethandler">SetHandler</a></h2>
+<h2><A name="sethandler">SetHandler</A></h2>
 
-<strong>Syntax:</strong> SetHandler <em>handler-name</em><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<br>
-<strong>Compatibility:</strong> SetHandler is only available in Apache
-1.1 and later.<p>
+<STRONG>Syntax:</STRONG> SetHandler <EM>handler-name</EM><BR>
+<STRONG>Context:</STRONG> directory, .htaccess<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<BR>
+<STRONG>Compatibility:</STRONG> SetHandler is only available in Apache
+1.1 and later.<P>
 
-<p>When placed into an <code>.htaccess</code> file or a
-<code>&lt;Directory&gt;</code> or <code>&lt;Location&gt;</code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE>&lt;Directory&gt;</CODE> or <CODE>&lt;Location&gt;</CODE> section,
 this directive forces all matching files to be parsed through the
-<a href="../handler.html">handler</a>
-given by <em>handler-name</em>. For example, if you had a
+<A HREF="../handler.html">handler</A>
+given by <EM>handler-name</EM>. For example, if you had a
 directory you wanted to be parsed entirely as imagemap rule files,
 regardless of extension, you might put the following into an
-<code>.htaccess</code> file in that directory:
-<pre>
+<CODE>.htaccess</CODE> file in that directory:
+<PRE>
     SetHandler imap-file
-</pre>
+</PRE>
 
-<p>Another example: if you wanted to have the server display a status
-report whenever a URL of <code>http://servername/status</code> was
+<P>Another example: if you wanted to have the server display a status
+report whenever a URL of <CODE>http://servername/status</CODE> was
 called, you might put the following into access.conf:
-<pre>
+<PRE>
     &lt;Location /status&gt;
     SetHandler server-status
     &lt;/Location&gt;
-</pre>
+</PRE>
 <HR>
 
 <h2><A name="typesconfig">TypesConfig</A></h2>
 <!--%plaintext &lt;?INDEX {\tt TypesConfig} directive&gt; -->
-<strong>Syntax:</strong> TypesConfig <em>filename</em><br>
-<strong>Default:</strong> <code>TypesConfig conf/mime.types</code><br>
-<Strong>Context:</strong> server config<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime<p>
+<STRONG>Syntax:</STRONG> TypesConfig <EM>filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>TypesConfig conf/mime.types</CODE><BR>
+<Strong>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_mime<P>
 
 The TypesConfig directive sets the location of the mime types configuration
-file. <em>Filename</em> is relative to the
+file. <EM>Filename</EM> is relative to the
 <A HREF="core.html#serverroot">ServerRoot</A>. This file sets the default list of
 mappings from filename extensions to content types; changing this file is not
 recommended. Use the <A HREF="#addtype">AddType</A> directive instead. The
 file contains lines in the format of the arguments to an AddType command:
-<blockquote><em>mime-type extension extension ...</em></blockquote>
+<BLOCKQUOTE><EM>mime-type extension extension ...</EM></BLOCKQUOTE>
 The extensions are lower-cased. Blank lines, and lines beginning with a hash
-character (`#') are ignored.<p>
+character (`#') are ignored.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 22205b05e125bda97ad87a08db2e1b9a413b46d4..af00aaa82a532504c41f5936fadee0fd75cb722f 100644 (file)
   <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]">
  </DIV>
 
- <h1 align="CENTER">Module mod_mime_magic</h1>
+ <h1 align="CENTER">Module mod_mime_magic</H1>
 
   This module is contained in the mod_mime_magic.c file, and is
   an optional extension to the Apache HTTPD server.
   It can be used to determine the MIME type of a file by looking at a
   few bytes of its contents, the same way the Unix file(1) command works.
   To use mod_mime_magic you have to enable the following line in the
-  server build <tt>Configuration</tt> file: 
+  server build <TT>Configuration</TT> file: 
 
-  <pre>
+  <PRE>
       AddModule modules/standard/mod_mime_magic.o
-  </pre>
+  </PRE>
 
-  This should be listed <em>before</em> mod_mime in the build
-  <tt>Configuration</tt> file so that it will be used after mod_mime.
+  This should be listed <EM>before</EM> mod_mime in the build
+  <TT>Configuration</TT> file so that it will be used after mod_mime.
   mod_mime_magic is intended as a "second line of defense" for cases
   mod_mime cannot resolve.
 
   <h2>Summary</h2>
 
-  This module is derived from a free version of the <code>file(1)</code>
+  This module is derived from a free version of the <CODE>file(1)</CODE>
   command for Unix,
   which uses "magic numbers" and other hints from a file's contents to
   figure out what the contents are.
   In the case of this module,
   it tries to figure out the MIME type of the file.
-  <p>
+  <P>
   This module active only if the magic file is specified by the 
-  <A HREF="#mimemagicfile"><code>MimeMagicFile</code></a> directive.
-  <p>
+  <A HREF="#mimemagicfile"><CODE>MimeMagicFile</CODE></A> directive.
+  <P>
   The contents of the file are plain ASCII text in 4-5 columns.
   Blank lines are allowed but ignored.
   Commented lines use a hash mark "#".
   The remaining lines are parsed for the following columns:
   <table border=1>
   <tr valign=top>
-  <th>Column</th>
-  <th>Description</th>
-  </tr>
+  <TH>Column</TH>
+  <TH>Description</TH>
+  </TR>
   <tr valign=top>
-  <td>1</td>
-  <td>byte number to begin checking from
-  <br>
-  "&gt;" indicates a dependency upon the previous non-"&gt;" line</td>
-  </tr><tr valign=top>
-  <td>2</td>
-  <td>type of data to match
+  <TD>1</TD>
+  <TD>byte number to begin checking from
+  <BR>
+  "&gt;" indicates a dependency upon the previous non-"&gt;" line</TD>
+  </TR><tr valign=top>
+  <TD>2</TD>
+  <TD>type of data to match
     <table border=1>
-    <tr><td>byte</td><td>single character</td></tr>
-    <tr><td>short</td><td>machine-order 16-bit integer</td></tr>
-    <tr><td>long</td><td>machine-order 32-bit integer</td></tr>
-    <tr><td>string</td><td>arbitrary-length string</td></tr>
-    <tr><td>date</td><td>long integer date
-      (seconds since Unix epoch/1970)</td></tr>
-    <tr><td>beshort</td><td>big-endian 16-bit integer</td></tr>
-    <tr><td>belong</td><td>big-endian 32-bit integer</td></tr>
-    <tr><td>bedate</td><td>big-endian 32-bit integer date</td></tr>
-    <tr><td>leshort</td><td>little-endian 16-bit integer</td></tr>
-    <tr><td>lelong</td><td>little-endian 32-bit integer</td></tr>
-    <tr><td>ledate</td><td>little-endian 32-bit integer date</td></tr>
-    </table>
-  </td>
-  </tr><tr valign=top>
-  <td>3</td>
-  <td>contents of data to match</td>
-  </tr><tr valign=top>
-  <td>4</td>
-  <td>MIME type if matched</td>
-  </tr><tr valign=top>
-  <td>5</td>
-  <td>MIME encoding if matched (optional)</td>
-  </tr>
-  </table>
+    <TR><TD>byte</TD><TD>single character</TD></TR>
+    <TR><TD>short</TD><TD>machine-order 16-bit integer</TD></TR>
+    <TR><TD>long</TD><TD>machine-order 32-bit integer</TD></TR>
+    <TR><TD>string</TD><TD>arbitrary-length string</TD></TR>
+    <TR><TD>date</TD><TD>long integer date
+      (seconds since Unix epoch/1970)</TD></TR>
+    <TR><TD>beshort</TD><TD>big-endian 16-bit integer</TD></TR>
+    <TR><TD>belong</TD><TD>big-endian 32-bit integer</TD></TR>
+    <TR><TD>bedate</TD><TD>big-endian 32-bit integer date</TD></TR>
+    <TR><TD>leshort</TD><TD>little-endian 16-bit integer</TD></TR>
+    <TR><TD>lelong</TD><TD>little-endian 32-bit integer</TD></TR>
+    <TR><TD>ledate</TD><TD>little-endian 32-bit integer date</TD></TR>
+    </TABLE>
+  </TD>
+  </TR><tr valign=top>
+  <TD>3</TD>
+  <TD>contents of data to match</TD>
+  </TR><tr valign=top>
+  <TD>4</TD>
+  <TD>MIME type if matched</TD>
+  </TR><tr valign=top>
+  <TD>5</TD>
+  <TD>MIME encoding if matched (optional)</TD>
+  </TR>
+  </TABLE>
 
-  <p>
+  <P>
   For example, the following magic file lines
   would recognize some audio formats.
 
-<pre>
+<PRE>
 # Sun/NeXT audio data
 0       string          .snd
 &gt;12     belong          1               audio/basic
 &gt;12     belong          6               audio/basic
 &gt;12     belong          7               audio/basic
 &gt;12     belong          23              audio/x-adpcm
-</pre>
+</PRE>
 
   Or these would recognize the difference between "*.doc" files containing
   Microsoft Word or FrameMaker documents.  (These are incompatible file
   formats which use the same file suffix.)
 
-<pre>
+<PRE>
 # Frame
 0       string          \&lt;MakerFile     application/x-frame
 0       string          \&lt;MIFFile       application/x-frame
 0       string          \376\067\0\043                  application/msword
 0       string          \320\317\021\340\241\261        application/msword
 0       string          \333\245-\0\0\0                 application/msword
-</pre>
+</PRE>
 
   An optional MIME encoding can be included as a fifth column.
   For example, this can recognize gzipped files and set the encoding
   for them.
 
-<pre>
+<PRE>
 # gzip (GNU zip, not to be confused with [Info-ZIP/PKWARE] zip archiver)
 0       string          \037\213        application/octet-stream        x-gzip
-</pre>
+</PRE>
 
   <h3>Performance Issues</h3>
 
   This module is not for every system.  If your system is barely keeping
   up with its load or if you're performing a web server benchmark,
   you may not want to enable this because the processing is not free.
-  <p>
+  <P>
   However, an effort was made to improve the performance of the original
   file(1) code to make it fit in a busy web server.
   It was designed for a server where there are thousands of users who
   ...even if just to reduce the "why doesn't my page work" calls
   when users improperly name their own files.
   You have to decide if the extra work suits your environment.
-  <p>
+  <P>
   When compiling an Apache server, this module should be at or near the
   top of the list of modules in the Configuration file.  The modules are
   listed in increasing priority so that will mean this one is used only
   as a last resort, just like it was designed to.
 
   <h2>Directives</h2>
-  <p>
+  <P>
   <UL>
    <LI><A HREF="#mimemagicfile">MimeMagicFile</A>
    </LI>
    MimeMagicFile
   </A></H2>
   <P>
-  <STRONG>Syntax:</STRONG> MimeMagicFile <em>magic-file-name</em>
+  <STRONG>Syntax:</STRONG> MimeMagicFile <EM>magic-file-name</EM>
   <BR>
   <STRONG>Default:</STRONG> none
   <BR>
   <STRONG>Status:</STRONG> Extension
   <BR>
   <STRONG>Module:</STRONG> mod_mime_magic
-  <p>
+  <P>
 
-  The <code>MimeMagicFile</code> directive can be used to enable this module,
-  the default file is distributed at <code>conf/magic</code>.
+  The <CODE>MimeMagicFile</CODE> directive can be used to enable this module,
+  the default file is distributed at <CODE>conf/magic</CODE>.
   Non-rooted paths are relative to the ServerRoot.  Virtual hosts
   will use the same file as the main server unless a more specific setting
   is used, in which case the more specific setting overrides the main server's
   file.
-  <p>
+  <P>
   <HR>
 
-  <h2><a name="notes">Notes</a></h2>
+  <h2><A name="notes">Notes</A></h2>
 
   The following notes apply to the mod_mime_magic module and are
   included here for compliance with contributors' copyright restrictions
   that require their acknowledgment.
 
-<pre>
+<PRE>
 /*
  * mod_mime_magic: MIME type lookup via file magic numbers
  * Copyright (c) 1996-1997 Cisco Systems, Inc.
  * - Command-line flags have been removed since they will never be used here.
  *
  */
-</pre>
+</PRE>
 
  </BODY>
 </HTML>
index c69777f9c9c6f86c5c3236809c09b5e3e682757f..c1ba2b0b173da762bdca9ffb8ca946facd2cbf72 100644 (file)
@@ -13,9 +13,9 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_negotiation</h1>
+<H1 ALIGN="CENTER">Module mod_negotiation</H1>
 
-This module is contained in the <code>mod_negotiation.c</code> file,
+This module is contained in the <CODE>mod_negotiation.c</CODE> file,
 and is compiled in by default. It provides for <A
 HREF="../content-negotiation.html">content negotiation</A>.
 
@@ -24,13 +24,13 @@ Content negotiation, or more accurately content selection, is the
 selection of the document that best matches the clients
 capabilities, from one of several available documents.
 There are two implementations of this.
-<ul>
-<li> A type map (a file with the handler <code>type-map</code>)
+<UL>
+<LI> A type map (a file with the handler <CODE>type-map</CODE>)
 which explicitly lists the files containing the variants.
-<li> A MultiViews search (enabled by the MultiViews
+<LI> A MultiViews search (enabled by the MultiViews
 <A HREF="core.html#options">Option</A>, where the server does an implicit
 filename pattern match, and choose from amongst the results.
-</ul>
+</UL>
 
 <h3>Type maps</h3>
 A type map has the same format as RFC822 mail headers. It contains document
@@ -44,70 +44,70 @@ between the header name and value, and between the tokens of value.
 
 The headers allowed are:
 
-<dl>
-<dt>Content-Encoding:
-<dd>The encoding of the file. Currently only two encodings are recognized
-by http; <code>x-compress</code> for compressed files, and <code>x-gzip</code>
+<DL>
+<DT>Content-Encoding:
+<DD>The encoding of the file. Currently only two encodings are recognized
+by http; <CODE>x-compress</CODE> for compressed files, and <CODE>x-gzip</CODE>
 for gzipped files.
-<dt>Content-Language:
-<dd>The language of the variant, as an Internet standard language code, such
-as <code>en</code>.
-<dt>Content-Length:
-<dd>The length of the file, in bytes. If this header is not present, then
+<DT>Content-Language:
+<DD>The language of the variant, as an Internet standard language code, such
+as <CODE>en</CODE>.
+<DT>Content-Length:
+<DD>The length of the file, in bytes. If this header is not present, then
 the actual length of the file is used.
-<dt>Content-Type:
-<dd>The MIME media type of the document, with optional parameters.
+<DT>Content-Type:
+<DD>The MIME media type of the document, with optional parameters.
 parameters are separated from the media type and from one another by
 semi-colons. Parameter syntax is name=value; allowed parameters are:
-<dl>
-<dt>level
-<dd>the value is an integer, which specifies the version of the media type.
-For <code>text/html</code> this defaults to 2, otherwise 0.
-<dt>qs
-<dd>the value is a floating-point number with value between 0. and 1.
+<DL>
+<DT>level
+<DD>the value is an integer, which specifies the version of the media type.
+For <CODE>text/html</CODE> this defaults to 2, otherwise 0.
+<DT>qs
+<DD>the value is a floating-point number with value between 0. and 1.
 It indications the 'quality' of this variant.
-</dl>
+</DL>
 Example:
-<blockquote><code>Content-Type: image/jpeg; qs=0.8</code></blockquote>
-<dt>URI:
-<dd>The path to the file containing this variant, relative to the map file.
-</dl>
+<BLOCKQUOTE><CODE>Content-Type: image/jpeg; qs=0.8</CODE></BLOCKQUOTE>
+<DT>URI:
+<DD>The path to the file containing this variant, relative to the map file.
+</DL>
 
 <h3>MultiViews</h3>
 A MultiViews search is enabled by the MultiViews
 <A HREF="core.html#options">Option</A>.
-If the server receives a request for <code>/some/dir/foo</code> and
-<code>/some/dir/foo</code> does <em>not</em> exist, then the server reads the
-directory looking for all files named <code>foo.*</code>, and effectively
+If the server receives a request for <CODE>/some/dir/foo</CODE> and
+<CODE>/some/dir/foo</CODE> does <EM>not</EM> exist, then the server reads the
+directory looking for all files named <CODE>foo.*</CODE>, 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, and returns that document.<p>
+requirements, and returns that document.<P>
 
 
 
 <h2>Directives</h2>
-<ul>
-<li><A href="#cachenegotiateddocs">CacheNegotiatedDocs</a>
-<li><A HREF="#languagepriority">LanguagePriority</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#cachenegotiateddocs">CacheNegotiatedDocs</A>
+<LI><A HREF="#languagepriority">LanguagePriority</A>
+</UL>
+<HR>
 
 
 <h2><A name="cachenegotiateddocs">CacheNegotiatedDocs</A></h2>
-<strong>Syntax:</strong> CacheNegotiatedDocs<br>
-<Strong>Context:</strong> server config<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_negotiation<br>
-<strong>Compatibility:</strong> CacheNegotiatedDocs is only available
-in Apache 1.1 and later.<p>
-
-<p>If set, this directive allows content-negotiated documents to be
+<STRONG>Syntax:</STRONG> CacheNegotiatedDocs<BR>
+<Strong>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_negotiation<BR>
+<STRONG>Compatibility:</STRONG> CacheNegotiatedDocs is only available
+in Apache 1.1 and later.<P>
+
+<P>If set, this directive allows content-negotiated documents to be
 cached by proxy servers. This could mean that clients behind those
 proxys could retrieve versions of the documents that are not the best
 match for their abilities, but it will make caching more
 efficient.
-<p>
+<P>
 
 This directive only applies to requests which come from HTTP/1.0 browsers.
 HTTP/1.1 provides much better control over the caching of negotiated
@@ -118,22 +118,22 @@ HTTP/1.1 requests.
 
 <h2><A name="languagepriority">LanguagePriority</A></h2>
 <!--%plaintext &lt;?INDEX {\tt LanguagePriority} directive&gt; -->
-<strong>Syntax:</strong> LanguagePriority <em>mime-lang mime-lang...</em><br>
-<Strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
-<Strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_negotiation<p>
+<STRONG>Syntax:</STRONG> LanguagePriority <EM>mime-lang mime-lang...</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host, directory, .htaccess<BR>
+<Strong>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_negotiation<P>
 
 The LanguagePriority sets the precedence of language variants for the case
 where the client does not express a preference, when handling a
-MultiViews request. The list of <em>mime-lang</em> are in order of decreasing
+MultiViews request. The list of <EM>mime-lang</EM> are in order of decreasing
 preference. Example:
 
-<blockquote><code>LanguagePriority en fr de</code></blockquote>
+<BLOCKQUOTE><CODE>LanguagePriority en fr de</CODE></BLOCKQUOTE>
 
-For a request for <code>foo.html</code>, where <code>foo.html.fr</code>
-and <code>foo.html.de</code> both existed, but the browser did not express
-a language preference, then <code>foo.html.fr</code> would be returned.<p>
+For a request for <CODE>foo.html</CODE>, where <CODE>foo.html.fr</CODE>
+and <CODE>foo.html.de</CODE> both existed, but the browser did not express
+a language preference, then <CODE>foo.html.fr</CODE> would be returned.<P>
 
 <P>
 
index 43e7dff8e0caeebace57580799c95f3f25897245..b571bb3a91eb76d54a53592e84e67af67c63a9fc 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache module mod_proxy</h1>
+<H1 ALIGN="CENTER">Apache module mod_proxy</H1>
 
-This module is contained in the <code>mod_proxy.c</code> file for Apache 1.1.x,
-or the <code>modules/proxy</code> subdirectory for Apache 1.2, and
+This module is contained in the <CODE>mod_proxy.c</CODE> file for Apache 1.1.x,
+or the <CODE>modules/proxy</CODE> subdirectory for Apache 1.2, and
 is not compiled in by default. It provides for an <STRONG>HTTP
 1.0</STRONG> caching proxy 
 server. It is only available in Apache 1.1 and later. Common configuration
-questions are addressed <a href="#configs">after the directive
-descriptions</a>.
+questions are addressed <A HREF="#configs">after the directive
+descriptions</A>.
 
 <h3>Note:</h3>
-<p>This module was experimental in Apache 1.1.x. As of Apache 1.2, mod_proxy
-stability is <EM>greatly</EM> improved.<p>
+<P>This module was experimental in Apache 1.1.x. As of Apache 1.2, mod_proxy
+stability is <EM>greatly</EM> improved.<P>
 
 <h2>Summary</h2>
 
 This module implements a proxy/cache for Apache. It implements
 proxying capability for
-<code>FTP</code>,
-<code>CONNECT</code> (for SSL),
-<code>HTTP/0.9</code>, and
-<code>HTTP/1.0</code>.
+<CODE>FTP</CODE>,
+<CODE>CONNECT</CODE> (for SSL),
+<CODE>HTTP/0.9</CODE>, and
+<CODE>HTTP/1.0</CODE>.
 The module can be configured to connect to other proxy modules for these
 and other protocols.
 
 <h2>Directives</h2>
-<ul>
-<li><a href="#proxyrequests">ProxyRequests</a>
-<li><a href="#proxyremote">ProxyRemote</a>
-<li><a href="#proxypass">ProxyPass</a>
-<li><a href="#proxyblock">ProxyBlock</a>
-<li><a href="#noproxy">NoProxy</a>
-<li><a href="#proxydomain">ProxyDomain</a>
-<li><a href="#cacheroot">CacheRoot</a>
-<li><a href="#cachesize">CacheSize</a>
-<li><a href="#cachemaxexpire">CacheMaxExpire</a>
-<li><a href="#cachedefaultexpire">CacheDefaultExpire</a>
-<li><a href="#cachelastmodifiedfactor">CacheLastModifiedFactor</a>
-<li><a href="#cachegcinterval">CacheGcInterval</a>
-<li><a href="#cachedirlevels">CacheDirLevels</a>
-<li><a href="#cachedirlength">CacheDirLength</a>
-<li><a href="#nocache">NoCache</a>
-</ul>
-
-<hr>
+<UL>
+<LI><A HREF="#proxyrequests">ProxyRequests</A>
+<LI><A HREF="#proxyremote">ProxyRemote</A>
+<LI><A HREF="#proxypass">ProxyPass</A>
+<LI><A HREF="#proxyblock">ProxyBlock</A>
+<LI><A HREF="#noproxy">NoProxy</A>
+<LI><A HREF="#proxydomain">ProxyDomain</A>
+<LI><A HREF="#cacheroot">CacheRoot</A>
+<LI><A HREF="#cachesize">CacheSize</A>
+<LI><A HREF="#cachemaxexpire">CacheMaxExpire</A>
+<LI><A HREF="#cachedefaultexpire">CacheDefaultExpire</A>
+<LI><A HREF="#cachelastmodifiedfactor">CacheLastModifiedFactor</A>
+<LI><A HREF="#cachegcinterval">CacheGcInterval</A>
+<LI><A HREF="#cachedirlevels">CacheDirLevels</A>
+<LI><A HREF="#cachedirlength">CacheDirLength</A>
+<LI><A HREF="#nocache">NoCache</A>
+</UL>
+
+<HR>
 
 <A name="proxyrequests"><h2>ProxyRequests</h2></A>
-<strong>Syntax:</strong> ProxyRequests <em>on/off</em><br>
-<strong>Default:</strong> <code>ProxyRequests Off</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> ProxyRequests is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ProxyRequests <EM>on/off</EM><BR>
+<STRONG>Default:</STRONG> <CODE>ProxyRequests Off</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> ProxyRequests is only available in
+Apache 1.1 and later.<P>
 
 This allows or prevents Apache from functioning as a proxy
-server. Setting ProxyRequests to 'off' does not disable use of the <a
-href="#proxypass">ProxyPass</a> directive.
+server. Setting ProxyRequests to 'off' does not disable use of the <A
+HREF="#proxypass">ProxyPass</A> directive.
 
 <HR>
 
 <A name="proxyremote"><h2>ProxyRemote</h2></A>
-<strong>Syntax:</strong> ProxyRemote <em>&lt;match&gt; &lt;remote-server&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> ProxyRemote is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ProxyRemote <EM>&lt;match&gt; &lt;remote-server&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> ProxyRemote is only available in
+Apache 1.1 and later.<P>
 
 This defines remote proxies to this proxy. &lt;match&gt; is either the
 name of a URL-scheme that the remote server supports, or a partial URL
@@ -91,19 +91,19 @@ for which the remote server should be used, or '*' to indicate the
 server should be contacted for all requests. &lt;remote-server&gt; is a
 partial URL for the remote server. Syntax:
 
-<pre>
+<PRE>
   &lt;remote-server&gt; = &lt;protocol&gt;://&lt;hostname&gt;[:port]
-</pre>
+</PRE>
 
 &lt;protocol&gt; is the protocol that should be used to communicate
 with the remote server; only "http" is supported by this module.
 <P>
 Example:
-<pre>
+<PRE>
   ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
   ProxyRemote * http://cleversite.com
   ProxyRemote ftp http://ftpproxy.mydomain.com:8080
-</pre>
+</PRE>
 
 In the last example, the proxy will forward FTP requests, encapsulated
 as yet another HTTP proxy request, to another proxy which can handle
@@ -112,14 +112,14 @@ them.
 <HR>
 
 <A name="proxypass"><h2>ProxyPass</h2></A>
-<strong>Syntax:</strong> ProxyPass <em>&lt;path&gt; &lt;url&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> ProxyPass is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> ProxyPass <EM>&lt;path&gt; &lt;url&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> ProxyPass is only available in
+Apache 1.1 and later.<P>
 
 This directive allows remote servers to be mapped into the space of the local
 server; the local server does not act as a proxy in the conventional sense,
@@ -127,9 +127,9 @@ but appears to be a mirror of the remote server. &lt;path&gt; is the name of
 a local virtual path; &lt;url&gt; is a partial URL for the remote server.
 <P>
 Suppose the local server has address <SAMP>http://wibble.org/</SAMP>; then
-<pre>
+<PRE>
    ProxyPass /mirror/foo http://foo.com
-</pre>
+</PRE>
 will cause a local request for the
 &lt;<SAMP>http://wibble.org/mirror/foo/bar</SAMP>&gt; to be
 internally converted into a proxy request to
@@ -138,52 +138,52 @@ internally converted into a proxy request to
 <HR>
 
 <A name="proxyblock"><h2>ProxyBlock</h2></A>
-<strong>Syntax:</strong> ProxyBlock <em>&lt;word/host/domain list&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> ProxyBlock is only available in
-Apache 1.2 and later.<p>
+<STRONG>Syntax:</STRONG> ProxyBlock <EM>&lt;word/host/domain list&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> ProxyBlock is only available in
+Apache 1.2 and later.<P>
 
 The ProxyBlock directive specifies a list of words, hosts and/or domains,
 separated by spaces. HTTP, HTTPS, and FTP document requests to matched words,
-hosts or domains are <em>blocked</em> by the proxy server. The proxy module
+hosts or domains are <EM>blocked</EM> by the proxy server. The proxy module
 will also attempt to determine IP addresses of list items which may be
 hostnames during startup, and cache them for match test as well. Example:
 
-<pre>
+<PRE>
   ProxyBlock joes_garage.com some_host.co.uk rocky.wotsamattau.edu
-</pre>
+</PRE>
 
-'rocky.wotsamattau.edu' would also be matched if referenced by IP address.<p>
+'rocky.wotsamattau.edu' would also be matched if referenced by IP address.<P>
 
-Note that 'wotsamattau' would also be sufficient to match 'wotsamattau.edu'.<p>
+Note that 'wotsamattau' would also be sufficient to match 'wotsamattau.edu'.<P>
 
 Note also that
 
-<pre>
+<PRE>
 ProxyBlock *
-</pre>
+</PRE>
 
 blocks connections to all sites.
 
 <HR>
 
 <A name="noproxy"><h2>NoProxy</h2></A>
-<strong>Syntax:</strong> NoProxy { <A HREF="#domain"><em>&lt;Domain&gt;</em></A>
-                                 | <A HREF="#subnet"><em>&lt;SubNet&gt;</em></A>
-                                | <A HREF="#ipaddr"><em>&lt;IpAddr&gt;</em></A>
-                                | <A HREF="#hostname"><em>&lt;Hostname&gt;</em></A>
-                                } <br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> NoProxy is only available in
-Apache 1.3 and later.<p>
+<STRONG>Syntax:</STRONG> NoProxy { <A HREF="#domain"><EM>&lt;Domain&gt;</EM></A>
+                                 | <A HREF="#subnet"><EM>&lt;SubNet&gt;</EM></A>
+                                | <A HREF="#ipaddr"><EM>&lt;IpAddr&gt;</EM></A>
+                                | <A HREF="#hostname"><EM>&lt;Hostname&gt;</EM></A>
+                                } <BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> NoProxy is only available in
+Apache 1.3 and later.<P>
 
 This directive is only useful for Apache proxy servers within intranets.
 The NoProxy directive specifies a list of subnets, IP addresses, hosts
@@ -193,10 +193,10 @@ the configured ProxyRemote proxy server(s).
 <P>
 Example:
 
-<pre>
+<PRE>
   ProxyRemote  *  http://firewall.mycompany.com:81
   NoProxy         .mycompany.com 192.168.112.0/21 
-</pre>
+</PRE>
 The arguments to the NoProxy directive are one of the following type list:
    <DL>
     <!-- ===================== Domain ======================= -->
@@ -254,8 +254,8 @@ The arguments to the NoProxy directive are one of the following type list:
                Example: 192.168.123.7<BR>
         Note: An <EM>IPAddr</EM> does not need to be resolved by the DNS
        system, so it can result in more effective apache performance.
-        <p><strong>See Also:</strong>
-       <a href="../dns-caveats.html">DNS Issues</a></p>
+        <P><STRONG>See Also:</STRONG>
+       <A HREF="../dns-caveats.html">DNS Issues</A></P>
 
     <!-- ===================== Hostname ======================= -->
     <A NAME="hostname">
@@ -281,47 +281,47 @@ The arguments to the NoProxy directive are one of the following type list:
         of the DNS tree, therefore two hosts <SAMP>WWW.MyDomain.com</SAMP>
         and <SAMP>www.mydomain.com.</SAMP> (note the trailing period) are
         considered equal.<BR>
-<p><strong>See Also:</strong>
-<a href="../dns-caveats.html">DNS Issues</a></p>
+<P><STRONG>See Also:</STRONG>
+<A HREF="../dns-caveats.html">DNS Issues</A></P>
    </DL>
 
 <HR>
 
 <A name="proxydomain"><h2>ProxyDomain</h2></A>
-<strong>Syntax:</strong> ProxyDomain <em>&lt;Domain&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> ProxyDomain is only available in
-Apache 1.3 and later.<p>
+<STRONG>Syntax:</STRONG> ProxyDomain <EM>&lt;Domain&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> ProxyDomain is only available in
+Apache 1.3 and later.<P>
 
 This directive is only useful for Apache proxy servers within intranets.
 The ProxyDomain directive specifies the default domain which the apache
 proxy server will belong to. If a request to a host without a domain name
 is encountered, a redirection response to the same host
-with the configured <em>Domain</em> appended will be generated. 
+with the configured <EM>Domain</EM> appended will be generated. 
 <P>
 Example:
 
-<pre>
+<PRE>
   ProxyRemote  *  http://firewall.mycompany.com:81
   NoProxy         .mycompany.com 192.168.112.0/21 
   ProxyDomain     .mycompany.com
-</pre>
+</PRE>
 
 <HR>
 
 <A name="cacheroot"><h2>CacheRoot</h2></A>
-<strong>Syntax:</strong> CacheRoot <em>&lt;directory&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheRoot is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheRoot <EM>&lt;directory&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheRoot is only available in
+Apache 1.1 and later.<P>
 
 Sets the name of the directory to contain cache files; this must be
 writable
@@ -330,14 +330,14 @@ by the httpd server.
 <HR>
 
 <A name="cachesize"><h2>CacheSize</h2></A>
-<strong>Syntax:</strong> CacheSize <em>&lt;size&gt;</em><br>
-<strong>Default:</strong> <code>CacheSize 5</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheSize is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheSize <EM>&lt;size&gt;</EM><BR>
+<STRONG>Default:</STRONG> <CODE>CacheSize 5</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheSize is only available in
+Apache 1.1 and later.<P>
 
 Sets the desired space usage of the cache, in KB (1024-byte units). Although
 usage may grow above this setting, the garbage collection will delete files
@@ -346,14 +346,14 @@ until the usage is at or below this setting.
 <HR>
 
 <A name="cachegcinterval"><h2>CacheGcInterval</h2></A>
-<strong>Syntax:</strong> CacheGcInterval <em>&lt;time&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheGcinterval is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheGcInterval <EM>&lt;time&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheGcinterval is only available in
+Apache 1.1 and later.<P>
 
 Check the cache every &lt;time&gt; hours, and delete files if the space
 usage is greater than that set by CacheSize.
@@ -361,14 +361,14 @@ usage is greater than that set by CacheSize.
 <HR>
 
 <A name="cachemaxexpire"><h2>CacheMaxExpire</h2></A>
-<strong>Syntax:</strong> CacheMaxExpire <em>&lt;time&gt;</em><br>
-<strong>Default:</strong> <code>CacheMaxExpire 24</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheMaxExpire is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheMaxExpire <EM>&lt;time&gt;</EM><BR>
+<STRONG>Default:</STRONG> <CODE>CacheMaxExpire 24</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheMaxExpire is only available in
+Apache 1.1 and later.<P>
 
 Cachable HTTP documents will be retained for at most &lt;time&gt; hours without
 checking the origin server. Thus documents can be at most &lt;time&gt;
@@ -378,37 +378,37 @@ was supplied with the document.
 <HR>
 
 <A name="cachelastmodifiedfactor"><h2>CacheLastModifiedFactor</h2></A>
-<strong>Syntax:</strong> CacheLastModifiedFactor <em>&lt;factor&gt;</em><br>
-<strong>Default:</strong> <code>CacheLastModifiedFactor 0.1</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheLastModifiedFactor is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheLastModifiedFactor <EM>&lt;factor&gt;</EM><BR>
+<STRONG>Default:</STRONG> <CODE>CacheLastModifiedFactor 0.1</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheLastModifiedFactor is only available in
+Apache 1.1 and later.<P>
 
 If the origin HTTP server did not supply an expiry date for the
 document, then estimate one using the formula
-<pre>
+<PRE>
   expiry-period = time-since-last-modification * &lt;factor&gt;
-</pre>
+</PRE>
 For example, if the document was last modified 10 hours ago, and
 &lt;factor&gt; is 0.1, then the expiry period will be set to 10*0.1 = 1 hour.
 
-<p>If the expiry-period would be longer than that set by CacheMaxExpire,
+<P>If the expiry-period would be longer than that set by CacheMaxExpire,
 then the latter takes precedence.
 
 <HR>
 
 <A name="cachedirlevels"><h2>CacheDirLevels</h2></A>
-<strong>Syntax:</strong> CacheDirLevels <em>&lt;levels&gt;</em><br>
-<strong>Default:</strong> <code>CacheDirLevels 3</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheDirLevels is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheDirLevels <EM>&lt;levels&gt;</EM><BR>
+<STRONG>Default:</STRONG> <CODE>CacheDirLevels 3</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheDirLevels is only available in
+Apache 1.1 and later.<P>
 
 CacheDirLevels sets the number of levels of subdirectories in the cache.
 Cached data will be saved this many directory levels below CacheRoot.
@@ -416,89 +416,89 @@ Cached data will be saved this many directory levels below CacheRoot.
 <HR>
 
 <A name="cachedirlength"><h2>CacheDirLength</h2></A>
-<strong>Syntax:</strong> CacheDirLength <em>&lt;length&gt;</em><br>
-<strong>Default:</strong> <code>CacheDirLength 1</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheDirLength is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheDirLength <EM>&lt;length&gt;</EM><BR>
+<STRONG>Default:</STRONG> <CODE>CacheDirLength 1</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheDirLength is only available in
+Apache 1.1 and later.<P>
 
 CacheDirLength sets the number of characters in proxy cache subdirectory names.
 
 <HR>
 
 <A name="cachedefaultexpire"><h2>CacheDefaultExpire</h2></A>
-<strong>Syntax:</strong> CacheDefaultExpire <em>&lt;time&gt;</em><br>
-<strong>Default:</strong> <code>CacheDefaultExpire 1</code><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheDefaultExpire is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> CacheDefaultExpire <EM>&lt;time&gt;</EM><BR>
+<STRONG>Default:</STRONG> <CODE>CacheDefaultExpire 1</CODE><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> CacheDefaultExpire is only available in
+Apache 1.1 and later.<P>
 
 If the document is fetched via a protocol that does not support expiry times,
 then use &lt;time&gt; hours as the expiry time.
-<a href="#cachemaxexpire">CacheMaxExpire</a> does <strong>not</strong>
+<A HREF="#cachemaxexpire">CacheMaxExpire</A> does <STRONG>not</STRONG>
 override this setting.
 
 <HR>
 
 <A name="nocache"><h2>NoCache</h2></A>
-<strong>Syntax:</strong> NoCache <em>&lt;word/host/domain list&gt;</em><br>
-<strong>Default:</strong> <EM>None</EM><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Override:</strong> <EM>Not applicable</EM><br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> NoCache is only available in
-Apache 1.1 and later.<p>
+<STRONG>Syntax:</STRONG> NoCache <EM>&lt;word/host/domain list&gt;</EM><BR>
+<STRONG>Default:</STRONG> <EM>None</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Override:</STRONG> <EM>Not applicable</EM><BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_proxy<BR>
+<STRONG>Compatibility:</STRONG> NoCache is only available in
+Apache 1.1 and later.<P>
 
 The NoCache directive specifies a list of words, hosts and/or domains, separated
 by spaces. HTTP and non-passworded FTP documents from matched words, hosts or
-domains are <em>not</em> cached by the proxy server. The proxy module will
+domains are <EM>not</EM> cached by the proxy server. The proxy module will
 also attempt to determine IP addresses of list items which may be hostnames
 during startup, and cache them for match test as well. Example:
 
-<pre>
+<PRE>
   NoCache joes_garage.com some_host.co.uk bullwinkle.wotsamattau.edu
-</pre>
+</PRE>
 
 'bullwinkle.wotsamattau.edu' would also be matched if referenced by IP
-address.<p>
+address.<P>
 
-Note that 'wotsamattau' would also be sufficient to match 'wotsamattau.edu'.<p>
+Note that 'wotsamattau' would also be sufficient to match 'wotsamattau.edu'.<P>
 
 Note also that
 
-<pre>
+<PRE>
 NoCache *
-</pre>
+</PRE>
 
-disables caching completely.<p>
+disables caching completely.<P>
 
-<hr>
+<HR>
 
-<a name="configs"><h2>Common configuration topics</h2></a>
+<A name="configs"><h2>Common configuration topics</h2></A>
 
-<ul>
-<li><a href="#access">Controlling access to your proxy</a>
-<li><a href="#shortname">Using Netscape hostname shortcuts</a>
-<li><a href="#mimetypes">Why doesn't file type <EM>xxx</EM> download via FTP?</a>
-<li><a href="#startup">Why does Apache start more slowly when using the
-        proxy module?</a>
-<li><a href="#socks">Can I use the Apache proxy module with my SOCKS proxy?</a>
-<li><a href="#intranet">What other functions are useful for an intranet proxy server?</a>
-</ul>
+<UL>
+<LI><A HREF="#access">Controlling access to your proxy</A>
+<LI><A HREF="#shortname">Using Netscape hostname shortcuts</A>
+<LI><A HREF="#mimetypes">Why doesn't file type <EM>xxx</EM> download via FTP?</A>
+<LI><A HREF="#startup">Why does Apache start more slowly when using the
+        proxy module?</A>
+<LI><A HREF="#socks">Can I use the Apache proxy module with my SOCKS proxy?</A>
+<LI><A HREF="#intranet">What other functions are useful for an intranet proxy server?</A>
+</UL>
 
-<h2><a name="access">Controlling access to your proxy</a></h2>
+<h2><A name="access">Controlling access to your proxy</A></h2>
 
 You can control who can access your proxy via the normal &lt;Directory&gt;
-control block using the following example:<p>
+control block using the following example:<P>
 
-<pre>
+<PRE>
 &lt;Directory proxy:*&gt;
 &lt;Limit GET PUT POST DELETE CONNECT OPTIONS&gt;
 order deny,allow
@@ -506,68 +506,68 @@ deny from [machines you'd like *not* to allow by IP address or name]
 allow from [machines you'd like to allow by IP address or name]
 &lt;/Limit&gt;
 &lt;/Directory&gt;
-</pre><p>
+</PRE><P>
 
 A &lt;Files&gt; block will also work, and is the only method known to work
-for all possible URLs in Apache versions earlier than 1.2b10.<p>
+for all possible URLs in Apache versions earlier than 1.2b10.<P>
 
-<h2><a name="shortname">Using Netscape hostname shortcuts</a></h2>
+<h2><A name="shortname">Using Netscape hostname shortcuts</A></h2>
 
 There is an optional patch to the proxy module to allow Netscape-like
 hostname shortcuts to be used. It's available
-<a href="http://www.apache.org/dist/contrib/patches/1.2/netscapehost.patch">
-here</a>.<p>
+<A HREF="http://www.apache.org/dist/contrib/patches/1.2/netscapehost.patch">
+here</A>.<P>
 
-<h2><a name="mimetypes">Why doesn't file type <EM>xxx</EM> download via FTP?</a></h2>
+<h2><A name="mimetypes">Why doesn't file type <EM>xxx</EM> download via FTP?</A></h2>
 
 You probably don't have that particular file type defined as
 <EM>application/octet-stream</EM> in your proxy's mime.types configuration
-file. A useful line can be<p>
+file. A useful line can be<P>
 
-<pre>
+<PRE>
 application/octet-stream        bin dms lha lzh exe class tgz taz
-</pre>
+</PRE>
 
-<h2><a name="type">How can I force an FTP ASCII download of File <EM>xxx</EM>?</a></h2>
+<h2><A name="type">How can I force an FTP ASCII download of File <EM>xxx</EM>?</A></h2>
 
 In the rare situation where you must download a specific file using the FTP
 <STRONG>ASCII</STRONG> transfer method (while the default transfer is in
 <STRONG>binary</STRONG> mode), you can override mod_proxy's default by
-suffixing the request with <SAMP>;type=a</SAMP> to force an ASCII transfer.<p>
+suffixing the request with <SAMP>;type=a</SAMP> to force an ASCII transfer.<P>
 
-<h2><a name="startup">Why does Apache start more slowly when using the
-        proxy module?</a></h2>
+<h2><A name="startup">Why does Apache start more slowly when using the
+        proxy module?</A></h2>
 
-If you're using the <code>ProxyBlock</code> or <code>NoCache</code>
+If you're using the <CODE>ProxyBlock</CODE> or <CODE>NoCache</CODE>
 directives, hostnames' IP addresses are looked up and cached during
 startup for later match test. This may take a few seconds (or more)
-depending on the speed with which the hostname lookups occur.<p>
+depending on the speed with which the hostname lookups occur.<P>
 
-<h2><a name="socks">Can I use the Apache proxy module with my SOCKS proxy?</a></h2>
+<h2><A name="socks">Can I use the Apache proxy module with my SOCKS proxy?</A></h2>
 
-Yes. Just build Apache with the rule <code>SOCKS4=yes</code> in your
+Yes. Just build Apache with the rule <CODE>SOCKS4=yes</CODE> in your
 <EM>Configuration</EM> file, and follow the instructions there. SOCKS5
-capability can be added in a similar way (there's no <code>SOCKS5</code>
-rule yet), so use the <code>EXTRA_LDFLAGS</code> definition, or build Apache
+capability can be added in a similar way (there's no <CODE>SOCKS5</CODE>
+rule yet), so use the <CODE>EXTRA_LDFLAGS</CODE> definition, or build Apache
 normally and run it with the <EM>runsocks</EM> wrapper provided with SOCKS5,
-if your OS supports dynamically linked libraries.<p>
+if your OS supports dynamically linked libraries.<P>
 
 Some users have reported problems when using SOCKS version 4.2 on Solaris.
-The problem was solved by upgrading to SOCKS 4.3.<p>
+The problem was solved by upgrading to SOCKS 4.3.<P>
 
 Remember that you'll also have to grant access to your Apache proxy machine by
 permitting connections on the appropriate ports in your SOCKS daemon's
-configuration.<p>
+configuration.<P>
 
-<h2><a name="intranet">What other functions are useful for an intranet proxy server?</a></h2>
+<h2><A name="intranet">What other functions are useful for an intranet proxy server?</A></h2>
 
-<p>An Apache proxy server situated in an intranet needs to forward external
+<P>An Apache proxy server situated in an intranet needs to forward external
 requests through the company's firewall. However, when it has to access
 resources within the intranet, it can bypass the firewall when accessing
 hosts. The <A HREF="#noproxy">NoProxy</A> directive is useful for specifying
-which hosts belong to the intranet and should be accessed directly.</p>
+which hosts belong to the intranet and should be accessed directly.</P>
 
-<p>Users within an intranet tend to omit the local domain name from their
+<P>Users within an intranet tend to omit the local domain name from their
 WWW requests, thus requesting "http://somehost/" instead of
 "http://somehost.my.dom.ain/". Some commercial proxy servers let them get
 away with this and simply serve the request, implying a configured
@@ -575,7 +575,7 @@ local domain. When the <A HREF="#proxydomain">ProxyDomain</A> directive
 is used and the server is <A HREF="#proxyrequests">configured for
 proxy service</A>, Apache can return a redirect response and send the client
 to the correct, fully qualified, server address. This is the preferred method
-since the user's bookmark files will then contain fully qualified hosts.</p>
+since the user's bookmark files will then contain fully qualified hosts.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 366bf7afa40c5d82c29922932e089bb8fa59afba..be9cb2215ea97b8b9320a604c56f50c8bfba2d55 100644 (file)
@@ -2,10 +2,10 @@
 <!--%hypertext -->
 <!-- mod_rewrite.html                                 -->
 <!-- Documentation for the mod_rewrite Apache module  -->
-<html>
-<head>
-<title>Apache module mod_rewrite</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache module mod_rewrite</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
 >
 <!--#include virtual="header.html" -->
 
-<h1 ALIGN="CENTER">Module mod_rewrite</h1>
+<h1 ALIGN="CENTER">Module mod_rewrite</H1>
 
-This module is contained in the <code>mod_rewrite.c</code> file, with Apache
+This module is contained in the <CODE>mod_rewrite.c</CODE> file, with Apache
 1.2 and later.  It provides a rule-based rewriting engine to rewrite requested
-URLs on the fly.   <code>mod_rewrite</code> is not compiled into the server by
-default. To use <code>mod_rewrite</code> you have to enable the following line
+URLs on the fly.   <CODE>mod_rewrite</CODE> is not compiled into the server by
+default. To use <CODE>mod_rewrite</CODE> you have to enable the following line
 in the server build Configuration file:
-<pre>
+<PRE>
     AddModule  modules/standard/mod_rewrite.o
-</pre>
+</PRE>
 
 <h2>Summary</h2>
 
 This module uses a rule-based rewriting engine (based on a
 regular-expression parser) to rewrite requested URLs on the fly.
 
-<p>
+<P>
 It supports an unlimited number of additional rule conditions (which can
 operate on a lot of variables, including HTTP headers) for granular
 matching and external database lookups (either via plain text
 tables, DBM hash files or external processes) for advanced URL
 substitution.
 
-<p>
+<P>
 It operates on the full URLs (including the PATH_INFO part) both in per-server
 context (httpd.conf) and per-dir context (.htaccess) and even can generate
 QUERY_STRING parts on result.   The rewritten result can lead to internal
 sub-processing, external request redirection or to internal proxy throughput.
 
-<p>
+<P>
 This module was originally written in April 1996 and 
 gifted exclusively to the The Apache Group in July 1997 by
-<p>
-<blockquote>
-    <i>Ralf S. Engelschall</i><br>
-    <a href="mailto:rse@engelschall.com"><tt>rse@engelschall.com</tt></a><br>
-    <a href="http://www.engelschall.com/"><tt>www.engelschall.com</tt></a>
-</blockquote>
+<P>
+<BLOCKQUOTE>
+    <EM>Ralf S. Engelschall</EM><BR>
+    <A HREF="mailto:rse@engelschall.com"><TT>rse@engelschall.com</TT></A><BR>
+    <A HREF="http://www.engelschall.com/"><TT>www.engelschall.com</TT></A>
+</BLOCKQUOTE>
 
 <!--%hypertext -->
 <HR>
 <!--/%hypertext -->
 
-<p>
+<P>
 <h2>Directives</h2>
 
-<ul>
-    <li><a href="#RewriteEngine">RewriteEngine</a>
-    <li><a href="#RewriteOptions">RewriteOptions</a>
-    <li><a href="#RewriteLog">RewriteLog</a>
-    <li><a href="#RewriteLogLevel">RewriteLogLevel</a>
-    <li><a href="#RewriteMap">RewriteMap</a>
-    <li><a href="#RewriteBase">RewriteBase</a>
-    <li><a href="#RewriteCond">RewriteCond</a>
-    <li><a href="#RewriteRule">RewriteRule</a>
-</ul>
+<UL>
+    <LI><A HREF="#RewriteEngine">RewriteEngine</A>
+    <LI><A HREF="#RewriteOptions">RewriteOptions</A>
+    <LI><A HREF="#RewriteLog">RewriteLog</A>
+    <LI><A HREF="#RewriteLogLevel">RewriteLogLevel</A>
+    <LI><A HREF="#RewriteMap">RewriteMap</A>
+    <LI><A HREF="#RewriteBase">RewriteBase</A>
+    <LI><A HREF="#RewriteCond">RewriteCond</A>
+    <LI><A HREF="#RewriteRule">RewriteRule</A>
+</UL>
 
 <!--%hypertext -->
-<hr>
+<HR>
 <!--/%hypertext -->
 
 
-<center>
-<a name="Configuration">
-<h1>Configuration Directives</h1>
-</a>
-</center>
+<CENTER>
+<A name="Configuration">
+<H1>Configuration Directives</H1>
+</A>
+</CENTER>
 
-<a name="RewriteEngine"><h3>RewriteEngine</h3></a>
-<strong>Syntax:</strong> <code>RewriteEngine</code> {<code>on,off</code>}<br>
-<strong>Default:</strong> <strong><code>RewriteEngine off</code></strong><br>
-<strong>Context:</strong> server config, virtual host, per-directory config<br>
-<p>
+<A name="RewriteEngine"><h3>RewriteEngine</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteEngine</CODE> {<CODE>on,off</CODE>}<BR>
+<STRONG>Default:</STRONG> <STRONG><CODE>RewriteEngine off</CODE></STRONG><BR>
+<STRONG>Context:</STRONG> server config, virtual host, per-directory config<BR>
+<P>
 
-The <tt>RewriteEngine</tt> directive enables or disables the
-runtime rewriting engine. If it is set to <code>off</code> this module does
-no runtime processing at all. It does not even update the <tt>SCRIPT_URx</tt>
+The <TT>RewriteEngine</TT> directive enables or disables the
+runtime rewriting engine. If it is set to <CODE>off</CODE> this module does
+no runtime processing at all. It does not even update the <TT>SCRIPT_URx</TT>
 environment variables.
 
-<p>
+<P>
 Use this directive to disable the module instead of commenting out
-all <tt>RewriteRule</tt> directives!
+all <TT>RewriteRule</TT> directives!
 
-<p>
+<P>
 Note that, by default, rewrite configurations are not inherited.
-This means that you need to have a <tt>RewriteEngine on</tt>
+This means that you need to have a <TT>RewriteEngine on</TT>
 directive for each virtual host you wish to use it in, unless <A
 HREF="#RewriteOptions">RewriteOptions inherit</A> is enabled.
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteOptions"><h3>RewriteOptions</h3></a>
-<strong>Syntax:</strong> <code>RewriteOptions</code> <em>Option</em> ...<br>
-<strong>Default:</strong> -<em>None</em>-<br>
-<strong>Context:</strong> server config, virtual host, per-directory config<br>
-<p>
+<A name="RewriteOptions"><h3>RewriteOptions</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteOptions</CODE> <EM>Option</EM> ...<BR>
+<STRONG>Default:</STRONG> -<EM>None</EM>-<BR>
+<STRONG>Context:</STRONG> server config, virtual host, per-directory config<BR>
+<P>
 
-The <tt>RewriteOptions</tt> directive sets some special options for the
-current per-server or per-directory configuration. The <em>Option</em>
+The <TT>RewriteOptions</TT> directive sets some special options for the
+current per-server or per-directory configuration. The <EM>Option</EM>
 strings can be one of the following:
 
-<ul>
-<li>'<strong><code>inherit</code></strong>'<br>
+<UL>
+<LI>'<STRONG><CODE>inherit</CODE></STRONG>'<BR>
     This forces the current configuration to inherit the configuration of the
     parent. In per-virtual-server context this means that the maps,
     conditions and rules of the main server gets inherited. In per-directory
     context this means that conditions and rules of the parent directory's
-    <tt>.htaccess</tt> configuration gets inherited.
-</ul>
+    <TT>.htaccess</TT> configuration gets inherited.
+</UL>
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteLog"><h3>RewriteLog</h3></a>
-<strong>Syntax:</strong> <code>RewriteLog</code> <em>Filename</em><br>
-<strong>Default:</strong> -<em>None</em>-<br>
-<strong>Context:</strong> server config, virtual host<br>
-<p>
+<A name="RewriteLog"><h3>RewriteLog</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteLog</CODE> <EM>Filename</EM><BR>
+<STRONG>Default:</STRONG> -<EM>None</EM>-<BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<P>
 
-The <tt>RewriteLog</tt> directive sets the name of the file to which the
+The <TT>RewriteLog</TT> directive sets the name of the file to which the
 server logs any rewriting actions it performs. If the name does not begin
-with a slash ('<tt>/</tt>') then it is assumed to be relative to the
-<em>Server Root</em>.  The directive should occur only once per server
+with a slash ('<TT>/</TT>') then it is assumed to be relative to the
+<EM>Server Root</EM>.  The directive should occur only once per server
 config.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#f0f0f0" cellspacing=0 cellpadding=10>
-<tr><td>
+<TR><TD>
 To disable the logging of rewriting actions it is not recommended
-to set <em>Filename</em>
-to <code>/dev/null</code>, because although the rewriting engine does
+to set <EM>Filename</EM>
+to <CODE>/dev/null</CODE>, because although the rewriting engine does
 not create output to a logfile it still creates the logfile
-output internally. <b>This will slow down the server with no advantage to the
-administrator!</b>
+output internally. <STRONG>This will slow down the server with no advantage to the
+administrator!</STRONG>
 To disable logging either remove or comment out the
-<tt>RewriteLog</tt> directive or use <tt>RewriteLogLevel 0</tt>!
-</td></tr>
-</table>
+<TT>RewriteLog</TT> directive or use <TT>RewriteLogLevel 0</TT>!
+</TD></TR>
+</TABLE>
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
-SECURITY: See the <a
-href="../misc/security_tips.html">Apache Security
-Tips</a> document for details on why your security could be compromised if the
+<TR><TD>
+SECURITY: See the <A
+HREF="../misc/security_tips.html">Apache Security
+Tips</A> document for details on why your security could be compromised if the
 directory where logfiles are stored is writable by anyone other than the user
 that starts the server.
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
-<p>
-<b>Example:</b>
-<blockquote>
-<pre>
+<P>
+<STRONG>Example:</STRONG>
+<BLOCKQUOTE>
+<PRE>
 RewriteLog "/usr/local/var/apache/logs/rewrite.log"
-</pre>
-</blockquote>
+</PRE>
+</BLOCKQUOTE>
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteLogLevel"><h3>RewriteLogLevel</h3></a>
-<strong>Syntax:</strong> <code>RewriteLogLevel</code> <em>Level</em><br>
-<strong>Default:</strong> <strong><code>RewriteLogLevel 0</code></strong><br>
-<strong>Context:</strong> server config, virtual host<br>
-<p>
+<A name="RewriteLogLevel"><h3>RewriteLogLevel</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteLogLevel</CODE> <EM>Level</EM><BR>
+<STRONG>Default:</STRONG> <STRONG><CODE>RewriteLogLevel 0</CODE></STRONG><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<P>
 
-The <tt>RewriteLogLevel</tt> directive set the verbosity level of the rewriting
+The <TT>RewriteLogLevel</TT> directive set the verbosity level of the rewriting
 logfile.  The default level 0 means no logging, while 9 or more means
 that practically all actions are logged.
 
-<p>
-To disable the logging of rewriting actions simply set <em>Level</em> to 0.
+<P>
+To disable the logging of rewriting actions simply set <EM>Level</EM> to 0.
 This disables all rewrite action logs.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#f0f0f0" cellspacing=0 cellpadding=10>
-<tr><td>
-<b>Notice:</b> Using a high value for <i>Level</i> will slow down your Apache
+<TR><TD>
+<STRONG>Notice:</STRONG> Using a high value for <EM>Level</EM> will slow down your Apache
 server dramatically! Use the rewriting logfile only for debugging or at least
-at <em>Level</em> not greater than 2!
-</td></tr>
-</table>
+at <EM>Level</EM> not greater than 2!
+</TD></TR>
+</TABLE>
 
 
-<p>
-<b>Example:</b>
-<blockquote>
-<pre>
+<P>
+<STRONG>Example:</STRONG>
+<BLOCKQUOTE>
+<PRE>
 RewriteLogLevel 3
-</pre>
-</blockquote>
+</PRE>
+</BLOCKQUOTE>
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteMap"><h3>RewriteMap</h3></a>
-<strong>Syntax:</strong> <code>RewriteMap</code> <em>Mapname</em> <code>{txt,dbm,prg}:</code><em>Filename</em><br>
-<strong>Default:</strong> not used per default<br>
-<strong>Context:</strong> server config, virtual host<br>
-<p>
+<A name="RewriteMap"><h3>RewriteMap</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteMap</CODE> <EM>Mapname</EM> <CODE>{txt,dbm,prg}:</CODE><EM>Filename</EM><BR>
+<STRONG>Default:</STRONG> not used per default<BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<P>
 
-The <tt>RewriteMap</tt> directive defines an external <em>Rewriting Map</em>
+The <TT>RewriteMap</TT> directive defines an external <EM>Rewriting Map</EM>
 which can be used inside rule substitution strings by the mapping-functions
 to insert/substitute fields through a key lookup.
-<p>
+<P>
 
-The <a name="mapfunc"><em>Mapname</em></a> is the name of the map and will
+The <A name="mapfunc"><EM>Mapname</EM></A> is the name of the map and will
 be used to specify a mapping-function for the substitution strings of a
 rewriting rule via
 
-<blockquote><strong>
-<code>${</code> <em>Mapname</em> <code>:</code> <em>LookupKey</em>
-<code>|</code> <em>DefaultValue</em> <code>}</code>
-</strong></blockquote>
+<BLOCKQUOTE><STRONG>
+<CODE>${</CODE> <EM>Mapname</EM> <CODE>:</CODE> <EM>LookupKey</EM>
+<CODE>|</CODE> <EM>DefaultValue</EM> <CODE>}</CODE>
+</STRONG></BLOCKQUOTE>
 
-When such a directive occurs the map <em>Mapname</em>
-is consulted and the key <em>LookupKey</em> is looked-up. If the key is
-found, the map-function directive is substituted by <em>SubstValue</em>. If
-the key is not found then it is substituted by <em>DefaultValue</em>.
+When such a directive occurs the map <EM>Mapname</EM>
+is consulted and the key <EM>LookupKey</EM> is looked-up. If the key is
+found, the map-function directive is substituted by <EM>SubstValue</EM>. If
+the key is not found then it is substituted by <EM>DefaultValue</EM>.
 
-<p>
-The <em>Filename</em> must be a valid Unix filepath, containing one
+<P>
+The <EM>Filename</EM> must be a valid Unix filepath, containing one
 of the following formats:
 
-<ol>
-<li><b>Plain Text Format</b>
-    <p>
+<OL>
+<LI><STRONG>Plain Text Format</STRONG>
+    <P>
     This is a ASCII file which contains either blank lines, comment lines
     (starting with a '#' character) or
 
-    <blockquote><strong>
-    <em>MatchingKey</em>  <em>SubstValue</em>
-    </strong></blockquote>
+    <BLOCKQUOTE><STRONG>
+    <EM>MatchingKey</EM>  <EM>SubstValue</EM>
+    </STRONG></BLOCKQUOTE>
 
     pairs - one per line. You can create such files either manually,
     using your favorite editor, or by using the programs
-    <tt>mapcollect</tt> and <tt>mapmerge</tt> from the <tt>support</tt>
-    directory of the <b>mod_rewrite</b> distribution.
-    <p>
-    To declare such a map prefix, <em>Filename</em> with a <code>txt:</code>
+    <TT>mapcollect</TT> and <TT>mapmerge</TT> from the <TT>support</TT>
+    directory of the <STRONG>mod_rewrite</STRONG> distribution.
+    <P>
+    To declare such a map prefix, <EM>Filename</EM> with a <CODE>txt:</CODE>
     string as in the following example:
 
-<p>
+<P>
 <table border=0 cellspacing=1 cellpadding=5 bgcolor="#f0f0f0">
-<tr><td><pre>
+<TR><TD><PRE>
 #
 #   map.real-to-user -- maps realnames to usernames
 #
 
 Ralf.S.Engelschall    rse   # Bastard Operator From Hell
 Dr.Fred.Klabuster     fred  # Mr. DAU
-</pre></td></tr>
-</table>
+</PRE></TD></TR>
+</TABLE>
 
-<p>
+<P>
 <table border=0 cellspacing=1 cellpadding=5 bgcolor="#f0f0f0">
-<tr><td><pre>
+<TR><TD><PRE>
 RewriteMap real-to-host txt:/path/to/file/map.real-to-user
-</pre></td></tr>
-</table>
+</PRE></TD></TR>
+</TABLE>
 
-<p>
-<li><b>DBM Hashfile Format</b>
-    <p>
+<P>
+<LI><STRONG>DBM Hashfile Format</STRONG>
+    <P>
     This is a binary NDBM format file containing the
-    same contents as the <em>Plain Text Format</em> files. You can create
-    such a file with any NDBM tool or with the <tt>dbmmanage</tt> program
-    from the <tt>support</tt> directory of the Apache distribution.
-    <p>
-    To declare such a map prefix <em>Filename</em> with a <code>dbm:</code>
+    same contents as the <EM>Plain Text Format</EM> files. You can create
+    such a file with any NDBM tool or with the <TT>dbmmanage</TT> program
+    from the <TT>support</TT> directory of the Apache distribution.
+    <P>
+    To declare such a map prefix <EM>Filename</EM> with a <CODE>dbm:</CODE>
     string.
-<p>
-<li><b>Program Format</b>
-    <p>
+<P>
+<LI><STRONG>Program Format</STRONG>
+    <P>
     This is a Unix executable, not a lookup file.  To create it you can use
     the language of your choice, but the result has to be a run-able Unix
     binary (i.e. either object-code or a script with the
-    magic cookie trick '<tt>#!/path/to/interpreter</tt>' as the first line).
-    <p>
+    magic cookie trick '<TT>#!/path/to/interpreter</TT>' as the first line).
+    <P>
     This program gets started once at startup of the Apache servers and then
-    communicates with the rewriting engine over its <tt>stdin</tt> and
-    <tt>stdout</tt> file-handles.  For each map-function lookup it will
+    communicates with the rewriting engine over its <TT>stdin</TT> and
+    <TT>stdout</TT> file-handles.  For each map-function lookup it will
     receive the key to lookup as a newline-terminated string on
-    <tt>stdin</tt>. It then has to give back the looked-up value as a
-    newline-terminated string on <tt>stdout</tt> or the four-character string
-    ``<tt>NULL</tt>'' if it fails (i.e. there is no corresponding value
+    <TT>stdin</TT>. It then has to give back the looked-up value as a
+    newline-terminated string on <TT>stdout</TT> or the four-character string
+    ``<TT>NULL</TT>'' if it fails (i.e. there is no corresponding value
     for the given key). A trivial program which will implement a 1:1 map
     (i.e. key == value) could be:
-    <p>
+    <P>
 <table border=0 cellspacing=1 cellpadding=5 bgcolor="#f0f0f0">
-<tr><td><pre>
+<TR><TD><PRE>
 #!/usr/bin/perl
 $| = 1;
 while (&lt;STDIN&gt;) {
@@ -321,86 +321,86 @@ while (&lt;STDIN&gt;) {
     # or lookups should occur...
     print $_;
 }
-</pre></td></tr>
-</table>
-    <p>
-    <b>But be very careful:</b><br>
-    <ol>
-    <li>``<i>Keep the program simple, stupid</i>'' (KISS), because
+</PRE></TD></TR>
+</TABLE>
+    <P>
+    <STRONG>But be very careful:</STRONG><BR>
+    <OL>
+    <LI>``<EM>Keep the program simple, stupid</EM>'' (KISS), because
         if this program hangs it will lead to a hang of the Apache server
         when the rule occurs.
-    <li>Avoid one common mistake: never do buffered I/O on <tt>stdout</tt>!
-    This will cause a deadloop! Hence the ``<tt>$|=1</tt>'' in the above
+    <LI>Avoid one common mistake: never do buffered I/O on <TT>stdout</TT>!
+    This will cause a deadloop! Hence the ``<TT>$|=1</TT>'' in the above
     example...
-    </ol>
-    <p>
-    To declare such a map prefix <em>Filename</em> with a <code>prg:</code>
+    </OL>
+    <P>
+    To declare such a map prefix <EM>Filename</EM> with a <CODE>prg:</CODE>
     string.
-</ol>
+</OL>
 
-The <tt>RewriteMap</tt> directive can occur more than once. For each
-mapping-function use one <tt>RewriteMap</tt> directive to declare its
-rewriting mapfile. While you cannot <b>declare</b> a map in per-directory
-context it is of course possible to <b>use</b> this map in per-directory
+The <TT>RewriteMap</TT> directive can occur more than once. For each
+mapping-function use one <TT>RewriteMap</TT> directive to declare its
+rewriting mapfile. While you cannot <STRONG>declare</STRONG> a map in per-directory
+context it is of course possible to <STRONG>use</STRONG> this map in per-directory
 context.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#f0f0f0" cellspacing=0 cellpadding=10>
-<tr><td>
+<TR><TD>
 For plain text and DBM format files the looked-up keys are cached in-core
-until the <tt>mtime</tt> of the mapfile changes or the server does a
+until the <TT>mtime</TT> of the mapfile changes or the server does a
 restart. This way you can have map-functions in rules which are used
-for <b>every</b> request. This is no problem, because the external lookup
+for <STRONG>every</STRONG> request. This is no problem, because the external lookup
 only happens once!
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteBase"><h3>RewriteBase</h3></a>
-<strong>Syntax:</strong> <code>RewriteBase</code> <em>BaseURL</em><br>
-<strong>Default:</strong> <em>default is the physical directory path</em><br>
-<strong>Context:</strong> per-directory config<br>
-<p>
+<A name="RewriteBase"><h3>RewriteBase</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteBase</CODE> <EM>BaseURL</EM><BR>
+<STRONG>Default:</STRONG> <EM>default is the physical directory path</EM><BR>
+<STRONG>Context:</STRONG> per-directory config<BR>
+<P>
 
-The <tt>RewriteBase</tt> directive explicitly sets the base URL for
-per-directory rewrites. As you will see below, <tt>RewriteRule</tt> can be
-used in per-directory config files (<tt>.htaccess</tt>). There it will act
+The <TT>RewriteBase</TT> directive explicitly sets the base URL for
+per-directory rewrites. As you will see below, <TT>RewriteRule</TT> can be
+used in per-directory config files (<TT>.htaccess</TT>). There it will act
 locally, i.e. the local directory prefix is stripped at this stage of
 processing and your rewriting rules act only on the remainder. At the end
 it is automatically added.
 
-<p>
+<P>
 When a substitution occurs for a new URL, this module has to
 re-inject the URL into the server processing. To be able to do this it needs
 to know what the corresponding URL-prefix or URL-base is. By default this
-prefix is the corresponding filepath itself. <b>But at most websites URLs are
-<b>NOT</b> directly related to physical filename paths, so this assumption
-will be usually be wrong!</b> There you have to use the <tt>RewriteBase</tt>
+prefix is the corresponding filepath itself. <STRONG>But at most websites URLs are
+<STRONG>NOT</STRONG> directly related to physical filename paths, so this assumption
+will be usually be wrong!</STRONG> There you have to use the <TT>RewriteBase</TT>
 directive to specify the correct URL-prefix.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
-So, if your webserver's URLs are <b>not</b> directly
-related to physical file paths, you have to use <tt>RewriteBase</tt> in every
-<tt>.htaccess</tt> files where you want to use <tt>RewriteRule</tt>
+<TR><TD>
+So, if your webserver's URLs are <STRONG>not</STRONG> directly
+related to physical file paths, you have to use <TT>RewriteBase</TT> in every
+<TT>.htaccess</TT> files where you want to use <TT>RewriteRule</TT>
 directives.
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
-<p>
-<b>Example:</b>
+<P>
+<STRONG>Example:</STRONG>
 
-<blockquote>
+<BLOCKQUOTE>
    Assume the following per-directory config file:
 
-<p>
+<P>
 <table border=0 cellspacing=1 cellpadding=5 bgcolor="#f0f0f0">
-<tr><td><pre>
+<TR><TD><PRE>
 #
 #  /abc/def/.htaccess -- per-dir config file for directory /abc/def
 #  Remember: /abc/def is the physical path of /xyz, i.e. the server
@@ -415,23 +415,23 @@ RewriteBase   /xyz
 
 #  now the rewriting rules
 RewriteRule   ^oldstuff\.html$  newstuff.html
-</pre></td></tr>
-</table>
+</PRE></TD></TR>
+</TABLE>
 
-<p>
-In the above example, a request to <tt>/xyz/oldstuff.html</tt> gets correctly
-rewritten to the physical file <tt>/abc/def/newstuff.html</tt>.
+<P>
+In the above example, a request to <TT>/xyz/oldstuff.html</TT> gets correctly
+rewritten to the physical file <TT>/abc/def/newstuff.html</TT>.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
+<TR><TD>
 <font size=-1>
-<b>For the Apache hackers:</b><br>
+<STRONG>For the Apache hackers:</STRONG><BR>
 The following list gives detailed information about the internal
 processing steps:
 
-<p>
-<pre>
+<P>
+<PRE>
 Request:
   /xyz/oldstuff.html
 
@@ -443,7 +443,7 @@ Internal Processing:
 
 Result:
   /abc/def/newstuff.html
-</pre>
+</PRE>
 
 This seems very complicated but is the correct Apache internal processing,
 because the per-directory rewriting comes too late in the process.  So,
@@ -452,293 +452,293 @@ kernel! BUT: While this seems like a serious overhead, it really isn't, because
 this re-injection happens fully internal to the Apache server and the same
 procedure is used by many other operations inside Apache. So, you can be
 sure the design and implementation is correct.
-</font>
-</td></tr>
-</table>
+</FONT>
+</TD></TR>
+</TABLE>
 
-</blockquote>
+</BLOCKQUOTE>
 
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteCond"><h3>RewriteCond</h3></a>
-<strong>Syntax:</strong> <code>RewriteCond</code> <em>TestString</em> <em>CondPattern</em><br>
-<strong>Default:</strong> -<em>None</em>-<br>
-<strong>Context:</strong> server config, virtual host, per-directory config<br>
-<p>
+<A name="RewriteCond"><h3>RewriteCond</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteCond</CODE> <EM>TestString</EM> <EM>CondPattern</EM><BR>
+<STRONG>Default:</STRONG> -<EM>None</EM>-<BR>
+<STRONG>Context:</STRONG> server config, virtual host, per-directory config<BR>
+<P>
 
-The <tt>RewriteCond</tt> directive defines a rule condition. Precede a
-<tt>RewriteRule</tt> directive with one or more <tt>RewriteCond</tt>
+The <TT>RewriteCond</TT> directive defines a rule condition. Precede a
+<TT>RewriteRule</TT> directive with one or more <TT>RewriteCond</TT>
 directives.
 
 The following rewriting rule is only used if its pattern matches the current
-state of the URI <b>AND</b> if these additional conditions apply, too.
+state of the URI <STRONG>AND</STRONG> if these additional conditions apply, too.
 
-<p>
-<em>TestString</em> is a string which can contains the following
+<P>
+<EM>TestString</EM> is a string which can contains the following
 expanded constructs in addition to plain text:
 
-<ul>
-<li><b>RewriteRule backreferences</b>: These are backreferences of the form
+<UL>
+<LI><STRONG>RewriteRule backreferences</STRONG>: These are backreferences of the form
 
-<blockquote><strong>
-<tt>$N</tt>
-</strong></blockquote>
+<BLOCKQUOTE><STRONG>
+<TT>$N</TT>
+</STRONG></BLOCKQUOTE>
 
 (1 <= N <= 9) which provide access to the grouped parts (parenthesis!) of the
-pattern from the corresponding <tt>RewriteRule</tt> directive (the one
-following the current bunch of <tt>RewriteCond</tt> directives).
+pattern from the corresponding <TT>RewriteRule</TT> directive (the one
+following the current bunch of <TT>RewriteCond</TT> directives).
 
-<p>
-<li><b>RewriteCond backreferences</b>: These are backreferences of the form
+<P>
+<LI><STRONG>RewriteCond backreferences</STRONG>: These are backreferences of the form
 
-<blockquote><strong>
-<tt>%N</tt>
-</strong></blockquote>
+<BLOCKQUOTE><STRONG>
+<TT>%N</TT>
+</STRONG></BLOCKQUOTE>
 
 (1 <= N <= 9) which provide access to the grouped parts (parenthesis!) of the
-pattern from the last matched <tt>RewriteCond</tt> directive in the current
+pattern from the last matched <TT>RewriteCond</TT> directive in the current
 bunch of conditions.
 
-<p>
-<li><b>Server-Variables</b>: These are variables
+<P>
+<LI><STRONG>Server-Variables</STRONG>: These are variables
     of the form
 
-<blockquote><strong>
-<tt>%{</tt> <em>NAME_OF_VARIABLE</em> <tt>}</tt>
-</strong></blockquote>
+<BLOCKQUOTE><STRONG>
+<TT>%{</TT> <EM>NAME_OF_VARIABLE</EM> <TT>}</TT>
+</STRONG></BLOCKQUOTE>
 
-where <em>NAME_OF_VARIABLE</em> can be a string
+where <EM>NAME_OF_VARIABLE</EM> can be a string
 of the following list:
 
-<p>
+<P>
 <table bgcolor="#f0f0f0" cellspacing=0 cellpadding=5>
-<tr>
+<TR>
 <td valign=top>
-<b>HTTP headers:</b><p>
+<STRONG>HTTP headers:</STRONG><P>
 <font size=-1>
-HTTP_USER_AGENT<br>
-HTTP_REFERER<br>
-HTTP_COOKIE<br>
-HTTP_FORWARDED<br>
-HTTP_HOST<br>
-HTTP_PROXY_CONNECTION<br>
-HTTP_ACCEPT<br>
-</font>
-</td>
+HTTP_USER_AGENT<BR>
+HTTP_REFERER<BR>
+HTTP_COOKIE<BR>
+HTTP_FORWARDED<BR>
+HTTP_HOST<BR>
+HTTP_PROXY_CONNECTION<BR>
+HTTP_ACCEPT<BR>
+</FONT>
+</TD>
 
 <td valign=top>
-<b>connection &amp; request:</b><p>
+<STRONG>connection &amp; request:</STRONG><P>
 <font size=-1>
-REMOTE_ADDR<br>
-REMOTE_HOST<br>
-REMOTE_USER<br>
-REMOTE_IDENT<br>
-REQUEST_METHOD<br>
-SCRIPT_FILENAME<br>
-PATH_INFO<br>
-QUERY_STRING<br>
-AUTH_TYPE<br>
-</font>
-</td>
-
-</tr>
-<tr>
+REMOTE_ADDR<BR>
+REMOTE_HOST<BR>
+REMOTE_USER<BR>
+REMOTE_IDENT<BR>
+REQUEST_METHOD<BR>
+SCRIPT_FILENAME<BR>
+PATH_INFO<BR>
+QUERY_STRING<BR>
+AUTH_TYPE<BR>
+</FONT>
+</TD>
+
+</TR>
+<TR>
 
 <td valign=top>
-<b>server internals:</b><p>
+<STRONG>server internals:</STRONG><P>
 <font size=-1>
-DOCUMENT_ROOT<br>
-SERVER_ADMIN<br>
-SERVER_NAME<br>
-SERVER_PORT<br>
-SERVER_PROTOCOL<br>
-SERVER_SOFTWARE<br>
-SERVER_VERSION<br>
-</font>
-</td>
+DOCUMENT_ROOT<BR>
+SERVER_ADMIN<BR>
+SERVER_NAME<BR>
+SERVER_PORT<BR>
+SERVER_PROTOCOL<BR>
+SERVER_SOFTWARE<BR>
+SERVER_VERSION<BR>
+</FONT>
+</TD>
 
 <td valign=top>
-<b>system stuff:</b><p>
+<STRONG>system stuff:</STRONG><P>
 <font size=-1>
-TIME_YEAR<br>
-TIME_MON<br>
-TIME_DAY<br>
-TIME_HOUR<br>
-TIME_MIN<br>
-TIME_SEC<br>
-TIME_WDAY<br>
-TIME<br>
-</font>
-</td>
+TIME_YEAR<BR>
+TIME_MON<BR>
+TIME_DAY<BR>
+TIME_HOUR<BR>
+TIME_MIN<BR>
+TIME_SEC<BR>
+TIME_WDAY<BR>
+TIME<BR>
+</FONT>
+</TD>
 
 <td valign=top>
-<b>specials:</b><p>
+<STRONG>specials:</STRONG><P>
 <font size=-1>
-API_VERSION<br>
-THE_REQUEST<br>
-REQUEST_URI<br>
-REQUEST_FILENAME<br>
-IS_SUBREQ<br>
-</font>
-</td>
-</tr>
-</table>
-
-<p>
+API_VERSION<BR>
+THE_REQUEST<BR>
+REQUEST_URI<BR>
+REQUEST_FILENAME<BR>
+IS_SUBREQ<BR>
+</FONT>
+</TD>
+</TR>
+</TABLE>
+
+<P>
 <table width="70%" border=0 bgcolor="#f0f0f0" cellspacing=0 cellpadding=10>
-<tr><td>
+<TR><TD>
 These variables all correspond to the similar named HTTP MIME-headers, C
-variables of the Apache server or <tt>struct tm</tt> fields of the Unix
+variables of the Apache server or <TT>struct tm</TT> fields of the Unix
 system.
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
-</ul>
+</UL>
 
-<p>
+<P>
 Special Notes:
-<ol>
-<li>The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same
-value, i.e. the value of the <tt>filename</tt> field of the internal
-<tt>request_rec</tt> structure of the Apache server. The first name is just the
+<OL>
+<LI>The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same
+value, i.e. the value of the <TT>filename</TT> field of the internal
+<TT>request_rec</TT> structure of the Apache server. The first name is just the
 commonly known CGI variable name while the second is the consistent
-counterpart to REQUEST_URI (which contains the value of the <tt>uri</tt>
-field of <tt>request_rec</tt>).
+counterpart to REQUEST_URI (which contains the value of the <TT>uri</TT>
+field of <TT>request_rec</TT>).
 
-<p>
-<li>There is the special format: <tt>%{ENV:variable}</tt> where
-<i>variable</i> can be any environment variable. This is looked-up via
-internal Apache structures and (if not found there) via <tt>getenv()</tt> from
+<P>
+<LI>There is the special format: <TT>%{ENV:variable}</TT> where
+<EM>variable</EM> can be any environment variable. This is looked-up via
+internal Apache structures and (if not found there) via <TT>getenv()</TT> from
 the Apache server process.
 
-<p>
-<li>There is the special format: <tt>%{HTTP:header}</tt> where
-<i>header</i> can be any HTTP MIME-header name. This is looked-up
-from the HTTP request. Example: <tt>%{HTTP:Proxy-Connection}</tt>
-is the value of the HTTP header ``<tt>Proxy-Connection:</tt>''.
-
-<p>
-<li>There is the special format: <tt>%{LA-U:url}</tt>
-for look-aheads like <tt>-U</tt>. This performs a internal sub-request to
-look-ahead for the final value of <i>url</i>.
-
-<p>
-<li>There is the special format: <tt>%{LA-F:file}</tt>
-for look-aheads like <tt>-F</tt>. This performs a internal sub-request to
-look-ahead for the final value of <i>file</i>.
-</ol>
-
-<p>
-<em>CondPattern</em> is the condition pattern, i.e. a regular expression
-which gets applied to the current instance of the <em>TestString</em>, i.e.
-<em>TestString</em> gets evaluated and then matched against
-<em>CondPattern</em>.
-
-<p>
-<b>Remember:</b> <em>CondPattern</em> is a standard
-<em>Extended Regular Expression</em> with some additions:
-
-<ol>
-<li>You can precede the pattern string with a '<tt>!</tt>' character
-(exclamation mark) to specify a <b>non</b>-matching pattern.
-
-<p>
-<li>
-There are some special variants of <em>CondPatterns</em>. Instead of real
+<P>
+<LI>There is the special format: <TT>%{HTTP:header}</TT> where
+<EM>header</EM> can be any HTTP MIME-header name. This is looked-up
+from the HTTP request. Example: <TT>%{HTTP:Proxy-Connection}</TT>
+is the value of the HTTP header ``<TT>Proxy-Connection:</TT>''.
+
+<P>
+<LI>There is the special format: <TT>%{LA-U:url}</TT>
+for look-aheads like <TT>-U</TT>. This performs a internal sub-request to
+look-ahead for the final value of <EM>url</EM>.
+
+<P>
+<LI>There is the special format: <TT>%{LA-F:file}</TT>
+for look-aheads like <TT>-F</TT>. This performs a internal sub-request to
+look-ahead for the final value of <EM>file</EM>.
+</OL>
+
+<P>
+<EM>CondPattern</EM> is the condition pattern, i.e. a regular expression
+which gets applied to the current instance of the <EM>TestString</EM>, i.e.
+<EM>TestString</EM> gets evaluated and then matched against
+<EM>CondPattern</EM>.
+
+<P>
+<STRONG>Remember:</STRONG> <EM>CondPattern</EM> is a standard
+<EM>Extended Regular Expression</EM> with some additions:
+
+<OL>
+<LI>You can precede the pattern string with a '<TT>!</TT>' character
+(exclamation mark) to specify a <STRONG>non</STRONG>-matching pattern.
+
+<P>
+<LI>
+There are some special variants of <EM>CondPatterns</EM>. Instead of real
 regular expression strings you can also use one of the following:
-<p>
-<ul>
-<li>'<b>&lt;CondPattern</b>' (is lexicographically lower)<br>
-Treats the <i>CondPattern</i> as a plain string and compares it
-lexicographically to <i>TestString</i> and results in a true expression if
-<i>TestString</i> is lexicographically lower then <i>CondPattern</i>.
-<p>
-<li>'<b>&gt;CondPattern</b>' (is lexicographically greater)<br>
-Treats the <i>CondPattern</i> as a plain string and compares it
-lexicographically to <i>TestString</i> and results in a true expression if
-<i>TestString</i> is lexicographically greater then <i>CondPattern</i>.
-<p>
-<li>'<b>=CondPattern</b>' (is lexicographically equal)<br>
-Treats the <i>CondPattern</i> as a plain string and compares it
-lexicographically to <i>TestString</i> and results in a true expression if
-<i>TestString</i> is lexicographically equal to <i>CondPattern</i>, i.e the
+<P>
+<UL>
+<LI>'<STRONG>&lt;CondPattern</STRONG>' (is lexicographically lower)<BR>
+Treats the <EM>CondPattern</EM> as a plain string and compares it
+lexicographically to <EM>TestString</EM> and results in a true expression if
+<EM>TestString</EM> is lexicographically lower then <EM>CondPattern</EM>.
+<P>
+<LI>'<STRONG>&gt;CondPattern</STRONG>' (is lexicographically greater)<BR>
+Treats the <EM>CondPattern</EM> as a plain string and compares it
+lexicographically to <EM>TestString</EM> and results in a true expression if
+<EM>TestString</EM> is lexicographically greater then <EM>CondPattern</EM>.
+<P>
+<LI>'<STRONG>=CondPattern</STRONG>' (is lexicographically equal)<BR>
+Treats the <EM>CondPattern</EM> as a plain string and compares it
+lexicographically to <EM>TestString</EM> and results in a true expression if
+<EM>TestString</EM> is lexicographically equal to <EM>CondPattern</EM>, i.e the
 two strings are exactly equal (character by character).
-If <i>CondPattern</i> is just <samp>""</samp> (two quotation marks) this
-compares <i>TestString</i> against the empty string.
-<p>
-<li>'<b>-d</b>' (is <b>d</b>irectory)<br>
-Treats the <i>TestString</i> as a pathname and
+If <EM>CondPattern</EM> is just <SAMP>""</SAMP> (two quotation marks) this
+compares <EM>TestString</EM> against the empty string.
+<P>
+<LI>'<STRONG>-d</STRONG>' (is <STRONG>d</STRONG>irectory)<BR>
+Treats the <EM>TestString</EM> as a pathname and
 tests if it exists and is a directory.
-<p>
-<li>'<b>-f</b>' (is regular <b>f</b>ile)<br>
-Treats the <i>TestString</i> as a pathname and
+<P>
+<LI>'<STRONG>-f</STRONG>' (is regular <STRONG>f</STRONG>ile)<BR>
+Treats the <EM>TestString</EM> as a pathname and
 tests if it exists and is a regular file.
-<p>
-<li>'<b>-s</b>' (is regular file with <b>s</b>ize)<br>
-Treats the <i>TestString</i> as a pathname and
+<P>
+<LI>'<STRONG>-s</STRONG>' (is regular file with <STRONG>s</STRONG>ize)<BR>
+Treats the <EM>TestString</EM> as a pathname and
 tests if it exists and is a regular file with size greater then zero.
-<p>
-<li>'<b>-l</b>' (is symbolic <b>l</b>ink)<br>
-Treats the <i>TestString</i> as a pathname and
+<P>
+<LI>'<STRONG>-l</STRONG>' (is symbolic <STRONG>l</STRONG>ink)<BR>
+Treats the <EM>TestString</EM> as a pathname and
 tests if it exists and is a symbolic link.
-<p>
-<li>'<b>-F</b>' (is existing file via subrequest)<br>
-Checks if <i>TestString</i> is a valid file and accessible via all the
+<P>
+<LI>'<STRONG>-F</STRONG>' (is existing file via subrequest)<BR>
+Checks if <EM>TestString</EM> is a valid file and accessible via all the
 server's currently-configured access controls for that path.  This uses an
 internal subrequest to determine the check, so use it with care because it
 decreases your servers performance!
-<p>
-<li>'<b>-U</b>' (is existing URL via subrequest)<br>
-Checks if <i>TestString</i> is a valid URL and accessible via all the server's
+<P>
+<LI>'<STRONG>-U</STRONG>' (is existing URL via subrequest)<BR>
+Checks if <EM>TestString</EM> is a valid URL and accessible via all the server's
 currently-configured access controls for that path.  This uses an internal
 subrequest to determine the check, so use it with care because it decreases
 your servers performance!
-</ul>
-<p>
+</UL>
+<P>
 Notice: All of these tests can also be prefixed by a not ('!') character
 to negate their meaning.
-</ol>
+</OL>
 
-<p>
-Additionally you can set special flags for <em>CondPattern</em> by appending
+<P>
+Additionally you can set special flags for <EM>CondPattern</EM> by appending
 
-<blockquote><strong>
-<code>[</code><em>flags</em><code>]</code>
-</strong></blockquote>
+<BLOCKQUOTE><STRONG>
+<CODE>[</CODE><EM>flags</EM><CODE>]</CODE>
+</STRONG></BLOCKQUOTE>
 
-as the third argument to the <tt>RewriteCond</tt> directive. <em>Flags</em>
+as the third argument to the <TT>RewriteCond</TT> directive. <EM>Flags</EM>
 is a comma-separated list of the following flags:
 
-<ul>
-<li>'<strong><code>nocase|NC</code></strong>' (<b>n</b>o <b>c</b>ase)<br>
+<UL>
+<LI>'<STRONG><CODE>nocase|NC</CODE></STRONG>' (<STRONG>n</STRONG>o <STRONG>c</STRONG>ase)<BR>
     This makes the condition test case-insensitive, i.e. there is
     no difference between 'A-Z' and 'a-z' both in the expanded
-    <em>TestString</em> and the <em>CondPattern</em>.
-<p>
-<li>'<strong><code>ornext|OR</code></strong>' (<b>or</b> next condition)<br>
+    <EM>TestString</EM> and the <EM>CondPattern</EM>.
+<P>
+<LI>'<STRONG><CODE>ornext|OR</CODE></STRONG>' (<STRONG>or</STRONG> next condition)<BR>
     Use this to combine rule conditions with a local OR instead of the
     implicit AND. Typical example:
-    <p>
-<blockquote><pre>
+    <P>
+<BLOCKQUOTE><PRE>
 RewriteCond %{REMOTE_HOST}  ^host1.*  [OR]
 RewriteCond %{REMOTE_HOST}  ^host2.*  [OR]
 RewriteCond %{REMOTE_HOST}  ^host3.*
 RewriteRule ...some special stuff for any of these hosts...
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
     Without this flag you had to write down the cond/rule three times.
-</ul>
+</UL>
 
-<p>
-<b>Example:</b>
-<blockquote>
+<P>
+<STRONG>Example:</STRONG>
+<BLOCKQUOTE>
 
-To rewrite the Homepage of a site according to the ``<tt>User-Agent:</tt>''
+To rewrite the Homepage of a site according to the ``<TT>User-Agent:</TT>''
 header of the request, you can use the following:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
 RewriteCond  %{HTTP_USER_AGENT}  ^Mozilla.*
 RewriteRule  ^/$                 /homepage.max.html  [L]
 
@@ -746,355 +746,355 @@ RewriteCond  %{HTTP_USER_AGENT}  ^Lynx.*
 RewriteRule  ^/$                 /homepage.min.html  [L]
 
 RewriteRule  ^/$                 /homepage.std.html  [L]
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 Interpretation: If you use Netscape Navigator as your browser (which identifies
 itself as 'Mozilla'), then you get the max homepage, which includes
 Frames, etc. If you use the Lynx browser (which is Terminal-based), then you
 get the min homepage, which contains no images, no tables, etc.  If you
 use any other browser you get the standard homepage.
-</blockquote>
+</BLOCKQUOTE>
 
-<p>
+<P>
 <hr noshade size=1>
-<p>
+<P>
 
-<a name="RewriteRule"><h3>RewriteRule</h3></a>
-<strong>Syntax:</strong> <code>RewriteRule</code> <em>Pattern</em> <em>Substitution</em><br>
-<strong>Default:</strong> -<em>None</em>-<br>
-<strong>Context:</strong> server config, virtual host, per-directory config<br>
+<A name="RewriteRule"><h3>RewriteRule</h3></A>
+<STRONG>Syntax:</STRONG> <CODE>RewriteRule</CODE> <EM>Pattern</EM> <EM>Substitution</EM><BR>
+<STRONG>Default:</STRONG> -<EM>None</EM>-<BR>
+<STRONG>Context:</STRONG> server config, virtual host, per-directory config<BR>
 
-<p>
-The <tt>RewriteRule</tt> directive is the real rewriting workhorse.  The
+<P>
+The <TT>RewriteRule</TT> directive is the real rewriting workhorse.  The
 directive can occur more than once. Each directive then defines one single
-rewriting rule.  The <b>definition order</b> of these rules is
-<b>important</b>, because this order is used when applying the rules at
+rewriting rule.  The <STRONG>definition order</STRONG> of these rules is
+<STRONG>important</STRONG>, because this order is used when applying the rules at
 run-time.
 
-<p>
-<a name="patterns"><em>Pattern</em></a> can be (for Apache 1.1.x a System
-V8 and for Apache 1.2.x a POSIX) <a name="regexp">regular expression</a>
+<P>
+<A name="patterns"><EM>Pattern</EM></A> can be (for Apache 1.1.x a System
+V8 and for Apache 1.2.x a POSIX) <A name="regexp">regular expression</A>
 which gets applied to the current URL. Here ``current'' means the value of the
 URL when this rule gets applied. This may not be the original requested
 URL, because there could be any number of rules before which already matched
 and made alterations to it.
 
-<p>
+<P>
 Some hints about the syntax of regular expressions:
 
-<p>
+<P>
 <table bgcolor="#f0f0f0" cellspacing=0 cellpadding=5>
-<tr>
+<TR>
 <td valign=top>
-<pre>
-<strong><code>^</code></strong>           Start of line
-<strong><code>$</code></strong>           End of line
-<strong><code>.</code></strong>           Any single character
-<strong><code>[</code></strong>chars<strong><code>]</code></strong>     One of chars
-<strong><code>[^</code></strong>chars<strong><code>]</code></strong>    None of chars
-
-<strong><code>?</code></strong>           0 or 1 of the preceding char
-<strong><code>*</code></strong>           0 or N of the preceding char
-<strong><code>+</code></strong>           1 or N of the preceding char
-
-<strong><code>\</code></strong>char       escape that specific char
-            (e.g. for specifying the chars "<code>.[]()</code>" etc.)
-
-<strong><code>(</code></strong>string<strong><code>)</code></strong>    Grouping of chars (the <b>N</b>th group can be used on the RHS with <code>$</code><b>N</b>)
-</pre>
-</td>
-</tr>
-</table>
-
-<p>
-Additionally the NOT character ('<tt>!</tt>') is a possible pattern
-prefix. This gives you the ability to negate a pattern; to say, for instance: ``<i>if
-the current URL does <b>NOT</b> match to this pattern</i>''. This can be used
+<PRE>
+<STRONG><CODE>^</CODE></STRONG>           Start of line
+<STRONG><CODE>$</CODE></STRONG>           End of line
+<STRONG><CODE>.</CODE></STRONG>           Any single character
+<STRONG><CODE>[</CODE></STRONG>chars<STRONG><CODE>]</CODE></STRONG>     One of chars
+<STRONG><CODE>[^</CODE></STRONG>chars<STRONG><CODE>]</CODE></STRONG>    None of chars
+
+<STRONG><CODE>?</CODE></STRONG>           0 or 1 of the preceding char
+<STRONG><CODE>*</CODE></STRONG>           0 or N of the preceding char
+<STRONG><CODE>+</CODE></STRONG>           1 or N of the preceding char
+
+<STRONG><CODE>\</CODE></STRONG>char       escape that specific char
+            (e.g. for specifying the chars "<CODE>.[]()</CODE>" etc.)
+
+<STRONG><CODE>(</CODE></STRONG>string<STRONG><CODE>)</CODE></STRONG>    Grouping of chars (the <STRONG>N</STRONG>th group can be used on the RHS with <CODE>$</CODE><STRONG>N</STRONG>)
+</PRE>
+</TD>
+</TR>
+</TABLE>
+
+<P>
+Additionally the NOT character ('<TT>!</TT>') is a possible pattern
+prefix. This gives you the ability to negate a pattern; to say, for instance: ``<EM>if
+the current URL does <STRONG>NOT</STRONG> match to this pattern</EM>''. This can be used
 for special cases where it is better to match the negative pattern or as a
 last default rule.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
-<b>Notice!</b> When using the NOT character to negate a pattern you cannot
+<TR><TD>
+<STRONG>Notice!</STRONG> When using the NOT character to negate a pattern you cannot
 have grouped wildcard parts in the pattern. This is impossible because when
 the pattern does NOT match, there are no contents for the groups. In
-consequence, if negated patterns are used, you cannot use <tt>$N</tt> in the
+consequence, if negated patterns are used, you cannot use <TT>$N</TT> in the
 substitution string!
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
-<p>
-<a name="rhs"><em>Substitution</em></a> of a rewriting rule is the string
+<P>
+<A name="rhs"><EM>Substitution</EM></A> of a rewriting rule is the string
 which is substituted for (or replaces) the original URL for which
-<em>Pattern</em> matched.  Beside plain text you can use
-
-<ol>
-<li>back-references <code>$N</code> to the RewriteRule pattern
-<li>back-references <code>%N</code> to the last matched RewriteCond pattern
-<li>server-variables as in rule condition test-strings (<code>%{VARNAME}</code>)
-<li><a href="#mapfunc">mapping-function</a> calls (<code>${mapname:key|default}</code>)
-</ol>
-
-Back-references are <code>$</code><b>N</b> (<b>N</b>=1..9) identifiers which
-will be replaced by the contents of the <b>N</b>th group of the matched
-<em>Pattern</em>. The server-variables are the same as for the
-<em>TestString</em> of a <tt>RewriteCond</tt> directive. The
-mapping-functions come from the <tt>RewriteMap</tt> directive and are
+<EM>Pattern</EM> matched.  Beside plain text you can use
+
+<OL>
+<LI>back-references <CODE>$N</CODE> to the RewriteRule pattern
+<LI>back-references <CODE>%N</CODE> to the last matched RewriteCond pattern
+<LI>server-variables as in rule condition test-strings (<CODE>%{VARNAME}</CODE>)
+<LI><A HREF="#mapfunc">mapping-function</A> calls (<CODE>${mapname:key|default}</CODE>)
+</OL>
+
+Back-references are <CODE>$</CODE><STRONG>N</STRONG> (<STRONG>N</STRONG>=1..9) identifiers which
+will be replaced by the contents of the <STRONG>N</STRONG>th group of the matched
+<EM>Pattern</EM>. The server-variables are the same as for the
+<EM>TestString</EM> of a <TT>RewriteCond</TT> directive. The
+mapping-functions come from the <TT>RewriteMap</TT> directive and are
 explained there. These three types of variables are expanded in the order of
 the above list.
 
-<p>
+<P>
 As already mentioned above, all the rewriting rules are applied to the
-<em>Substitution</em> (in the order of definition in the config file).  The
-URL is <b>completely replaced</b> by the <em>Substitution</em> and the
+<EM>Substitution</EM> (in the order of definition in the config file).  The
+URL is <STRONG>completely replaced</STRONG> by the <EM>Substitution</EM> and the
 rewriting process goes on until there are no more rules (unless explicitly
-terminated by a <code><b>L</b></code> flag - see below).
+terminated by a <CODE><STRONG>L</STRONG></CODE> flag - see below).
 
-<p>
-There is a special substitution string named '<tt>-</tt>' which means:
-<b>NO substitution</b>! Sounds silly? No, it is useful to provide rewriting
-rules which <b>only</b> match some URLs but do no substitution, e.g. in
-conjunction with the <b>C</b> (chain) flag to be able to have more than one
+<P>
+There is a special substitution string named '<TT>-</TT>' which means:
+<STRONG>NO substitution</STRONG>! Sounds silly? No, it is useful to provide rewriting
+rules which <STRONG>only</STRONG> match some URLs but do no substitution, e.g. in
+conjunction with the <STRONG>C</STRONG> (chain) flag to be able to have more than one
 pattern to be applied before a substitution occurs.
 
-<p>
+<P>
 One more note: You can even create URLs in the substitution string containing
 a query string part. Just use a question mark inside the substitution string
 to indicate that the following stuff should be re-injected into the
 QUERY_STRING.  When you want to erase an existing query string, end the
 substitution string with just the question mark.
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
-<b>Notice</b>: There is a special feature. When you prefix a substitution
-field with <tt>http://</tt><em>thishost</em>[<em>:thisport</em>] then
-<b>mod_rewrite</b> automatically strips it out.   This auto-reduction on
+<TR><TD>
+<STRONG>Notice</STRONG>: There is a special feature. When you prefix a substitution
+field with <TT>http://</TT><EM>thishost</EM>[<EM>:thisport</EM>] then
+<STRONG>mod_rewrite</STRONG> automatically strips it out.   This auto-reduction on
 implicit external redirect URLs is a useful and important feature when
 used in combination with a mapping-function which generates the hostname
 part.  Have a look at the first example in the example section below to
 understand this.
-<p>
-<b>Remember:</b> An unconditional external redirect to your own server will
-not work with the prefix <tt>http://thishost</tt> because of this feature.
-To achieve such a self-redirect, you have to use the <b>R</b>-flag (see
+<P>
+<STRONG>Remember:</STRONG> An unconditional external redirect to your own server will
+not work with the prefix <TT>http://thishost</TT> because of this feature.
+To achieve such a self-redirect, you have to use the <STRONG>R</STRONG>-flag (see
 below).
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
-<p>
-Additionally you can set special flags for <em>Substitution</em> by appending
+<P>
+Additionally you can set special flags for <EM>Substitution</EM> by appending
 
-<blockquote><strong>
-<code>[</code><em>flags</em><code>]</code>
-</strong></blockquote>
+<BLOCKQUOTE><STRONG>
+<CODE>[</CODE><EM>flags</EM><CODE>]</CODE>
+</STRONG></BLOCKQUOTE>
 
-as the third argument to the <tt>RewriteRule</tt> directive. <em>Flags</em> is a
+as the third argument to the <TT>RewriteRule</TT> directive. <EM>Flags</EM> is a
 comma-separated list of the following flags:
 
-<ul>
-<li>'<strong><code>redirect|R</code>[=<i>code</i>]</strong>' (force <a name="redirect"><b>r</b>edirect</a>)<br>
-    Prefix <em>Substitution</em>
-    with <code>http://thishost[:thisport]/</code> (which makes the new URL a URI) to
-    force a external redirection. If no <i>code</i> is given a HTTP response
+<UL>
+<LI>'<STRONG><CODE>redirect|R</CODE>[=<EM>code</EM>]</STRONG>' (force <A name="redirect"><STRONG>r</STRONG>edirect</A>)<BR>
+    Prefix <EM>Substitution</EM>
+    with <CODE>http://thishost[:thisport]/</CODE> (which makes the new URL a URI) to
+    force a external redirection. If no <EM>code</EM> is given a HTTP response
     of 302 (MOVED TEMPORARILY) is used. If you want to use other response
     codes in the range 300-400 just specify them as a number or use
-    one of the following symbolic names: <tt>temp</tt> (default), <tt>permanent</tt>,
-    <tt>seeother</tt>.
+    one of the following symbolic names: <TT>temp</TT> (default), <TT>permanent</TT>,
+    <TT>seeother</TT>.
     Use it for rules which should
     canonicalize the URL and gives it back to the client, e.g. translate
-    ``<code>/~</code>'' into ``<code>/u/</code>'' or always append a slash to
-    <code>/u/</code><em>user</em>, etc.<br>
-    <p>
-    <b>Notice:</b> When you use this flag, make sure that the
+    ``<CODE>/~</CODE>'' into ``<CODE>/u/</CODE>'' or always append a slash to
+    <CODE>/u/</CODE><EM>user</EM>, etc.<BR>
+    <P>
+    <STRONG>Notice:</STRONG> When you use this flag, make sure that the
     substitution field is a valid URL! If not, you are redirecting to an
     invalid location!  And remember that this flag itself only prefixes the
-    URL with <code>http://thishost[:thisport]/</code>, but rewriting goes on.
+    URL with <CODE>http://thishost[:thisport]/</CODE>, but rewriting goes on.
     Usually you also want to stop and do the redirection immediately.  To stop
     the rewriting you also have to provide the 'L' flag.
-<p>
-<li>'<strong><code>forbidden|F</code></strong>' (force URL to be <b>f</b>orbidden)<br>
+<P>
+<LI>'<STRONG><CODE>forbidden|F</CODE></STRONG>' (force URL to be <STRONG>f</STRONG>orbidden)<BR>
     This forces the current URL to be forbidden, i.e. it immediately sends
     back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with
     appropriate RewriteConds to conditionally block some URLs.
-<p>
-<li>'<strong><code>gone|G</code></strong>' (force URL to be <b>g</b>one)<br>
+<P>
+<LI>'<STRONG><CODE>gone|G</CODE></STRONG>' (force URL to be <STRONG>g</STRONG>one)<BR>
     This forces the current URL to be gone, i.e. it immediately sends back a
     HTTP response of 410 (GONE). Use this flag to mark no longer existing
     pages as gone.
-<p>
-<li>'<strong><code>proxy|P</code></strong>' (force <b>p</b>roxy)<br>
+<P>
+<LI>'<STRONG><CODE>proxy|P</CODE></STRONG>' (force <STRONG>p</STRONG>roxy)<BR>
     This flag forces the substitution part to be internally forced as a proxy
     request and immediately (i.e. rewriting rule processing stops here) put
     through the proxy module. You have to make sure that the substitution
-    string is a valid URI (e.g. typically <tt>http://</tt>) which can
+    string is a valid URI (e.g. typically <TT>http://</TT>) which can
     be handled by the Apache proxy module. If not you get an error from
     the proxy module. Use this flag to achieve a more powerful implementation
-    of the <tt>mod_proxy</tt> directive <tt>ProxyPass</tt>, to map
+    of the <TT>mod_proxy</TT> directive <TT>ProxyPass</TT>, to map
     some remote stuff into the namespace of the local server.
-    <p>
-    Notice: <b>You really have to put <tt>ProxyRequests On</tt> into your
+    <P>
+    Notice: <STRONG>You really have to put <TT>ProxyRequests On</TT> into your
     server configuration to prevent proxy requests from leading to core-dumps
     inside the Apache kernel. If you have not compiled in the proxy module,
     then there is no core-dump problem, because mod_rewrite checks for
-    existence of the proxy module and if lost forbids proxy URLs.  </b>
-<p>
-<li>'<strong><code>last|L</code></strong>' (<b>l</b>ast rule)<br>
+    existence of the proxy module and if lost forbids proxy URLs.  </STRONG>
+<P>
+<LI>'<STRONG><CODE>last|L</CODE></STRONG>' (<STRONG>l</STRONG>ast rule)<BR>
     Stop the rewriting process here and
     don't apply any more rewriting rules. This corresponds to the Perl
-    <code>last</code> command or the <code>break</code> command from the C
+    <CODE>last</CODE> command or the <CODE>break</CODE> command from the C
     language. Use this flag to prevent the currently rewritten URL from being
     rewritten further by following rules which may be wrong. For
-    example, use it to rewrite the root-path URL ('<code>/</code>') to a real
-    one, e.g. '<code>/e/www/</code>'.
-<p>
-<li>'<strong><code>next|N</code></strong>' (<b>n</b>ext round)<br>
+    example, use it to rewrite the root-path URL ('<CODE>/</CODE>') to a real
+    one, e.g. '<CODE>/e/www/</CODE>'.
+<P>
+<LI>'<STRONG><CODE>next|N</CODE></STRONG>' (<STRONG>n</STRONG>ext round)<BR>
     Re-run the rewriting process (starting again with the first rewriting
     rule). Here the URL to match is again not the original URL but the URL
     from the last rewriting rule.  This corresponds to the Perl
-    <code>next</code> command or the <code>continue</code> command from the C
+    <CODE>next</CODE> command or the <CODE>continue</CODE> command from the C
     language. Use this flag to restart the rewriting process, i.e.  to
-    immediately go to the top of the loop. <br>
-    <b>But be careful not to create a deadloop!</b>
-<p>
-<li>'<strong><code>chain|C</code></strong>' (<b>c</b>hained with next rule)<br>
+    immediately go to the top of the loop. <BR>
+    <STRONG>But be careful not to create a deadloop!</STRONG>
+<P>
+<LI>'<STRONG><CODE>chain|C</CODE></STRONG>' (<STRONG>c</STRONG>hained with next rule)<BR>
     This flag chains the current rule with the next rule (which itself can
     also be chained with its following rule, etc.). This has the following
     effect: if a rule matches, then processing continues as usual, i.e. the
-    flag has no effect. If the rule does <b>not</b> match, then all following
+    flag has no effect. If the rule does <STRONG>not</STRONG> match, then all following
     chained rules are skipped.   For instance, use it to remove the
-    ``<tt>.www</tt>'' part inside a per-directory rule set when you let an
-    external redirect happen (where the ``<tt>.www</tt>'' part should not to
+    ``<TT>.www</TT>'' part inside a per-directory rule set when you let an
+    external redirect happen (where the ``<TT>.www</TT>'' part should not to
     occur!).
-<p>
-<li>'<strong><code>type|T</code></strong>=<em>mime-type</em>' (force MIME <b>t</b>ype)<br>
-    Force the MIME-type of the target file to be <em>mime-type</em>. For
-    instance, this can be used to simulate the old <tt>mod_alias</tt>
-    directive <tt>ScriptAlias</tt> which internally forces all files inside
+<P>
+<LI>'<STRONG><CODE>type|T</CODE></STRONG>=<EM>mime-type</EM>' (force MIME <STRONG>t</STRONG>ype)<BR>
+    Force the MIME-type of the target file to be <EM>mime-type</EM>. For
+    instance, this can be used to simulate the old <TT>mod_alias</TT>
+    directive <TT>ScriptAlias</TT> which internally forces all files inside
     the mapped directory to have a MIME type of
-    ``<tt>application/x-httpd-cgi</tt>''.
-<p>
-<li>'<strong><code>nosubreq|NS</code></strong>' (used only if <b>n</b>o internal <b>s</b>ub-request)<br>
+    ``<TT>application/x-httpd-cgi</TT>''.
+<P>
+<LI>'<STRONG><CODE>nosubreq|NS</CODE></STRONG>' (used only if <STRONG>n</STRONG>o internal <STRONG>s</STRONG>ub-request)<BR>
     This flag forces the rewriting engine to skip a rewriting rule if the
     current request is an internal sub-request. For instance, sub-requests
-    occur internally in Apache when <tt>mod_include</tt> tries to find out
-    information about possible directory default files (<tt>index.xxx</tt>).
+    occur internally in Apache when <TT>mod_include</TT> tries to find out
+    information about possible directory default files (<TT>index.xxx</TT>).
     On sub-requests it is not always useful and even sometimes causes a failure to
-    if the complete set of rules are applied. Use this flag to exclude some rules.<br>
-    <p>
+    if the complete set of rules are applied. Use this flag to exclude some rules.<BR>
+    <P>
     Use the following rule for your decision: whenever you prefix some URLs
     with CGI-scripts to force them to be processed by the CGI-script, the
     chance is high that you will run into problems (or even overhead) on sub-requests.
     In these cases, use this flag.
-<p>
-<li>'<strong><code>qsappend|QSA</code></strong>' (<b>q</b>uery <b>s</b>tring
-    <b>a</b>ppend)<br
+<P>
+<LI>'<STRONG><CODE>qsappend|QSA</CODE></STRONG>' (<STRONG>q</STRONG>uery <STRONG>s</STRONG>tring
+    <STRONG>a</STRONG>ppend)<BR
     This flag forces the rewriting engine to append a query
     string part in the substitution string to the existing one instead of
     replacing it.  Use this when you want to add more data to the query string
     via a rewrite rule.
-<p>
-<li>'<strong><code>passthrough|PT</code></strong>' (<b>p</b>ass <b>t</b>hrough to next handler)<br>
-    This flag forces the rewriting engine to set the <code>uri</code> field
-    of the internal <code>request_rec</code> structure to the value
-    of the <code>filename</code> field.  This flag is just a hack to be able
-    to post-process the output of <tt>RewriteRule</tt> directives by
-    <tt>Alias</tt>, <tt>ScriptAlias</tt>, <tt>Redirect</tt>, etc. directives
+<P>
+<LI>'<STRONG><CODE>passthrough|PT</CODE></STRONG>' (<STRONG>p</STRONG>ass <STRONG>t</STRONG>hrough to next handler)<BR>
+    This flag forces the rewriting engine to set the <CODE>uri</CODE> field
+    of the internal <CODE>request_rec</CODE> structure to the value
+    of the <CODE>filename</CODE> field.  This flag is just a hack to be able
+    to post-process the output of <TT>RewriteRule</TT> directives by
+    <TT>Alias</TT>, <TT>ScriptAlias</TT>, <TT>Redirect</TT>, etc. directives
     from other URI-to-filename translators. A trivial example to show the
     semantics:
-    If you want to rewrite <tt>/abc</tt> to <tt>/def</tt> via the rewriting
-    engine of <tt>mod_rewrite</tt> and then <tt>/def</tt> to <tt>/ghi</tt>
-    with <tt>mod_alias</tt>:
-    <pre>
+    If you want to rewrite <TT>/abc</TT> to <TT>/def</TT> via the rewriting
+    engine of <TT>mod_rewrite</TT> and then <TT>/def</TT> to <TT>/ghi</TT>
+    with <TT>mod_alias</TT>:
+    <PRE>
     RewriteRule ^/abc(.*)  /def$1 [PT]
     Alias       /def       /ghi
-    </pre>
-    If you omit the <tt>PT</tt> flag then <tt>mod_rewrite</tt>
-    will do its job fine, i.e. it rewrites <tt>uri=/abc/...</tt> to
-    <tt>filename=/def/...</tt> as a full API-compliant URI-to-filename
-    translator should do. Then <tt>mod_alias</tt> comes and tries to do a
+    </PRE>
+    If you omit the <TT>PT</TT> flag then <TT>mod_rewrite</TT>
+    will do its job fine, i.e. it rewrites <TT>uri=/abc/...</TT> to
+    <TT>filename=/def/...</TT> as a full API-compliant URI-to-filename
+    translator should do. Then <TT>mod_alias</TT> comes and tries to do a
     URI-to-filename transition which will not work.
-    <p>
-    Notice: <b>You have to use this flag if you want to intermix directives
-    of different modules which contain URL-to-filename translators</b>. The
-    typical example is the use of <tt>mod_alias</tt> and
-    <tt>mod_rewrite</tt>..
-<p>
+    <P>
+    Notice: <STRONG>You have to use this flag if you want to intermix directives
+    of different modules which contain URL-to-filename translators</STRONG>. The
+    typical example is the use of <TT>mod_alias</TT> and
+    <TT>mod_rewrite</TT>..
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
+<TR><TD>
 <font size=-1>
-    <b>For the Apache hackers:</b><br>
+    <STRONG>For the Apache hackers:</STRONG><BR>
     If the current Apache API had a
     filename-to-filename hook additionally to the URI-to-filename hook then
     we wouldn't need this flag!  But without  such a hook this flag is the
     only solution. The Apache Group has discussed this problem and will
     add such hooks into Apache version 2.0.
-</font>
-</td></tr>
-</table>
-<p>
-<li>'<strong><code>skip|S</code></strong>=<em>num</em>' (<b>s</b>kip next rule(s))<br>
-    This flag forces the rewriting engine to skip the next <em>num</em> rules
+</FONT>
+</TD></TR>
+</TABLE>
+<P>
+<LI>'<STRONG><CODE>skip|S</CODE></STRONG>=<EM>num</EM>' (<STRONG>s</STRONG>kip next rule(s))<BR>
+    This flag forces the rewriting engine to skip the next <EM>num</EM> rules
     in sequence when the current rule matches. Use this to make pseudo
     if-then-else constructs: The last rule of the then-clause becomes
-    a <tt>skip=N</tt> where N is the number of rules in the else-clause.
-    (This is <b>not</b> the same as the 'chain|C' flag!)
-<p>
-<li>'<strong><code>env|E=</code></strong><i>VAR</i>:<i>VAL</i>' (set <b>e</b>nvironment variable)<br>
-       This forces an environment variable named <i>VAR</i> to be set to the
-       value <i>VAL</i>, where <i>VAL</i> can contain regexp backreferences
-       <tt>$N</tt> and <tt>%N</tt> which will be expanded. You can use this flag
+    a <TT>skip=N</TT> where N is the number of rules in the else-clause.
+    (This is <STRONG>not</STRONG> the same as the 'chain|C' flag!)
+<P>
+<LI>'<STRONG><CODE>env|E=</CODE></STRONG><EM>VAR</EM>:<EM>VAL</EM>' (set <STRONG>e</STRONG>nvironment variable)<BR>
+       This forces an environment variable named <EM>VAR</EM> to be set to the
+       value <EM>VAL</EM>, where <EM>VAL</EM> can contain regexp backreferences
+       <TT>$N</TT> and <TT>%N</TT> which will be expanded. You can use this flag
        more than once to set more than one variable. The variables can be later
        dereferenced at a lot of situations, but the usual location will be from
-       within XSSI (via <tt>&lt;!--#echo var="VAR"--&gt;</tt>) or CGI (e.g.
-       <tt>$ENV{'VAR'}</tt>).  But additionally you can also dereference it in a
-       following RewriteCond pattern via <tt>%{ENV:VAR}</tt>. Use this to strip
+       within XSSI (via <TT>&lt;!--#echo var="VAR"--&gt;</TT>) or CGI (e.g.
+       <TT>$ENV{'VAR'}</TT>).  But additionally you can also dereference it in a
+       following RewriteCond pattern via <TT>%{ENV:VAR}</TT>. Use this to strip
        but remember information from URLs.
-</ul>
+</UL>
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
-Remember: Never forget that <em>Pattern</em> gets applied to a complete URL
-in per-server configuration files. <b>But in per-directory configuration
+<TR><TD>
+Remember: Never forget that <EM>Pattern</EM> gets applied to a complete URL
+in per-server configuration files. <STRONG>But in per-directory configuration
 files, the per-directory prefix (which always is the same for a specific
-directory!) gets automatically <em>removed</em> for the pattern matching and
-automatically <em>added</em> after the substitution has been done.</b> This feature is
+directory!) gets automatically <EM>removed</EM> for the pattern matching and
+automatically <EM>added</EM> after the substitution has been done.</STRONG> This feature is
 essential for many sorts of rewriting, because without this prefix stripping
 you have to match the parent directory which is not always possible.
-<p>
+<P>
 There is one exception: If a substitution string starts with
-``<tt>http://</tt>'' then the directory prefix will be <b>not</b> added and a
-external redirect or proxy throughput (if flag <b>P</b> is used!) is forced!
-</td></tr>
-</table>
+``<TT>http://</TT>'' then the directory prefix will be <STRONG>not</STRONG> added and a
+external redirect or proxy throughput (if flag <STRONG>P</STRONG> is used!) is forced!
+</TD></TR>
+</TABLE>
 
-<p>
+<P>
 <table width="70%" border=0 bgcolor="#fff0f0" cellspacing=0 cellpadding=10>
-<tr><td>
+<TR><TD>
 Notice!  To enable the rewriting engine for per-directory configuration files
-you need to set ``<tt>RewriteEngine On</tt>'' in these files <b>and</b>
-``<tt>Option FollowSymLinks</tt>'' enabled. If your administrator has
-disabled override of <tt>FollowSymLinks</tt> for a user's directory, then
+you need to set ``<TT>RewriteEngine On</TT>'' in these files <STRONG>and</STRONG>
+``<TT>Option FollowSymLinks</TT>'' enabled. If your administrator has
+disabled override of <TT>FollowSymLinks</TT> for a user's directory, then
 you cannot use the rewriting engine.  This restriction is needed for
 security reasons.
-</td></tr>
-</table>
+</TD></TR>
+</TABLE>
 
-<p>
+<P>
 Here are all possible substitution combinations and their meanings:
 
-<p>
-<b>Inside per-server configuration (<tt>httpd.conf</tt>)<br>
-for request ``<tt>GET /somepath/pathinfo</tt>'':</b><br>
+<P>
+<STRONG>Inside per-server configuration (<TT>httpd.conf</TT>)<BR>
+for request ``<TT>GET /somepath/pathinfo</TT>'':</STRONG><BR>
 
-<p>
+<P>
 <table bgcolor="#f0f0f0" cellspacing=0 cellpadding=5>
-<tr>
-<td>
-<pre>
-<b>Given Rule</b>                                      <b>Resulting Substitution</b>
+<TR>
+<TD>
+<PRE>
+<STRONG>Given Rule</STRONG>                                      <STRONG>Resulting Substitution</STRONG>
 ----------------------------------------------  ----------------------------------
 ^/somepath(.*) otherpath$1                      not supported, because invalid!
 
@@ -1125,23 +1125,23 @@ for request ``<tt>GET /somepath/pathinfo</tt>'':</b><br>
 
 ^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                 via internal proxy
-</pre>
-</td>
-</tr>
-</table>
-
-<p>
-<b>Inside per-directory configuration for <tt>/somepath</tt><br>
-(i.e. file <tt>.htaccess</tt> in dir <tt>/physical/path/to/somepath</tt> containing
-<tt>RewriteBase /somepath</tt>)<br> for
-request ``<tt>GET /somepath/localpath/pathinfo</tt>'':</b><br>
-
-<p>
+</PRE>
+</TD>
+</TR>
+</TABLE>
+
+<P>
+<STRONG>Inside per-directory configuration for <TT>/somepath</TT><BR>
+(i.e. file <TT>.htaccess</TT> in dir <TT>/physical/path/to/somepath</TT> containing
+<TT>RewriteBase /somepath</TT>)<BR> for
+request ``<TT>GET /somepath/localpath/pathinfo</TT>'':</STRONG><BR>
+
+<P>
 <table bgcolor="#f0f0f0" cellspacing=0 cellpadding=5>
-<tr>
-<td>
-<pre>
-<b>Given Rule</b>                                      <b>Resulting Substitution</b>
+<TR>
+<TD>
+<PRE>
+<STRONG>Given Rule</STRONG>                                      <STRONG>Resulting Substitution</STRONG>
 ----------------------------------------------  ----------------------------------
 ^localpath(.*) otherpath$1                      /somepath/otherpath/pathinfo
 
@@ -1173,80 +1173,80 @@ request ``<tt>GET /somepath/localpath/pathinfo</tt>'':</b><br>
 
 ^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                 via internal proxy
-</pre>
-</td>
-</tr>
-</table>
+</PRE>
+</TD>
+</TR>
+</TABLE>
 
 
-<p>
-<b>Example:</b>
-<p>
-<blockquote>
+<P>
+<STRONG>Example:</STRONG>
+<P>
+<BLOCKQUOTE>
 We want to rewrite URLs of the form
-<blockquote>
-<code>/</code> <em>Language</em>
-<code>/~</code> <em>Realname</em>
-<code>/.../</code> <em>File</em>
-</blockquote>
+<BLOCKQUOTE>
+<CODE>/</CODE> <EM>Language</EM>
+<CODE>/~</CODE> <EM>Realname</EM>
+<CODE>/.../</CODE> <EM>File</EM>
+</BLOCKQUOTE>
 into
-<blockquote>
-<code>/u/</code> <em>Username</em>
-<code>/.../</code> <em>File</em>
-<code>.</code> <em>Language</em>
-</blockquote>
-<p>
+<BLOCKQUOTE>
+<CODE>/u/</CODE> <EM>Username</EM>
+<CODE>/.../</CODE> <EM>File</EM>
+<CODE>.</CODE> <EM>Language</EM>
+</BLOCKQUOTE>
+<P>
 We take the rewrite mapfile from above and save it under
-<code>/anywhere/map.real-to-user</code>. Then we only have to add the
+<CODE>/anywhere/map.real-to-user</CODE>. Then we only have to add the
 following lines to the Apache server configuration file:
 
-<blockquote>
-<pre>
+<BLOCKQUOTE>
+<PRE>
 RewriteLog   /anywhere/rewrite.log
 RewriteMap   real-to-user               txt:/anywhere/map.real-to-host
 RewriteRule  ^/([^/]+)/~([^/]+)/(.*)$   /u/${real-to-user:$2|nobody}/$3.$1
-</pre>
-</blockquote>
-</blockquote>
+</PRE>
+</BLOCKQUOTE>
+</BLOCKQUOTE>
 
 
 <!--%hypertext -->
-<hr>
+<HR>
 <!--/%hypertext -->
 
-<center>
-<a name="Additional">
-<h1>Additional Features</h1>
-</a>
-</center>
+<CENTER>
+<A name="Additional">
+<H1>Additional Features</H1>
+</A>
+</CENTER>
 
-<a name="EnvVar">
+<A name="EnvVar">
 <h2>Environment Variables</h2>
-</a>
+</A>
 
 This module keeps track of two additional (non-standard) CGI/SSI environment
-variables named <tt>SCRIPT_URL</tt> and <tt>SCRIPT_URI</tt>. These contain
-the <em>logical</em> Web-view to the current resource, while the standard CGI/SSI
-variables <tt>SCRIPT_NAME</tt> and <tt>SCRIPT_FILENAME</tt> contain the
-<em>physical</em> System-view. 
-
-<p>
-Notice: These variables hold the URI/URL <em>as they were initially
-requested</em>, i.e. in a state <em>before</em> any rewriting. This is
+variables named <TT>SCRIPT_URL</TT> and <TT>SCRIPT_URI</TT>. These contain
+the <EM>logical</EM> Web-view to the current resource, while the standard CGI/SSI
+variables <TT>SCRIPT_NAME</TT> and <TT>SCRIPT_FILENAME</TT> contain the
+<EM>physical</EM> System-view. 
+
+<P>
+Notice: These variables hold the URI/URL <EM>as they were initially
+requested</EM>, i.e. in a state <EM>before</EM> any rewriting. This is
 important because the rewriting process is primarily used to rewrite logical
 URLs to physical pathnames.
 
-<p>
-<b>Example:</b>
+<P>
+<STRONG>Example:</STRONG>
 
-<blockquote>
-<pre>
+<BLOCKQUOTE>
+<PRE>
 SCRIPT_NAME=/v/sw/free/lib/apache/global/u/rse/.www/index.html
 SCRIPT_FILENAME=/u/rse/.www/index.html
 SCRIPT_URL=/u/rse/
 SCRIPT_URI=http://en2.en.sdm.de/u/rse/
-</pre>
-</blockquote>
+</PRE>
+</BLOCKQUOTE>
 
 
 <!--#include virtual="footer.html" -->
index 3ece21704c4b32e7d8b7cac7b9601101aaa91ac8..b2ed9e5ec56d2ff8c74b496c059bb9985edef733 100644 (file)
 <!--#include virtual="header.html" -->
   <H1 ALIGN="CENTER">Module mod_speling</H1>
   <P>
-  This module is contained in the <code>mod_speling.c</code> file,
-  and is <strong>not</strong> compiled in by default.
+  This module is contained in the <CODE>mod_speling.c</CODE> file,
+  and is <STRONG>not</STRONG> compiled in by default.
   It attempts to correct misspellings of
   URLs that users might have entered, by ignoring capitalization
-  and by allowing up to one misspelling.<br>
+  and by allowing up to one misspelling.<BR>
   This catches the majority of misspelled requests. An automatic
   "spelling corrected" redirection is returned if only one matching
   document was found, and a list of matches is returned if more than
@@ -26,7 +26,7 @@
   </P>
 
   <h2>Summary</h2>
-  <p>
+  <P>
   Requests to documents sometimes cannot be served by the core apache
   server because the request was misspelled or miscapitalized. This
   module addresses this problem by trying to find a matching document,
   <STRONG>up to one misspelling</STRONG> (character insertion / omission
   / transposition or wrong character). A list is built with all document
   names which were matched using this strategy.
-  </p>
-  <p>
+  </P>
+  <P>
   If, after scanning the directory,
-  <ul>
-   <li>no matching document was found, Apache will proceed as usual
+  <UL>
+   <LI>no matching document was found, Apache will proceed as usual
        and return a "document not found" error.
-   <li>only one document is found that "almost" matches the request,
+   <LI>only one document is found that "almost" matches the request,
        then it is returned in the form of a redirection response.
-   <li>more than one document with a close match was found, then
+   <LI>more than one document with a close match was found, then
        the list of the matches is returned to the client, and the client
        can select the correct candidate.
-  </ul>
-  </p>
+  </UL>
+  </P>
 
   <h2>Directives</h2>
 
-  <menu>
-  <li><A HREF="#checkspelling">CheckSpelling</A>
-  </menu>
+  <MENU>
+  <LI><A HREF="#checkspelling">CheckSpelling</A>
+  </MENU>
 
   <HR> <!-- the HR is part of the directive description -->
   <A name="checkspelling"><h2>CheckSpelling</h2></A>
   <!--%plaintext &lt;?INDEX {\tt CheckSpelling} directive&gt; -->
-  <strong>Syntax:</strong> CheckSpelling <em>on/off</em><br>
-  <strong>Default:</strong> <code>CheckSpelling Off</code><br>
-  <Strong>Context:</strong> server config, virtual host<br>
-  <strong>Status:</strong> Base<br>
-  <strong>Module:</strong> mod_speling<br>
-  <strong>Compatibility:</strong> CheckSpelling was available as a separately
+  <STRONG>Syntax:</STRONG> CheckSpelling <EM>on/off</EM><BR>
+  <STRONG>Default:</STRONG> <CODE>CheckSpelling Off</CODE><BR>
+  <Strong>Context:</STRONG> server config, virtual host<BR>
+  <STRONG>Status:</STRONG> Base<BR>
+  <STRONG>Module:</STRONG> mod_speling<BR>
+  <STRONG>Compatibility:</STRONG> CheckSpelling was available as a separately
   available module for Apache 1.1, but was limited to miscapitalizations.
   As of Apache 1.3, it is part of the apache distribution<!-- or:
-  available as a separate module-->.<p>
+  available as a separate module-->.<P>
 
   This directive enables or disables the spelling module. When enabled,
   keep in mind that
@@ -78,7 +78,7 @@
   <LI>the document trees should not contain sensitive files which could
       be matched inadvertently, by a spelling "correction".
   <LI>the module is unable to correct misspelled user names
-      (as in <code>http://my.host/~apahce/</code>), just file names or
+      (as in <CODE>http://my.host/~apahce/</CODE>), just file names or
       directory names.
   </UL>
 
index 65c2dc389d09b9e6be5215bb799b652fb99dce4b..f6335a6926ca26ab6ba87e2235cc3c51444fc2b9 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache module mod_status</title>
-</head><!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+<HTML><HEAD>
+<TITLE>Apache module mod_status</TITLE>
+</HEAD><!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  TEXT="#000000"
@@ -11,9 +11,9 @@
 >
 
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Module mod_status</h1>
+<h1 ALIGN="CENTER">Module mod_status</H1>
 
-The Status Module is only available in Apache 1.1 and later.<p>
+The Status Module is only available in Apache 1.1 and later.<P>
 
 <h2>Function</h2>
 
@@ -23,23 +23,23 @@ the current server statistics in an easily readable form.  If required
 this page can be made to automatically refresh (given a compatible
 browser).  Another page gives a simple machine-readable list of the current
 server state.
-<p>
+<P>
 The details given are:
-<ul>
-<li>The number of children serving requests
-<li>The number of idle children
-<li>The status of each child, the number of requests that child has
+<UL>
+<LI>The number of children serving requests
+<LI>The number of idle children
+<LI>The status of each child, the number of requests that child has
 performed and the total number of bytes served by the child (*)
-<li>A total number of accesses and byte count served (*)
-<li>The time the server was started/restarted and the
+<LI>A total number of accesses and byte count served (*)
+<LI>The time the server was started/restarted and the
 time it has been running for
-<li>Averages giving the number of requests per second,
+<LI>Averages giving the number of requests per second,
 the number of bytes served per second and the average number
 of bytes per request (*)
-<li>The current percentage CPU used by each child and in total by
+<LI>The current percentage CPU used by each child and in total by
 Apache (*)
-<li>The current hosts and requests being processed (*)
-</ul>
+<LI>The current hosts and requests being processed (*)
+</UL>
 
 A compile-time option must be used to display the details marked "(*)" as
 the instrumentation required for obtaining these statistics does not
@@ -48,8 +48,8 @@ exist within standard Apache.
 <h2>Enabling Status Support</h2>
 
 To enable status reports only for browsers from the foo.com
-domain add this code to your <code>access.conf</code> configuration file
-<pre>
+domain add this code to your <CODE>access.conf</CODE> configuration file
+<PRE>
     &lt;Location /server-status&gt;
     SetHandler server-status
 
@@ -57,11 +57,11 @@ domain add this code to your <code>access.conf</code> configuration file
     deny from all
     allow from .foo.com
     &lt;/Location&gt;
-</pre>
-<p>
+</PRE>
+<P>
 You can now access server statistics by using a Web browser to access the
-page <code>http://your.server.name/server-status</code>
-<p>
+page <CODE>http://your.server.name/server-status</CODE>
+<P>
 Note that mod_status will only work when you are running Apache in
 <A HREF="core.html#servertype">standalone</A> mode and not
 <A HREF="core.html#servertype">inetd</A> mode.
@@ -69,29 +69,29 @@ Note that mod_status will only work when you are running Apache in
 <h3>Automatic Updates</h3>
 You can get the status page to update itself automatically if you have
 a browser that supports "refresh".  Access the page
-<code>http://your.server.name/server-status?refresh=N</code> to refresh the page
+<CODE>http://your.server.name/server-status?refresh=N</CODE> to refresh the page
 every N seconds.
 <h3>Machine Readable Status File</h3>
 A machine-readable version of the status file is available by accessing the
-page <code>http://your.server.name/server-status?auto</code>.  This is useful
-when automatically run, see the Perl program in the <code>/support</code>
-directory of Apache, <code>log_server_status</code>.
+page <CODE>http://your.server.name/server-status?auto</CODE>.  This is useful
+when automatically run, see the Perl program in the <CODE>/support</CODE>
+directory of Apache, <CODE>log_server_status</CODE>.
 
 <h2>Full Instrumentation</h2>
 
 To obtain full statistics you must compile Apache with a special
 directive.  On some machines there may be a small performance loss
 if you do this.  Try full statistics and see if you notice any
-difference.  If you do please contact <a href="mailto:mark@ukweb.com">
-mark@ukweb.com</a> and tell me your configuration.
+difference.  If you do please contact <A HREF="mailto:mark@ukweb.com">
+mark@ukweb.com</A> and tell me your configuration.
 
-<p>
+<P>
 
 Do this by adding the following to the AUX_CFLAGS line in the
 "Configuration" file and then recompiling as usual.
-<pre>
+<PRE>
         AUX_CFLAGS= (something) -DSTATUS
-</pre>
+</PRE>
 
 <BLOCKQUOTE>
  <STRONG>
index ff71fce93425cb97e0a66b2124ff986156a5aacb..919c9e8146d144a3a5b7ec4938d5742a5ccbdf51 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_unique_id</h1>
+<H1 ALIGN="CENTER">Module mod_unique_id</H1>
 
 This module provides a magic token for each request which is guaranteed
 to be unique across "all" requests under very specific conditions.
 The unique identifier is even unique across multiple machines in a
 properly configured cluster of machines.  The environment variable
-<code>UNIQUE_ID</code> is set to the identifier for each request.
+<CODE>UNIQUE_ID</CODE> is set to the identifier for each request.
 Unique identifiers are useful for various reasons which are beyond the
 scope of this document.
 
 <h2>Theory</h2>
 
-<p>
+<P>
 First a brief recap of how the Apache server works on Unix machines.
 This feature currently isn't supported on Windows NT.  On Unix machines,
 Apache creates several children, the children process requests one at
@@ -33,7 +33,7 @@ a time.  Each child can serve multiple requests in its lifetime.  For the
 purpose of this discussion, the children don't share any data
 with each other.  We'll refer to the children as httpd processes.
 
-<p>
+<P>
 Your website has one or more machines under your administrative control,
 together we'll call them a cluster of machines.  Each machine can
 possibly run multiple instances of Apache.  All of these collectively
@@ -41,42 +41,42 @@ are considered "the universe", and with certain assumptions we'll
 show that in this universe we can generate unique identifiers for each
 request, without extensive communication between machines in the cluster.
 
-<p>
+<P>
 The machines in your cluster should satisfy these requirements.
 (Even if you have only one machine you should synchronize its clock
 with NTP.)
 
-<ul>
-<li>The machines' times are synchronized via NTP or other network time
+<UL>
+<LI>The machines' times are synchronized via NTP or other network time
     protocol.
 
-<li>The machines' hostnames all differ, such that the module can do a
+<LI>The machines' hostnames all differ, such that the module can do a
     hostname lookup on the hostname and receive a different IP address
     for each machine in the cluster.
-</ul>
+</UL>
 
-<p>
+<P>
 As far as operating system assumptions go, we assume that pids (process
 ids) fit in 32-bits.  If the operating system uses more than 32-bits
 for a pid, the fix is trivial but must be performed in the code.
 
-<p>
+<P>
 Given those assumptions, at a single point in time we can identify
 any httpd process on any machine in the cluster from all other httpd
 processes.  The machine's IP address and the pid of the httpd process
 are sufficient to do this.  So in order to generate unique identifiers
 for requests we need only distinguish between different points in time.
 
-<p>
+<P>
 To distinguish time we will use a Unix timestamp (seconds since January
 1, 1970 UTC), and a 16-bit counter.  The timestamp has only one second
 granularity, so the counter is used to represent up to 65536 values
-during a single second.  The quadruple <i>( ip_addr, pid, time_stamp,
-counter )</i> is sufficient to enumerate 65536 requests per second per
+during a single second.  The quadruple <EM>( ip_addr, pid, time_stamp,
+counter )</EM> is sufficient to enumerate 65536 requests per second per
 httpd process.  There are issues however with pid reuse over
 time, and the counter is used to alleviate this issue.
 
-<p>
+<P>
 When an httpd child is created, the counter is initialized with (
 current microseconds divided by 10 ) modulo 65536 (this formula was
 chosen to eliminate some variance problems with the low order bits of
@@ -85,7 +85,7 @@ generated, the time stamp used is the time the request arrived at the
 web server.  The counter is incremented every time an identifier is
 generated (and allowed to roll over).
 
-<p>
+<P>
 The kernel generates a pid for each process as it forks the process, and
 pids are allowed to roll over (they're 16-bits on many Unixes, but newer
 systems have expanded to 32-bits).  So over time the same pid will be
@@ -94,7 +94,7 @@ destroy the uniqueness of our quadruple.  That is, we assume the system
 does not spawn 65536 processes in a one second interval (it may even be
 32768 processes on some Unixes, but even this isn't likely to happen).
 
-<p>
+<P>
 Suppose that time repeats itself for some reason.  That is, suppose that
 the system's clock is screwed up and it revisits a past time (or it is
 too far forward, is reset correctly, and then revisits the future time).
@@ -106,7 +106,7 @@ can't use rand() because you need to seed the generator, and can't seed
 it with the time because time, at least at one second resolution, has
 repeated itself).  This is not a perfect defense.
 
-<p>
+<P>
 How good a defense is it?  Well suppose that one of your machines serves
 at most 500 requests per second (which is a very reasonable upper bound
 at this writing, because systems generally do more than just shovel out
@@ -121,7 +121,7 @@ and with real world values it's even less likely to occur.  If your
 system is such that it's still likely to occur, then perhaps you should
 make the counter 32 bits (by editing the code).
 
-<p>
+<P>
 You may be concerned about the clock being "set back" during summer
 daylight savings.  However this isn't an issue because the times used here
 are UTC, which "always" go forward.  Note that x86 based Unixes may need
@@ -130,33 +130,33 @@ assume that the motherboard clock is on UTC and compensate appropriately.
 But even still, if you're running NTP then your UTC time will be correct
 very shortly after reboot.
 
-<p>
-The <code>UNIQUE_ID</code> environment variable is constructed by
+<P>
+The <CODE>UNIQUE_ID</CODE> environment variable is constructed by
 encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp,
-16 bit counter) quadruple using the alphabet <code>[A-Za-z0-9@-]</code>
+16 bit counter) quadruple using the alphabet <CODE>[A-Za-z0-9@-]</CODE>
 in a manner similar to MIME base64 encoding, producing 19 characters.
-The MIME base64 alphabet is actually <code>[A-Za-z0-9+/]</code> however
-<code>+</code> and <code>/</code> need to be specially encoded in URLs,
+The MIME base64 alphabet is actually <CODE>[A-Za-z0-9+/]</CODE> however
+<CODE>+</CODE> and <CODE>/</CODE> need to be specially encoded in URLs,
 which makes them less desirable.  All values are encoded in network
 byte ordering so that the encoding is comparable across architectures of
 different byte ordering.  The actual ordering of the encoding is: time
 stamp, IP address, pid, counter.  This ordering has a purpose, but it
 should be emphasized that applications should not dissect the encoding.
-Applications should treat the entire encoded <code>UNIQUE_ID</code> as an
-opaque token, which can be compared against other <code>UNIQUE_ID</code>s
+Applications should treat the entire encoded <CODE>UNIQUE_ID</CODE> as an
+opaque token, which can be compared against other <CODE>UNIQUE_ID</CODE>s
 for equality only.
 
-<p>
+<P>
 The ordering was chosen such that it's possible to change the encoding
 in the future without worrying about collision with an existing database
-of <code>UNIQUE_ID</code>s.  The new encodings should also keep the time
+of <CODE>UNIQUE_ID</CODE>s.  The new encodings should also keep the time
 stamp as the first element, and can otherwise use the same alphabet and
 bit length.  Since the time stamps are essentially an increasing sequence,
-it's sufficient to have a <i>flag second</i> in which all machines in the
+it's sufficient to have a <EM>flag second</EM> in which all machines in the
 cluster stop serving and request, and stop using the old encoding format.
 Afterwards they can resume requests and begin issuing the new encodings.
 
-<p>
+<P>
 This we believe is a relatively portable solution to this problem.  It can
 be extended to multithreaded systems like Windows NT, and can grow with
 future needs.  The identifiers generated have essentially an infinite
@@ -169,11 +169,11 @@ situations the identifier can be shortened, but more information needs
 to be assumed (for example the 32-bit IP address is overkill for any
 site, but there is no portable shorter replacement for it).
 
-<hr>
+<HR>
 
 <h2>Directives</h2>
 
-<code>mod_unique_id</code> has no directives.
+<CODE>mod_unique_id</CODE> has no directives.
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 50ae172b132cb5453bf2c3fe0c8a5dc7874d11f8..2d79f11940482345366eff8033c0636f39d3619c 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_userdir</h1>
+<H1 ALIGN="CENTER">Module mod_userdir</H1>
 
-This module is contained in the <code>mod_userdir.c</code> file, and
+This module is contained in the <CODE>mod_userdir.c</CODE> file, and
 is compiled in by default. It provides for user-specific directories.
 
 
-<ul>
-<li><A HREF="#userdir">UserDir</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#userdir">UserDir</A>
+</UL>
+<HR>
 
 
 <h2><A name="userdir">UserDir</A></h2>
 <!--%plaintext &lt;?INDEX {\tt UserDir} directive&gt; -->
-<strong>Syntax:</strong> UserDir <em>directory/filename</em><br>
-<strong>Default:</strong> <code>UserDir public_html</code><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_userdir<br>
-<strong>Compatibility:</strong> All forms except the <code>UserDir
-public_html</code> form are only available in Apache 1.1 or above.  Use
+<STRONG>Syntax:</STRONG> UserDir <EM>directory/filename</EM><BR>
+<STRONG>Default:</STRONG> <CODE>UserDir public_html</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_userdir<BR>
+<STRONG>Compatibility:</STRONG> All forms except the <CODE>UserDir
+public_html</CODE> form are only available in Apache 1.1 or above.  Use
 of the <SAMP>enabled</SAMP> keyword, or <SAMP>disabled</SAMP> with a
-list of usernames, is only available in Apache 1.3 and above.<p>
+list of usernames, is only available in Apache 1.3 and above.<P>
 
 The UserDir directive sets the real directory in a user's home directory
 to use when a request for a document for a user is received.
-<em>Directory/filename</em> is one of the following:
+<EM>Directory/filename</EM> is one of the following:
 </P>
 <UL>
  <LI>The name of a directory or a pattern such as those shown below.
@@ -64,18 +64,18 @@ If neither the <SAMP>enabled</SAMP> nor the <SAMP>disabled</SAMP>
 keywords appear in the <SAMP>Userdir</SAMP> directive, the argument is
 treated as a filename pattern, and is used to turn the name into a
 directory specification.  A request for
-<code>http://www.foo.com/~bob/one/two.html</code> will be translated to:
-<pre>
+<CODE>http://www.foo.com/~bob/one/two.html</CODE> will be translated to:
+<PRE>
 UserDir public_html     -&gt; ~bob/public_html/one/two.html
 UserDir /usr/web        -&gt; /usr/web/bob/one/two.html
 UserDir /home/*/www     -&gt; /home/bob/www/one/two.html
-</pre>
+</PRE>
 The following directives will send redirects to the client:
-<pre>
+<PRE>
 UserDir http://www.foo.com/users   -&gt; http//www.foo.com/users/bob/one/two.html
 UserDir http://www.foo.com/*/usr   -&gt; http://www.foo.com/bob/usr/one/two.html
 UserDir http://www.foo.com/~*/     -&gt; http://www.foo.com/~bob/one/two.html
-</pre>
+</PRE>
 </P>
 <BLOCKQUOTE>
  <STRONG>
index 3bc03d3c2280eb9dab6fa06e329058bd966debd7..af88b17c43c14cfbfbc45dabfbb954d7e4a9e1b2 100644 (file)
@@ -13,7 +13,7 @@
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_usertrack</h1>
+<H1 ALIGN="CENTER">Module mod_usertrack</H1>
 
 Previous releases of Apache have included a module which generates a
 'clickstream' log of user activity on a site using cookies. This was
@@ -22,60 +22,60 @@ module has been renamed the "user tracking" module,
 mod_usertrack. This module has been simplified and new directives
 added.
 
-<hr>
+<HR>
 
 <h2>Logging</h2>
 
 Previously, the cookies module (now the user tracking module) did its
-own logging, using the <tt>CookieLog</tt> directive. In this release,
+own logging, using the <TT>CookieLog</TT> directive. In this release,
 this module does no logging at all. Instead, a configurable log
 format file should be used to log user click-streams. This is possible
-because the logging module now allows <a
-href="../multilogs.html">multiple log files</a>. The cookie itself is
-logged by using the text <tt>%{cookie}n </tt>
+because the logging module now allows <A
+HREF="../multilogs.html">multiple log files</A>. The cookie itself is
+logged by using the text <TT>%{cookie}n </TT>
 
 in the log file format. For example:
-<pre>
+<PRE>
 CustomLog logs/clickstream "%{cookie}n %r %t"
-</pre>
+</PRE>
 
 For backward compatibility the configurable log module implements the
-old <tt>CookieLog</tt> directive, but this should be upgraded to the
-above <tt>CustomLog</tt> directive.
+old <TT>CookieLog</TT> directive, but this should be upgraded to the
+above <TT>CustomLog</TT> directive.
 
 <h2>Directives</h2>
 
-<ul>
-<li><a href="#cookieexpires">CookieExpires</a>
-<li><a href="#cookietracking">CookieTracking</a>
-</ul>
+<UL>
+<LI><A HREF="#cookieexpires">CookieExpires</A>
+<LI><A HREF="#cookietracking">CookieTracking</A>
+</UL>
 
-<hr>
+<HR>
 
-<h2><a name="cookieexpires">CookieExpires</A></h2>
-<strong>Syntax:</strong> CookieExpires <em>expiry-period</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> optional<br>
-<strong>Module:</strong> mod_usertrack<p>
+<h2><A name="cookieexpires">CookieExpires</A></h2>
+<STRONG>Syntax:</STRONG> CookieExpires <EM>expiry-period</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> optional<BR>
+<STRONG>Module:</STRONG> mod_usertrack<P>
 
 When used, this directive sets an expiry time on the cookie generated
-by the usertrack module. The <i>expiry-period</i> can be given either
+by the usertrack module. The <EM>expiry-period</EM> can be given either
 as a number of seconds, or in the format such as "2 weeks 3 days 7
 hours".  Valid denominations are: years, months, weeks, hours, minutes
 and seconds.  If the expiry time is in any format other than one
 number indicating the number of seconds, it must be enclosed by
 double quotes.
 
-<p>If this directive is not used, cookies last only for the current
-browser session.</p>
+<P>If this directive is not used, cookies last only for the current
+browser session.</P>
 
-<h2><a name="cookietracking">CookieTracking</A></h2>
-<strong>Syntax:</strong> CookieTracking <em>on | off</em><br>
-<strong>Context:</strong> server config, virtual host, directory,
-.htaccess<br>
-<strong>Override:</strong> FileInfo<br>
-<strong>Status:</strong> optional<br>
-<strong>Module:</strong> mod_usertrack<p>
+<h2><A name="cookietracking">CookieTracking</A></h2>
+<STRONG>Syntax:</STRONG> CookieTracking <EM>on | off</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host, directory,
+.htaccess<BR>
+<STRONG>Override:</STRONG> FileInfo<BR>
+<STRONG>Status:</STRONG> optional<BR>
+<STRONG>Module:</STRONG> mod_usertrack<P>
 
 When the user track module is compiled in, and "CookieTracking on" is
 set, Apache will start sending a user-tracking cookie for all new
index 01ea158da61d5e4b5c313d8d09ed755d9f86379e..96536c266e429b9defae1d58e79e74400f9ecdb6 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Running a High-Performance Web Server for BSD</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Running a High-Performance Web Server for BSD</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
 </A>
 <H1 ALIGN="CENTER">Running a High-Performance Web Server for BSD</H1>
 
-Like other OS's, the listen queue is often the <b>first limit hit</b>.  The
+Like other OS's, the listen queue is often the <STRONG>first limit hit</STRONG>.  The
 following are comments from "Aaron Gifford &lt;agifford@InfoWest.COM&gt;"
 on how to fix this on BSDI 1.x, 2.x,  and FreeBSD 2.0 (and earlier):
 
-<p>
+<P>
 
 Edit the following two files:
-<blockquote><code>  /usr/include/sys/socket.h <br>
-  /usr/src/sys/sys/socket.h </code></blockquote>
+<BLOCKQUOTE><CODE>  /usr/include/sys/socket.h <BR>
+  /usr/src/sys/sys/socket.h </CODE></BLOCKQUOTE>
 In each file, look for the following:
-<pre>
+<PRE>
     /*
      * Maximum queue length specifiable by listen.
      */
     #define SOMAXCONN       5
-</pre>
+</PRE>
 
 Just change the "5" to whatever appears to work.  I bumped the two
 machines I was having problems with up to 32 and haven't noticed the
 problem since.
 
-<p>
+<P>
 
 After the edit, recompile the kernel and recompile the Apache server
 then reboot.
@@ -48,27 +48,27 @@ then reboot.
 FreeBSD 2.1 seems to be perfectly happy, with SOMAXCONN
 set to 32 already.
 
-<p>
+<P>
 
 <A NAME="detail">
-<b>Addendum for <i>very</i> heavily loaded BSD servers</b><br>
+<STRONG>Addendum for <EM>very</EM> heavily loaded BSD servers</STRONG><BR>
 </A>
 from Chuck Murcko &lt;chuck@telebase.com&gt;
 
-<p>
+<P>
 
 If you're running a really busy BSD Apache server, the following are useful
-things to do if the system is acting sluggish:<p>
+things to do if the system is acting sluggish:<P>
 
-<ul>
+<UL>
 
-<li> Run vmstat to check memory usage, page/swap rates, etc.
+<LI> Run vmstat to check memory usage, page/swap rates, etc.
 
-<li> Run netstat -m to check mbuf usage
+<LI> Run netstat -m to check mbuf usage
 
-<li> Run fstat to check file descriptor usage
+<LI> Run fstat to check file descriptor usage
 
-</ul>
+</UL>
 
 These utilities give you an idea what you'll need to tune in your kernel,
 and whether it'll help to buy more RAM.
@@ -78,36 +78,36 @@ FreeBSD and other 4.4-lite derivatives) from a system getting heavy usage.
 The tools mentioned above were used, and the system memory was increased to
 48 MB before these tuneups. Other system parameters remained unchanged.
 
-<p>
+<P>
 
-<pre>
+<PRE>
 maxusers        256
-</pre>
+</PRE>
 
-Maxusers drives a <i>lot</i> of other kernel parameters:
+Maxusers drives a <EM>lot</EM> of other kernel parameters:
 
-<ul>
+<UL>
 
-<li> Maximum # of processes
+<LI> Maximum # of processes
 
-<li> Maximum # of processes per user
+<LI> Maximum # of processes per user
 
-<li> System wide open files limit
+<LI> System wide open files limit
 
-<li> Per-process open files limit
+<LI> Per-process open files limit
 
-<li> Maximum # of mbuf clusters
+<LI> Maximum # of mbuf clusters
 
-<li> Proc/pgrp hash table size
+<LI> Proc/pgrp hash table size
 
-</ul>
+</UL>
 
 The actual formulae for these derived parameters are in
-<i>/usr/src/sys/conf/param.c</i>.
+<EM>/usr/src/sys/conf/param.c</EM>.
 These calculated parameters can also be overridden (in part) by specifying
 your own values in the kernel configuration file:
 
-<pre>
+<PRE>
 # Network options. NMBCLUSTERS defines the number of mbuf clusters and
 # defaults to 256. This machine is a server that handles lots of traffic,
 # so we crank that value.
@@ -119,13 +119,13 @@ options         NMBCLUSTERS=4096        # mbuf clusters at 4096
 #
 options         CHILD_MAX=512           # maximum number of child processes
 options         OPEN_MAX=512            # maximum fds (breaks RPC svcs)
-</pre>
+</PRE>
 
 SOMAXCONN is not derived from maxusers, so you'll always need to increase
 that yourself. We used a value guaranteed to be larger than Apache's
 default for the listen() of 128, currently.
 
-<p>
+<P>
 
 In many cases, NMBCLUSTERS must be set much larger than would appear
 necessary at first glance. The reason for this is that if the browser
@@ -137,10 +137,10 @@ this state doesn't time out on the server, and the browser never sent
 a final FIN.  For more details see the
 <A HREF="fin_wait_2.html">FIN_WAIT_2</A> page.
 
-<p>
+<P>
 
 Some more info on mbuf clusters (from sys/mbuf.h):
-<pre>
+<PRE>
 /*
  * Mbufs are of a single size, MSIZE (machine/machparam.h), which
  * includes overhead.  An mbuf may add a single "mbuf cluster" of size
@@ -148,9 +148,9 @@ Some more info on mbuf clusters (from sys/mbuf.h):
  * and is used instead of the internal data area; this is done when
  * at least MINCLSIZE of data must be stored.
  */
-</pre>
+</PRE>
 
-<p>
+<P>
 
 CHILD_MAX and OPEN_MAX are set to allow up to 512 child processes (different
 than the maximum value for processes per user ID) and file descriptors.
@@ -160,19 +160,19 @@ files). If you've got a lot of other activity besides httpd on the same
 machine, you'll have to set NPROC higher still. In this example, the NPROC
 value derived from maxusers proved sufficient for our load.
 
-<p>
+<P>
 
-<b>Caveats</b>
+<STRONG>Caveats</STRONG>
 
-<p>
+<P>
 
 Be aware that your system may not boot with a kernel that is configured
-to use more resources than you have available system RAM. <b>ALWAYS</b>
+to use more resources than you have available system RAM. <STRONG>ALWAYS</STRONG>
 have a known bootable kernel available when tuning your system this way,
 and use the system tools beforehand to learn if you need to buy more
 memory before tuning.
 
-<p>
+<P>
 
 RPC services will fail when the value of OPEN_MAX is larger than 256.
 This is a function of the original implementations of the RPC library,
@@ -180,21 +180,21 @@ which used a byte value for holding file descriptors. BSDI has partially
 addressed this limit in its 2.1 release, but a real fix may well await
 the redesign of RPC itself.
 
-<p>
+<P>
 
 Finally, there's the hard limit of child processes configured in Apache.
 
-<p>
+<P>
 
 For versions of Apache later than 1.0.5 you'll need to change the
-definition for <b>HARD_SERVER_LIMIT</b> in <i>httpd.h</i> and recompile
+definition for <STRONG>HARD_SERVER_LIMIT</STRONG> in <EM>httpd.h</EM> and recompile
 if you need to run more than the default 150 instances of httpd.
 
-<p>
+<P>
 
 From conf/httpd.conf-dist:
 
-<pre>
+<PRE>
 # Limit on total number of servers running, i.e., limit on the number
 # of clients who can simultaneously connect --- if this limit is ever
 # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW.
@@ -202,35 +202,35 @@ From conf/httpd.conf-dist:
 # Unix with it as it spirals down...
 
 MaxClients 150
-</pre>
+</PRE>
 
 Know what you're doing if you bump this value up, and make sure you've
 done your system monitoring, RAM expansion, and kernel tuning beforehand.
 Then you're ready to service some serious hits!
 
-<p>
+<P>
 
-Thanks to <i>Tony Sanders</i> and <i>Chris Torek</i> at BSDI for their
+Thanks to <EM>Tony Sanders</EM> and <EM>Chris Torek</EM> at BSDI for their
 helpful suggestions and information.
 
 <P>
 
 "M. Teterin" &lt;mi@ALDAN.ziplink.net&gt; writes:<P>
-<blockquote>It really does help if your kernel and frequently used utilities
+<BLOCKQUOTE>It really does help if your kernel and frequently used utilities
 are fully optimized. Rebuilding the FreeBSD kernel on an AMD-133
 (486-class CPU) web-server with<BR>
-<code>    -m486 -fexpensive-optimizations -fomit-frame-pointer -O2</code><BR>
+<CODE>    -m486 -fexpensive-optimizations -fomit-frame-pointer -O2</CODE><BR>
 helped reduce the number of "unable" errors, because the CPU was
-often maxed out.</blockquote>
+often maxed out.</BLOCKQUOTE>
 <P>
 
 <HR>
 
 <H3>More welcome!</H3>
 
-If you have tips to contribute, send mail to <a
-href="mailto:brian@organic.com">brian@organic.com</a>
+If you have tips to contribute, send mail to <A
+HREF="mailto:brian@organic.com">brian@organic.com</A>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
 
index 8b5b94026452971a0e1a217308ca9efe2f63f052..67eed58ff144851dfc95f596a0f866df15cd51cf 100644 (file)
@@ -32,10 +32,10 @@ Date: Fri, 28 Jun 96 16:07:56 MDT<BR>
         mechanism.
 
 <LI>Patch ID OSF350-146 has been superseded by
-<blockquote>
+<BLOCKQUOTE>
                 Patch ID OSF350-195 for V3.2C<BR>
                 Patch ID OSF360-350195 for V3.2D
-</blockquote>
+</BLOCKQUOTE>
         Patch IDs for V3.2E and V3.2F should be available soon.
         There is no known reason why the Patch ID OSF360-350195
         won't work on these releases, but such use is not officially
index 23ab1c250a58008ea4e7ca6dde0e88107993b126..606b08151ccfad8f19be5d93cd15cfb8041df147 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Running a High-Performance Web Server on HPUX</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Running a High-Performance Web Server on HPUX</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
@@ -73,7 +73,7 @@ ftp://ftp.cup.hp.com/dist/networking/misc/listenq</A>.
 
 If folks are running Apache on a PA-8000 based system, they should
 consider "chatr'ing" the Apache executable to have a large page size.
-This would be "chatr +pi L <binary>." The GID of the running executable
+This would be "chatr +pi L <BINARY>." The GID of the running executable
 must have MLOCK privileges. Setprivgrp(1m) should be consulted for
 assigning MLOCK. The change can be validated by running Glance and
 examining the memory regions of the server(s) to make sure that they
@@ -120,5 +120,5 @@ http://www.cup.hp.com/netperf/NetperfPage.html</A>
 <A HREF="./"><IMG SRC="../images/index.gif" ALT="Index"></A>
 <A HREF="../"><IMG SRC="../images/home.gif" ALT="Home"></A>
 
-</body></html>
+</BODY></HTML>
 
index f0af157c0686c9371f6a3996214fa6615f2e4521..b0188b50d159c5cf6e7287c95dfd17cda1875a99 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Hints on Running a High-Performance Web Server</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Hints on Running a High-Performance Web Server</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
@@ -39,7 +39,7 @@ A/UX (Apple's UNIX)
 </A></H3>
 
 If you are running Apache on A/UX, a page that gives some helpful
-performance hints (concerning the <I>listen()</I> queue and using
+performance hints (concerning the <EM>listen()</EM> queue and using
 virtual hosts)
 <A HREF="http://www.jaguNET.com/apache.html">can be found here</A>
 
@@ -78,9 +78,9 @@ where the whole server will appear to freeze for a couple of minutes
 at a time, and then come back to life.  This has been traced to a
 listen() queue overload - certain Linux implementations have a low
 value set for the incoming connection queue which can cause problems.
-Please see our <a
-href="http://www.qosina.com/~awm/apache/linux-tcp.html">Using Apache on
-Linux</a> page for more info on how to fix this.
+Please see our <A
+HREF="http://www.qosina.com/~awm/apache/linux-tcp.html">Using Apache on
+Linux</A> page for more info on how to fix this.
 
 <P><HR>
 
@@ -100,9 +100,9 @@ Other links:
 
 <UL>
 
-<LI><A href="http://www.sun.com/sun-on-net/performance.html">
+<LI><A HREF="http://www.sun.com/sun-on-net/performance.html">
 World Wide Web Server Performance,
-&lt;http://www.sun.com/sun-on-net/performance.html&gt;</a>
+&lt;http://www.sun.com/sun-on-net/performance.html&gt;</A>
 <LI><A HREF="http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html">
 Solaris 2.x - tuning your TCP/IP stack</A> contains some good technical
 information about tuning various Solaris TCP/IP parameters.
@@ -122,9 +122,9 @@ http://www.islandnet.com/~mark/somaxconn.html</A>.
 
 <H3>More welcome!</H3>
 
-If you have tips to contribute, send mail to <a
-href="mailto:brian@organic.com">brian@organic.com</a>
+If you have tips to contribute, send mail to <A
+HREF="mailto:brian@organic.com">brian@organic.com</A>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
 
index eb8adbe2fe8338e99298eb3aa7fbcf164659b0fa..458104a9d0d9545d0bb95d7fb6d92156740a3c26 100644 (file)
@@ -23,16 +23,16 @@ bind errors, and accept errors, to name a few.
 <H2>UnixWare 1.x</H2>
 
 Make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not
-defined by Apache autoconfiguration). If using the UnixWare <i>cc</i>
+defined by Apache autoconfiguration). If using the UnixWare <EM>cc</EM>
 compiler, and you still see accept() errors, don't use compiler optimization,
-or get <i>gcc</i>.
+or get <EM>gcc</EM>.
 
 <H2>UnixWare 2.0.x</H2>
 
-SCO patch <a href="ftp://ftp.sco.com/UW20/tf2163.txt">tf2163</a> is required
+SCO patch <A HREF="ftp://ftp.sco.com/UW20/tf2163.txt">tf2163</A> is required
 in order for Apache to work correctly on UnixWare 2.0.x. See
-<a href="http://www.sco.com">http://www.sco.com</a>
-for UnixWare patch information.<p>
+<A HREF="http://www.sco.com">http://www.sco.com</A>
+for UnixWare patch information.<P>
 
 In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not
 defined by Apache autoconfiguration). To reduce instances of connections
@@ -41,20 +41,20 @@ only).
 
 <H2>UnixWare 2.1.x</H2>
 
-SCO patch <a href="ftp://ftp.sco.com/UW21/ptf3123b.txt">ptf3123</a> is required
+SCO patch <A HREF="ftp://ftp.sco.com/UW21/ptf3123b.txt">ptf3123</A> is required
 in order for Apache to work correctly on UnixWare 2.1.x. See
-<a href="http://www.sco.com">http://www.sco.com</a>
-for UnixWare patch information.<p>
+<A HREF="http://www.sco.com">http://www.sco.com</A>
+for UnixWare patch information.<P>
 
-<b>NOTE:</b> Unixware 2.1.2 and later already have patch ptf3123 included<p>
+<STRONG>NOTE:</STRONG> Unixware 2.1.2 and later already have patch ptf3123 included<P>
 
 In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not
 defined by Apache autoconfiguration). To reduce instances of connections
 in FIN_WAIT_2 state, you may also want to define NO_LINGCLOSE (Apache 1.2
-only).<p>
+only).<P>
 
 Thanks to Joe Doupnik &lt;JRD@cc.usu.edu&gt; and Rich Vaughn
-&lt;rvaughn@aad.com&gt; for additional info for UnixWare builds.<p>
+&lt;rvaughn@aad.com&gt; for additional info for UnixWare builds.<P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 1f1758d92df67660ef8ed8514eaf656daa1f375f..19a06c0cd5f1dc5aeecdb6c75be51f4dbab187a7 100644 (file)
 
 <H1 ALIGN="CENTER">Using Apache With Microsoft Windows</H1>
 
-<p>This document explains how to compile, install, configure and run
+<P>This document explains how to compile, install, configure and run
    Apache 1.3b3 (or later) under Microsoft Windows. Please note that at
    this time, Windows support is entirely experimental, and is
    recommended only for experienced users. The Apache Group does not
    guarantee that this software will work as documented, or even at
    all. If you find any bugs, or wish to contribute in other ways, please
-   use our <a href="http://www.apache.org/bug_report.html">bug reporting
-   page.</a></p>
+   use our <A HREF="http://www.apache.org/bug_report.html">bug reporting
+   page.</A></P>
 
-<p><b>Warning: Apache on NT has not yet been optimized for performance.
+<P><STRONG>Warning: Apache on NT has not yet been optimized for performance.
 Apache still performs best, and is most reliable on Unix platforms.  Over
 time we will improve NT performance. Folks doing comparative reviews
 of webserver performance are asked to compare against Apache
-on a Unix platform such as Solaris, FreeBSD, or Linux.</b></p>
+on a Unix platform such as Solaris, FreeBSD, or Linux.</STRONG></P>
 
-<hr>
+<HR>
 
-<ul>
-  <li><a href="#req">Requirements</a>
-  <li><a href="#down">Downloading Apache for Windows</a>
-  <li><a href="#comp">Compiling Apache for Windows</a>
-  <li><a href="#inst">Installing Apache for Windows</a>
-  <li><a href="#use">Using Apache for Windows</a>
-</ul>
+<UL>
+  <LI><A HREF="#req">Requirements</A>
+  <LI><A HREF="#down">Downloading Apache for Windows</A>
+  <LI><A HREF="#comp">Compiling Apache for Windows</A>
+  <LI><A HREF="#inst">Installing Apache for Windows</A>
+  <LI><A HREF="#use">Using Apache for Windows</A>
+</UL>
 
-<hr>
+<HR>
 
-<h2><a name="req">Requirements</a></h2>
+<h2><A name="req">Requirements</A></h2>
 
-<p>Apache 1.3b3 requires the following:</p>
+<P>Apache 1.3b3 requires the following:</P>
 
-<ul>
-  <li>Microsoft Windows NT 4.0<a href="#351">*</a>, or Windows 95.
-  <li>An Intel-based PC-compatible capable of running above OS (exact
+<UL>
+  <LI>Microsoft Windows NT 4.0<A HREF="#351">*</A>, or Windows 95.
+  <LI>An Intel-based PC-compatible capable of running above OS (exact
       requirements unknown) with a connection to a TCP/IP network.
-  <li>Microsoft Visual C++ 5.0 or later.
-</ul>
+  <LI>Microsoft Visual C++ 5.0 or later.
+</UL>
 
-<p><small><a name="351">*</a> Apache may run with Windows NT 3.5.1, but
-   has not been tested.</small></p>
+<P><SMALL><A name="351">*</A> Apache may run with Windows NT 3.5.1, but
+   has not been tested.</SMALL></P>
 
-<p>This documentation assumes good working knowledge of Microsoft
+<P>This documentation assumes good working knowledge of Microsoft
    Windows, Microsoft Visual C++, and the Apache web server (for
-   Unix).</p>
+   Unix).</P>
 
-<H2><a name="down">Downloading Apache for Windows</a></H2>
+<H2><A name="down">Downloading Apache for Windows</A></H2>
 
-<p>Information on the latest version of Apache can be found on the Apache
+<P>Information on the latest version of Apache can be found on the Apache
 web server at <A
 HREF="http://www.apache.org/">http://www.apache.org/</A>.  This will
 list the current release, any more recent alpha or beta-test release,
-together with details of mirror web and anonymous ftp sites.</p>
+together with details of mirror web and anonymous ftp sites.</P>
 
-<p>You can download Apache 1.3b3 in two different forms: an InstallShield-based
-  <code>.exe</code> file which contains the precompiled binary, and a
-  <code>.tar.gz</code> which contains the source code (and is also the
+<P>You can download Apache 1.3b3 in two different forms: an InstallShield-based
+  <CODE>.exe</CODE> file which contains the precompiled binary, and a
+  <CODE>.tar.gz</CODE> which contains the source code (and is also the
   regular Unix distribution). 
 
-<h2><a name="comp">Compiling Apache for Windows</a></h2>
+<h2><A name="comp">Compiling Apache for Windows</A></h2>
 
-<p>Compiling Apache requires Microsoft Visual C++ 5.0 to be properly
+<P>Compiling Apache requires Microsoft Visual C++ 5.0 to be properly
    installed. It is easiest to compile with the command-line tools
    (nmake, etc...). Consult the VC++ manual to determine how to install
-   them.</p>
+   them.</P>
 
-<p>First, unpack the Apache distribution into an appropriate
+<P>First, unpack the Apache distribution into an appropriate
    directory. Open a command-line prompt, and change to the
-   <code>src</code> subdirectory of the Apache distribution.</p>
+   <CODE>src</CODE> subdirectory of the Apache distribution.</P>
 
-<p>The master Apache makefile instructions are contained in the
-   <code>Makefile.nt</code> file. To compile Apache, simply use one of
+<P>The master Apache makefile instructions are contained in the
+   <CODE>Makefile.nt</CODE> file. To compile Apache, simply use one of
    the following commands:
-<ul>
-<li><code>nmake /f Makefile.nt _apacher</code> (release build)
-<li><code>nmake /f Makefile.nt _apached</code> (debug build)
-</ul>
+<UL>
+<LI><CODE>nmake /f Makefile.nt _apacher</CODE> (release build)
+<LI><CODE>nmake /f Makefile.nt _apached</CODE> (debug build)
+</UL>
 
-<p>These will both compile Apache. The latter will include debugging
+<P>These will both compile Apache. The latter will include debugging
    information in the resulting files, making it easier to find bugs and
-   track down problems.</p>
+   track down problems.</P>
 
-<p>Apache can also be compiled using VC++'s Visual Studio development
+<P>Apache can also be compiled using VC++'s Visual Studio development
    environment. Although compiling Apache in this manner is not as simple,
    it makes it possible to easily modify the Apache source, or to compile
-   Apache if the command-line tools are not installed.</p>
+   Apache if the command-line tools are not installed.</P>
 
-<p>Project files (<code>.DSP</code>) are included for each of the
+<P>Project files (<CODE>.DSP</CODE>) are included for each of the
    portions of Apache. The three projects that are necessary for
-   Apache to run are <code>Apache.dsp</code>,
-   <code>ApacheCore.dsp</code> and
-   <code>os/win32/ApacheOS.dsp</code>. The regular expression library
-   in <code>regex</code> also need to be compiled using the supplied
-   makefile. The <code>src/win32</code> subdirectory contains project
-   files for the optional modules (see below).</p>
+   Apache to run are <CODE>Apache.dsp</CODE>,
+   <CODE>ApacheCore.dsp</CODE> and
+   <CODE>os/win32/ApacheOS.dsp</CODE>. The regular expression library
+   in <CODE>regex</CODE> also need to be compiled using the supplied
+   makefile. The <CODE>src/win32</CODE> subdirectory contains project
+   files for the optional modules (see below).</P>
 
-<h2><a name="inst">Installing Apache for Windows</a></h2>
+<h2><A name="inst">Installing Apache for Windows</A></h2>
 
-<p>Once Apache has been compiled, it needs to be installed in its server
-   root directory. The hard-coded default is the <code>\Apache</code>
+<P>Once Apache has been compiled, it needs to be installed in its server
+   root directory. The hard-coded default is the <CODE>\Apache</CODE>
    directory, on the current hard drive. Another directory may be used,
-   but the files will need to be installed manually.</p>
+   but the files will need to be installed manually.</P>
 
-<p>To install the files into the </code>\Apache</code> directory
-   automatically, use one the following nmake commands (see above):</p>
-<ul>
-<li><code>nmake /f Makefile.nt installr</code> (for release build)
-<li><code>nmake /f Makefile.nt installd</code> (for debug build)
-</ul>
+<P>To install the files into the </CODE>\Apache</CODE> directory
+   automatically, use one the following nmake commands (see above):</P>
+<UL>
+<LI><CODE>nmake /f Makefile.nt installr</CODE> (for release build)
+<LI><CODE>nmake /f Makefile.nt installd</CODE> (for debug build)
+</UL>
 
-<p>This will install the following:</p>
+<P>This will install the following:</P>
 
-<ul>
-  <li><code>\Apache\Apache.exe</code> - Apache executable
-  <li><code>\Apache\ApacheCore.dll</code> - Main Apache shared library
-  <li><code>\Apache\modules\ApacheModule*.dll</code> - Optional Apache
+<UL>
+  <LI><CODE>\Apache\Apache.exe</CODE> - Apache executable
+  <LI><CODE>\Apache\ApacheCore.dll</CODE> - Main Apache shared library
+  <LI><CODE>\Apache\modules\ApacheModule*.dll</CODE> - Optional Apache
       modules (7 files)
-  <li><code>\Apache\conf</code> - Empty configuration directory
-  <li><code>\Apache\logs</code> - Empty logging directory
-</ul>
+  <LI><CODE>\Apache\conf</CODE> - Empty configuration directory
+  <LI><CODE>\Apache\logs</CODE> - Empty logging directory
+</UL>
 
-<p>If you do not have nmake, or wish to install in a different directory,
-   be sure to use a similar naming scheme.</p>
+<P>If you do not have nmake, or wish to install in a different directory,
+   be sure to use a similar naming scheme.</P>
 
-<h2><a name="use">Using Apache for Windows</a></h2>
+<h2><A name="use">Using Apache for Windows</A></h2>
 
-<p>The first step is to set up Apache's configuration files. Default
-   configuration files for Windows are located in the <code>conf</code>
+<P>The first step is to set up Apache's configuration files. Default
+   configuration files for Windows are located in the <CODE>conf</CODE>
    subdirectory in the Apache distribution, and are named
-   <code>httpd.conf-dist-win</code>, <code>access.conf-dist-win</code>
-   and <code>srm.conf-dist-win</code>. Move these into
-   <code>\Apache\conf</code>, and rename them <code>httpd.conf</code>,
-   <code>access.conf</code> and <code>srm.conf</code>, respectively.</p>
+   <CODE>httpd.conf-dist-win</CODE>, <CODE>access.conf-dist-win</CODE>
+   and <CODE>srm.conf-dist-win</CODE>. Move these into
+   <CODE>\Apache\conf</CODE>, and rename them <CODE>httpd.conf</CODE>,
+   <CODE>access.conf</CODE> and <CODE>srm.conf</CODE>, respectively.</P>
 
-<p>Configuring Apache is nearly identical to the Unix version of Apache,
-   so most of the standard <a href="./">Apache documentation</a> is
-   applicable. A few things are, however, different, or new:</p>
+<P>Configuring Apache is nearly identical to the Unix version of Apache,
+   so most of the standard <A HREF="./">Apache documentation</A> is
+   applicable. A few things are, however, different, or new:</P>
 
-<ul>
-  <li><p>Because Apache for Windows is multithreaded, it does not use a
+<UL>
+  <LI><P>Because Apache for Windows is multithreaded, it does not use a
       separate process for each request, as Apache does with
       Unix. Therefore, the "process"-management directives are different:
-      <p><a href="mod/core.html#startservers">StartServers</a> - This
+      <P><A HREF="mod/core.html#startservers">StartServers</A> - This
          tells the server how many processes to use. Unlike Unix, there
          will never be more than this number, and only one will be used
          at a time (the others will be held in reserve in case the main
          processes crashes or otherwise dies). The recommended default is
-         <code>StartServers 3</code>.
-      <p><a
-         href="mod/core.html#maxrequestsperchild">MaxRequestsPerChild</a>
+         <CODE>StartServers 3</CODE>.
+      <P><A
+         HREF="mod/core.html#maxrequestsperchild">MaxRequestsPerChild</A>
          - Like the Unix directive, this controls how many requests a
            process will serve before exiting. However, unlike Unix, a
            process serves all the requests at once, not just one, so if
            this is set, it is recommended that a very high number is
-           used. The recommended default, <code>MaxRequestsPerChild
-           0</code>, does not cause the process to ever exit.
-      <p><a href="mod/core.html#threadsperchild">ThreadsPerChild</a> -
+           used. The recommended default, <CODE>MaxRequestsPerChild
+           0</CODE>, does not cause the process to ever exit.
+      <P><A HREF="mod/core.html#threadsperchild">ThreadsPerChild</A> -
          This directive is new, and tells the server how many threads it
          should use. This is the maximum number of connections the server
          can handle at once; be sure and set this number high enough for
          your site if you get a lot of hits. The recommended default is
-         <code>ThreadsPerChild 50</code>.</p>
-  <li><p>The directives that accept filenames as arguments now must use
+         <CODE>ThreadsPerChild 50</CODE>.</P>
+  <LI><P>The directives that accept filenames as arguments now must use
       Windows filenames instead of Unix ones. However, because Apache
       uses Unix-style names internally, you must use forward slashes, not
       backslashes. Drive letters can be used; if omitted, the drive with
-      the Apache executable will be assumed.</p>
-  <li><p>Apache for Windows contains the ability to load modules at runtime,
+      the Apache executable will be assumed.</P>
+  <LI><P>Apache for Windows contains the ability to load modules at runtime,
       without recompiling the server. If Apache is compiled normally, it
       will install a number of optional modules in the
-      <code>\Apache\modules</code> directory. To activate these, or other
-      modules, the new <a href="mod/mod_dll.html#loadmodule">LoadModule</a>
+      <CODE>\Apache\modules</CODE> directory. To activate these, or other
+      modules, the new <A HREF="mod/mod_dll.html#loadmodule">LoadModule</A>
       directive must be used. For example, to active the status module,
       use the following (in addition to the status-activating directives
-      in <code>access.conf</code>):</p>
-<pre>
+      in <CODE>access.conf</CODE>):</P>
+<PRE>
     LoadModule status_module modules/ApacheModuleStatus.dll
-</pre>
-      <p>Information on <a href="mod/mod_dll.html#creating">creating module
-         DLLs</a> is also available.</p>
-  <li><p>Apache can also load ISAPI Extensions (i.e., Internet Server
+</PRE>
+      <P>Information on <A HREF="mod/mod_dll.html#creating">creating module
+         DLLs</A> is also available.</P>
+  <LI><P>Apache can also load ISAPI Extensions (i.e., Internet Server
          Applications), such as those used by Microsoft's IIS, and other
-         Windows servers. <a href="mod/mod_isapi.html">More information
-         is available.</a>
-</ul>
-
-<p>Once Apache is configured correctly, it is nearly ready to be
-run. However, we recommend you copy the <code>icons</code> and
-<code>htdocs</code> subdirectories from the Apache distribution to
-<code>\Apache</code>. The latter is especially important, as it contains
+         Windows servers. <A HREF="mod/mod_isapi.html">More information
+         is available.</A>
+</UL>
+
+<P>Once Apache is configured correctly, it is nearly ready to be
+run. However, we recommend you copy the <CODE>icons</CODE> and
+<CODE>htdocs</CODE> subdirectories from the Apache distribution to
+<CODE>\Apache</CODE>. The latter is especially important, as it contains
 the document root (what the server actually serves).
 
-<p>Apache can be executed in one of two ways, directly from the command
+<P>Apache can be executed in one of two ways, directly from the command
    line, or as a Windows NT service. To run it from the command line, use
    the following command:
-<pre>
-    C:\Apache> <b>apache -s</b>
-</pre>
-
-<p>Apache will then execute, and will remain running until it is
-   exited. To use Apache as a Windows NT service, use the following:</p>
-<pre>
-    C:\Apache> <b>apache -i</b>
-</pre>
-<p>Then open the Services control panel, and start the Apache service.</p>
-
-<p>If you installed Apache in a server root other than
-   <code>\Apache</code>, you must use the <code>-f</code> command-line
-   option to specify the httpd.conf file, or the <code>-d</code> option
-   to specify the server root.</p>
+<PRE>
+    C:\Apache> <STRONG>apache -s</STRONG>
+</PRE>
+
+<P>Apache will then execute, and will remain running until it is
+   exited. To use Apache as a Windows NT service, use the following:</P>
+<PRE>
+    C:\Apache> <STRONG>apache -i</STRONG>
+</PRE>
+<P>Then open the Services control panel, and start the Apache service.</P>
+
+<P>If you installed Apache in a server root other than
+   <CODE>\Apache</CODE>, you must use the <CODE>-f</CODE> command-line
+   option to specify the httpd.conf file, or the <CODE>-d</CODE> option
+   to specify the server root.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 9e27192fef119573d429087663b61b0ba3626bd9..74f7d4e6eb487a56004967177ab2fb8ddcbad7d0 100644 (file)
@@ -63,6 +63,6 @@ Apache uses
 </OL>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
 
 
index 6951e7cdbe5f43924b609e25e810a3b10a53ce40..b5cce17df288dfad6a337b725dbbe04662e3e145 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>How Directory, Location and Files sections work</title>
-</head>
+<HTML><HEAD>
+<TITLE>How Directory, Location and Files sections work</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">How Directory, Location and Files sections work</h1>
+<h1 ALIGN="CENTER">How Directory, Location and Files sections work</H1>
 
-The sections <a
-href="mod/core.html#directory"><code>&lt;Directory&gt;</code></a>, <a
-href="mod/core.html#location"><code>&lt;Location&gt;</code></a> and <a
-href="mod/core.html#files"><code>&lt;Files&gt;</code></a> can contain
+The sections <A
+HREF="mod/core.html#directory"><CODE>&lt;Directory&gt;</CODE></A>, <A
+HREF="mod/core.html#location"><CODE>&lt;Location&gt;</CODE></A> and <A
+HREF="mod/core.html#files"><CODE>&lt;Files&gt;</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
@@ -28,112 +28,112 @@ request URL.
 <h2>Directives allowed in the sections</h2>
 
 Everything that is syntactically allowed in
-<code>&lt;Directory&gt;</code> is also allowed in
-<code>&lt;Location&gt;</code> (except a sub-<code>&lt;Files&gt;</code>
+<CODE>&lt;Directory&gt;</CODE> is also allowed in
+<CODE>&lt;Location&gt;</CODE> (except a sub-<CODE>&lt;Files&gt;</CODE>
 section, but the code doesn't test for that, Lars has an open bug
 report on that).  Semantically however some things, and the most
 notable is AllowOverrides, make no sense in
-<code>&lt;Location&gt;</code>.  The same for
-<code>&lt;Files&gt;</code> -- syntactically everything is fine, but
+<CODE>&lt;Location&gt;</CODE>.  The same for
+<CODE>&lt;Files&gt;</CODE> -- syntactically everything is fine, but
 semantically some things are different.
 
 <h2>How the sections are merged</h2>
 
 The order of merging is:
 
-<ol>
+<OL>
 
-<li>
+<LI>
 
- <code>&lt;Directory&gt;</code> (except regular expressions) and
+ <CODE>&lt;Directory&gt;</CODE> (except regular expressions) and
  .htaccess done simultaneously (with .htaccess overriding
- <code>&lt;Directory&gt;</code>)
+ <CODE>&lt;Directory&gt;</CODE>)
 
-</li>
+</LI>
 
-<li>
- <code>&lt;DirectoryMatch&gt;</code>, and
- <code>&lt;Directory&gt;</code> with regular expressions
+<LI>
+ <CODE>&lt;DirectoryMatch&gt;</CODE>, and
+ <CODE>&lt;Directory&gt;</CODE> with regular expressions
 
-</li>
+</LI>
 
- <li><code>&lt;Files&gt;</code> and <code>&lt;FilesMatch&gt;</code> done simultaneously
- </li>
+ <LI><CODE>&lt;Files&gt;</CODE> and <CODE>&lt;FilesMatch&gt;</CODE> done simultaneously
+ </LI>
 
- <li><code>&lt;Location&gt;</code> and <code>&lt;LocationMatch&gt;</code> done simultaneously
- </li>
+ <LI><CODE>&lt;Location&gt;</CODE> and <CODE>&lt;LocationMatch&gt;</CODE> done simultaneously
+ </LI>
 
-</ol>
+</OL>
 
-Apart from <code>&lt;Directory&gt;</code>, each group is processed in
+Apart from <CODE>&lt;Directory&gt;</CODE>, each group is processed in
 the order that they appear in the configuration
-files. <code>&lt;Directory&gt;</code> (group 1 above) is processed in
+files. <CODE>&lt;Directory&gt;</CODE> (group 1 above) is processed in
 the order shortest directory component to longest. If multiple
-<code>&lt;Directory&gt;</code> sections apply to the same directory
+<CODE>&lt;Directory&gt;</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>
+access.conf. Configurations included via the <CODE>Include</CODE>
 directive will be treated as if they where inside the including file
-at the location of the <code>Include</code> directive.
+at the location of the <CODE>Include</CODE> directive.
 
-<p>
+<P>
 
-Sections inside <code>&lt;VirtualHost&gt;</code> sections are applied
-<i>after</i> the corresponding sections outside the virtual host
+Sections inside <CODE>&lt;VirtualHost&gt;</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. (Note: this only works correctly from 1.2.2 and 1.3a2
 onwards. Before those releases sections inside virtual hosts were
-applied <i>before</i> the main server).
+applied <EM>before</EM> the main server).
 
 <h2>Notes about using sections</h2>
 
 The general guidelines are:
 
-<p>
+<P>
 
-<ul>
-<li>
+<UL>
+<LI>
     If you are attempting to match objects at the filesystem level
-    then you must use <code>&lt;Directory&gt;</code> and/or
-    <code>&lt;Files&gt;</code>.
-</li>
+    then you must use <CODE>&lt;Directory&gt;</CODE> and/or
+    <CODE>&lt;Files&gt;</CODE>.
+</LI>
 
-<li>
+<LI>
     If you are attempting to match objects at the URL level then you
-    must use <code>&lt;Location&gt;</code>
-</li>
-</ul>
+    must use <CODE>&lt;Location&gt;</CODE>
+</LI>
+</UL>
 
 But a notable exception is:
 
-<ul>
-<li>
-    proxy control is done via <code>&lt;Directory&gt;</code>.  This is
+<UL>
+<LI>
+    proxy control is done via <CODE>&lt;Directory&gt;</CODE>.  This is
     a legacy mistake because the proxy existed prior to
-    <code>&lt;Location&gt;</code>.  A future version of the config
+    <CODE>&lt;Location&gt;</CODE>.  A future version of the config
     language should probably switch this to
-    <code>&lt;Location&gt;</code>.
-</li>
-</ul>
+    <CODE>&lt;Location&gt;</CODE>.
+</LI>
+</UL>
 
 Note also that modifying .htaccess parsing during Location doesn't do
 anything because .htaccess parsing has already occurred.
 
-<p>
+<P>
 
 Another note:
-<p>
+<P>
 
-<ul>
-<li>
+<UL>
+<LI>
     There is actually a
-    <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
+    <CODE>&lt;Location&gt;</CODE>/<CODE>&lt;LocationMatch&gt;</CODE>
     sequence performed just before the name translation phase (where
-    <code>Aliases</code> and <code>DocumentRoots</code> are used to
+    <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>
+</LI>
+</UL>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
index 6951e7cdbe5f43924b609e25e810a3b10a53ce40..b5cce17df288dfad6a337b725dbbe04662e3e145 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>How Directory, Location and Files sections work</title>
-</head>
+<HTML><HEAD>
+<TITLE>How Directory, Location and Files sections work</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">How Directory, Location and Files sections work</h1>
+<h1 ALIGN="CENTER">How Directory, Location and Files sections work</H1>
 
-The sections <a
-href="mod/core.html#directory"><code>&lt;Directory&gt;</code></a>, <a
-href="mod/core.html#location"><code>&lt;Location&gt;</code></a> and <a
-href="mod/core.html#files"><code>&lt;Files&gt;</code></a> can contain
+The sections <A
+HREF="mod/core.html#directory"><CODE>&lt;Directory&gt;</CODE></A>, <A
+HREF="mod/core.html#location"><CODE>&lt;Location&gt;</CODE></A> and <A
+HREF="mod/core.html#files"><CODE>&lt;Files&gt;</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
@@ -28,112 +28,112 @@ request URL.
 <h2>Directives allowed in the sections</h2>
 
 Everything that is syntactically allowed in
-<code>&lt;Directory&gt;</code> is also allowed in
-<code>&lt;Location&gt;</code> (except a sub-<code>&lt;Files&gt;</code>
+<CODE>&lt;Directory&gt;</CODE> is also allowed in
+<CODE>&lt;Location&gt;</CODE> (except a sub-<CODE>&lt;Files&gt;</CODE>
 section, but the code doesn't test for that, Lars has an open bug
 report on that).  Semantically however some things, and the most
 notable is AllowOverrides, make no sense in
-<code>&lt;Location&gt;</code>.  The same for
-<code>&lt;Files&gt;</code> -- syntactically everything is fine, but
+<CODE>&lt;Location&gt;</CODE>.  The same for
+<CODE>&lt;Files&gt;</CODE> -- syntactically everything is fine, but
 semantically some things are different.
 
 <h2>How the sections are merged</h2>
 
 The order of merging is:
 
-<ol>
+<OL>
 
-<li>
+<LI>
 
- <code>&lt;Directory&gt;</code> (except regular expressions) and
+ <CODE>&lt;Directory&gt;</CODE> (except regular expressions) and
  .htaccess done simultaneously (with .htaccess overriding
- <code>&lt;Directory&gt;</code>)
+ <CODE>&lt;Directory&gt;</CODE>)
 
-</li>
+</LI>
 
-<li>
- <code>&lt;DirectoryMatch&gt;</code>, and
- <code>&lt;Directory&gt;</code> with regular expressions
+<LI>
+ <CODE>&lt;DirectoryMatch&gt;</CODE>, and
+ <CODE>&lt;Directory&gt;</CODE> with regular expressions
 
-</li>
+</LI>
 
- <li><code>&lt;Files&gt;</code> and <code>&lt;FilesMatch&gt;</code> done simultaneously
- </li>
+ <LI><CODE>&lt;Files&gt;</CODE> and <CODE>&lt;FilesMatch&gt;</CODE> done simultaneously
+ </LI>
 
- <li><code>&lt;Location&gt;</code> and <code>&lt;LocationMatch&gt;</code> done simultaneously
- </li>
+ <LI><CODE>&lt;Location&gt;</CODE> and <CODE>&lt;LocationMatch&gt;</CODE> done simultaneously
+ </LI>
 
-</ol>
+</OL>
 
-Apart from <code>&lt;Directory&gt;</code>, each group is processed in
+Apart from <CODE>&lt;Directory&gt;</CODE>, each group is processed in
 the order that they appear in the configuration
-files. <code>&lt;Directory&gt;</code> (group 1 above) is processed in
+files. <CODE>&lt;Directory&gt;</CODE> (group 1 above) is processed in
 the order shortest directory component to longest. If multiple
-<code>&lt;Directory&gt;</code> sections apply to the same directory
+<CODE>&lt;Directory&gt;</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>
+access.conf. Configurations included via the <CODE>Include</CODE>
 directive will be treated as if they where inside the including file
-at the location of the <code>Include</code> directive.
+at the location of the <CODE>Include</CODE> directive.
 
-<p>
+<P>
 
-Sections inside <code>&lt;VirtualHost&gt;</code> sections are applied
-<i>after</i> the corresponding sections outside the virtual host
+Sections inside <CODE>&lt;VirtualHost&gt;</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. (Note: this only works correctly from 1.2.2 and 1.3a2
 onwards. Before those releases sections inside virtual hosts were
-applied <i>before</i> the main server).
+applied <EM>before</EM> the main server).
 
 <h2>Notes about using sections</h2>
 
 The general guidelines are:
 
-<p>
+<P>
 
-<ul>
-<li>
+<UL>
+<LI>
     If you are attempting to match objects at the filesystem level
-    then you must use <code>&lt;Directory&gt;</code> and/or
-    <code>&lt;Files&gt;</code>.
-</li>
+    then you must use <CODE>&lt;Directory&gt;</CODE> and/or
+    <CODE>&lt;Files&gt;</CODE>.
+</LI>
 
-<li>
+<LI>
     If you are attempting to match objects at the URL level then you
-    must use <code>&lt;Location&gt;</code>
-</li>
-</ul>
+    must use <CODE>&lt;Location&gt;</CODE>
+</LI>
+</UL>
 
 But a notable exception is:
 
-<ul>
-<li>
-    proxy control is done via <code>&lt;Directory&gt;</code>.  This is
+<UL>
+<LI>
+    proxy control is done via <CODE>&lt;Directory&gt;</CODE>.  This is
     a legacy mistake because the proxy existed prior to
-    <code>&lt;Location&gt;</code>.  A future version of the config
+    <CODE>&lt;Location&gt;</CODE>.  A future version of the config
     language should probably switch this to
-    <code>&lt;Location&gt;</code>.
-</li>
-</ul>
+    <CODE>&lt;Location&gt;</CODE>.
+</LI>
+</UL>
 
 Note also that modifying .htaccess parsing during Location doesn't do
 anything because .htaccess parsing has already occurred.
 
-<p>
+<P>
 
 Another note:
-<p>
+<P>
 
-<ul>
-<li>
+<UL>
+<LI>
     There is actually a
-    <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
+    <CODE>&lt;Location&gt;</CODE>/<CODE>&lt;LocationMatch&gt;</CODE>
     sequence performed just before the name translation phase (where
-    <code>Aliases</code> and <code>DocumentRoots</code> are used to
+    <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>
+</LI>
+</UL>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
index 673d81beb35099db3e75587db408b001537e92c4..d5c2e0d154a7306f0709e4e6d6628b1607030e51 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Stopping and Restarting Apache</h1>
+<h1 ALIGN="CENTER">Stopping and Restarting Apache</H1>
 
-<p>You will notice many <code>httpd</code> executables running on your system,
+<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
+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
+<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>
+<P>To send a signal to the parent you should issue a command such as:
+<BLOCKQUOTE><PRE>
     kill -TERM `cat /usr/local/apache/logs/httpd.pid`
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 You can read about its progress by issuing:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     tail -f /usr/local/apache/logs/error_log
-</pre></blockquote>
+</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.
+<A HREF="mod/core.html#serverroot">ServerRoot</A> and
+<A HREF="mod/core.html#pidfile">PidFile</A> settings.
 
 <h3>TERM Signal: stop now</h3>
 
-<p>Sending the <code>TERM</code> signal to the parent causes it to
+<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
@@ -48,67 +48,67 @@ further requests are served.
 
 <h3>HUP Signal: restart now</h3>
 
-<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
+<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>
+<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.
+set to zero when a <CODE>HUP</CODE> is sent.
 
-<p><b>Note:</b> If your configuration file has errors in it when you issue a
+<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>USR1 Signal: graceful restart</h3>
 
-<p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and
+<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and
 shouldn't be used at all.
 
-<p>The <code>USR1</code> signal causes the parent process to <i>advise</i>
+<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 <i>generation</i> of the
+replaces it with a child from the new <EM>generation</EM> of the
 configuration, which begins serving new requests immediately.
 
-<p>This code is designed to always respect the
-<a href="mod/core.html#maxclients">MaxClients</a>,
-<a href="mod/core.html#minspareservers">MinSpareServers</a>,
-and <a href="mod/core.html#maxspareservers">MaxSpareServers</a> settings.
-Furthermore, it respects <a href="mod/core.html#startservers">StartServers</a>
+<P>This code is designed to always respect the
+<A HREF="mod/core.html#maxclients">MaxClients</A>,
+<A HREF="mod/core.html#minspareservers">MinSpareServers</A>,
+and <A HREF="mod/core.html#maxspareservers">MaxSpareServers</A> settings.
+Furthermore, it respects <A HREF="mod/core.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>Users of the
-<a href="mod/mod_status.html">status module</a>
+<P>Users of the
+<A HREF="mod/mod_status.html">status module</A>
 will notice that the server statistics
-are <b>not</b> set to zero when a <code>USR1</code> is sent.  The code
+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 <i>scoreboard</i> used to keep track
+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
+<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
+<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
+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><b>Note:</b> If your configuration file has errors in it when you issue a
+<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
@@ -124,7 +124,7 @@ error and the error should be fixed before issuing the graceful restart.
 
 <h3>Appendix: signals and race conditions</h3>
 
-<p>Prior to Apache 1.2b9 there were several <i>race conditions</i>
+<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
@@ -132,11 +132,11 @@ 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>
+<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
+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
@@ -144,13 +144,13 @@ around, but fortunately most architectures do not require a scoreboard file.
 See the ScoreBoardFile documentation for a method to determine if your
 architecture uses it.
 
-<p><code>NEXT</code> and <code>MACHTEN</code> (68k only) have small race
+<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
+<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
index 673d81beb35099db3e75587db408b001537e92c4..d5c2e0d154a7306f0709e4e6d6628b1607030e51 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Stopping and Restarting Apache</h1>
+<h1 ALIGN="CENTER">Stopping and Restarting Apache</H1>
 
-<p>You will notice many <code>httpd</code> executables running on your system,
+<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
+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
+<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>
+<P>To send a signal to the parent you should issue a command such as:
+<BLOCKQUOTE><PRE>
     kill -TERM `cat /usr/local/apache/logs/httpd.pid`
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 You can read about its progress by issuing:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     tail -f /usr/local/apache/logs/error_log
-</pre></blockquote>
+</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.
+<A HREF="mod/core.html#serverroot">ServerRoot</A> and
+<A HREF="mod/core.html#pidfile">PidFile</A> settings.
 
 <h3>TERM Signal: stop now</h3>
 
-<p>Sending the <code>TERM</code> signal to the parent causes it to
+<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
@@ -48,67 +48,67 @@ further requests are served.
 
 <h3>HUP Signal: restart now</h3>
 
-<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
+<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>
+<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.
+set to zero when a <CODE>HUP</CODE> is sent.
 
-<p><b>Note:</b> If your configuration file has errors in it when you issue a
+<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>USR1 Signal: graceful restart</h3>
 
-<p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and
+<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and
 shouldn't be used at all.
 
-<p>The <code>USR1</code> signal causes the parent process to <i>advise</i>
+<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 <i>generation</i> of the
+replaces it with a child from the new <EM>generation</EM> of the
 configuration, which begins serving new requests immediately.
 
-<p>This code is designed to always respect the
-<a href="mod/core.html#maxclients">MaxClients</a>,
-<a href="mod/core.html#minspareservers">MinSpareServers</a>,
-and <a href="mod/core.html#maxspareservers">MaxSpareServers</a> settings.
-Furthermore, it respects <a href="mod/core.html#startservers">StartServers</a>
+<P>This code is designed to always respect the
+<A HREF="mod/core.html#maxclients">MaxClients</A>,
+<A HREF="mod/core.html#minspareservers">MinSpareServers</A>,
+and <A HREF="mod/core.html#maxspareservers">MaxSpareServers</A> settings.
+Furthermore, it respects <A HREF="mod/core.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>Users of the
-<a href="mod/mod_status.html">status module</a>
+<P>Users of the
+<A HREF="mod/mod_status.html">status module</A>
 will notice that the server statistics
-are <b>not</b> set to zero when a <code>USR1</code> is sent.  The code
+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 <i>scoreboard</i> used to keep track
+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
+<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
+<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
+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><b>Note:</b> If your configuration file has errors in it when you issue a
+<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
@@ -124,7 +124,7 @@ error and the error should be fixed before issuing the graceful restart.
 
 <h3>Appendix: signals and race conditions</h3>
 
-<p>Prior to Apache 1.2b9 there were several <i>race conditions</i>
+<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
@@ -132,11 +132,11 @@ 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>
+<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
+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
@@ -144,13 +144,13 @@ around, but fortunately most architectures do not require a scoreboard file.
 See the ScoreBoardFile documentation for a method to determine if your
 architecture uses it.
 
-<p><code>NEXT</code> and <code>MACHTEN</code> (68k only) have small race
+<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
+<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
index 90af9ad1176df31ebd835bb83446363863e05dda..51df1dd5ff3e13e917807a449a11c324051de641 100644 (file)
@@ -268,11 +268,11 @@ suEXEC binary in its proper location, and configure Apache for use with suEXEC.
 <P ALIGN="LEFT">
 <STRONG>EDITING THE SUEXEC HEADER FILE</STRONG><BR>
 - From the top-level of the Apache source tree, type:&nbsp;&nbsp;
-<STRONG><code>cd support [ENTER]</code></STRONG>
+<STRONG><CODE>cd support [ENTER]</CODE></STRONG>
 </P>
 
 <P ALIGN="LEFT">
-Edit the <code>suexec.h</code> file and change the following macros to
+Edit the <CODE>suexec.h</CODE> file and change the following macros to
 match your local Apache installation.
 </P>
 
@@ -347,7 +347,7 @@ match your local Apache installation.
 <STRONG>COMPILING THE SUEXEC WRAPPER</STRONG><BR>
 You now need to compile the suEXEC wrapper.  At the shell command prompt,
 type:&nbsp;&nbsp;<STRONG><CODE>cc suexec.c -o suexec [ENTER]</CODE></STRONG>.
-This should create the <STRONG><em>suexec</em></STRONG> wrapper executable.
+This should create the <STRONG><EM>suexec</EM></STRONG> wrapper executable.
 </P>
 
 <P ALIGN="LEFT">
@@ -373,7 +373,7 @@ info on this process.
 
 <P ALIGN="LEFT">
 <STRONG>COPYING THE SUEXEC BINARY TO ITS PROPER LOCATION</STRONG><BR>
-Copy the <STRONG><em>suexec</em></STRONG> executable created in the
+Copy the <STRONG><EM>suexec</EM></STRONG> executable created in the
 exercise above to the defined location for <STRONG>SUEXEC_BIN</STRONG>.
 </P>
 
@@ -383,8 +383,8 @@ exercise above to the defined location for <STRONG>SUEXEC_BIN</STRONG>.
 
 <P ALIGN="LEFT">
 In order for the wrapper to set the user ID, it must me installed as owner
-<STRONG><em>root</em></STRONG> and must have the setuserid execution bit
-set for file modes.  If you are not running a <STRONG><em>root</em></STRONG>
+<STRONG><EM>root</EM></STRONG> and must have the setuserid execution bit
+set for file modes.  If you are not running a <STRONG><EM>root</EM></STRONG>
 user shell, do so now and execute the following commands.
 </P>
 
@@ -420,16 +420,16 @@ your installation and try again.
 
 <P ALIGN="LEFT">
 One way to use <STRONG>suEXEC</STRONG> is through the
-<a href="mod/core.html#user"><STRONG>User</STRONG></a> and
-<a href="mod/core.html#group"><STRONG>Group</STRONG></a> directives in
-<a href="mod/core.html#virtualhost"><STRONG>VirtualHost</STRONG></a>
+<A HREF="mod/core.html#user"><STRONG>User</STRONG></A> and
+<A HREF="mod/core.html#group"><STRONG>Group</STRONG></A> directives in
+<A HREF="mod/core.html#virtualhost"><STRONG>VirtualHost</STRONG></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 <STRONG>User</STRONG> and <STRONG>Group</STRONG> defined for that
 <STRONG>&lt;VirtualHost&gt;</STRONG>. If only one or
 neither of these directives are specified for a
 <STRONG>&lt;VirtualHost&gt;</STRONG> then the main
-server userid is assumed.<p>
+server userid is assumed.<P>
 
 <STRONG>suEXEC</STRONG> can also be used to to execute CGI programs as
 the user to which the request is being directed. This is accomplished by
@@ -437,7 +437,7 @@ using the <STRONG>~</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.
+scrutiny of the <A HREF="#model">security checks</A> above.
 
 <P ALIGN="CENTER">
 <STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
@@ -446,7 +446,7 @@ scrutiny of the <a href="#model">security checks</a> above.
 <H3><A NAME="debug">Debugging suEXEC</A></H3>
 <P ALIGN="LEFT">
 The suEXEC wrapper will write log information to the location defined in
-the <code>suexec.h</code> as indicated above. If you feel you have
+the <CODE>suexec.h</CODE> 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>
index 90af9ad1176df31ebd835bb83446363863e05dda..51df1dd5ff3e13e917807a449a11c324051de641 100644 (file)
@@ -268,11 +268,11 @@ suEXEC binary in its proper location, and configure Apache for use with suEXEC.
 <P ALIGN="LEFT">
 <STRONG>EDITING THE SUEXEC HEADER FILE</STRONG><BR>
 - From the top-level of the Apache source tree, type:&nbsp;&nbsp;
-<STRONG><code>cd support [ENTER]</code></STRONG>
+<STRONG><CODE>cd support [ENTER]</CODE></STRONG>
 </P>
 
 <P ALIGN="LEFT">
-Edit the <code>suexec.h</code> file and change the following macros to
+Edit the <CODE>suexec.h</CODE> file and change the following macros to
 match your local Apache installation.
 </P>
 
@@ -347,7 +347,7 @@ match your local Apache installation.
 <STRONG>COMPILING THE SUEXEC WRAPPER</STRONG><BR>
 You now need to compile the suEXEC wrapper.  At the shell command prompt,
 type:&nbsp;&nbsp;<STRONG><CODE>cc suexec.c -o suexec [ENTER]</CODE></STRONG>.
-This should create the <STRONG><em>suexec</em></STRONG> wrapper executable.
+This should create the <STRONG><EM>suexec</EM></STRONG> wrapper executable.
 </P>
 
 <P ALIGN="LEFT">
@@ -373,7 +373,7 @@ info on this process.
 
 <P ALIGN="LEFT">
 <STRONG>COPYING THE SUEXEC BINARY TO ITS PROPER LOCATION</STRONG><BR>
-Copy the <STRONG><em>suexec</em></STRONG> executable created in the
+Copy the <STRONG><EM>suexec</EM></STRONG> executable created in the
 exercise above to the defined location for <STRONG>SUEXEC_BIN</STRONG>.
 </P>
 
@@ -383,8 +383,8 @@ exercise above to the defined location for <STRONG>SUEXEC_BIN</STRONG>.
 
 <P ALIGN="LEFT">
 In order for the wrapper to set the user ID, it must me installed as owner
-<STRONG><em>root</em></STRONG> and must have the setuserid execution bit
-set for file modes.  If you are not running a <STRONG><em>root</em></STRONG>
+<STRONG><EM>root</EM></STRONG> and must have the setuserid execution bit
+set for file modes.  If you are not running a <STRONG><EM>root</EM></STRONG>
 user shell, do so now and execute the following commands.
 </P>
 
@@ -420,16 +420,16 @@ your installation and try again.
 
 <P ALIGN="LEFT">
 One way to use <STRONG>suEXEC</STRONG> is through the
-<a href="mod/core.html#user"><STRONG>User</STRONG></a> and
-<a href="mod/core.html#group"><STRONG>Group</STRONG></a> directives in
-<a href="mod/core.html#virtualhost"><STRONG>VirtualHost</STRONG></a>
+<A HREF="mod/core.html#user"><STRONG>User</STRONG></A> and
+<A HREF="mod/core.html#group"><STRONG>Group</STRONG></A> directives in
+<A HREF="mod/core.html#virtualhost"><STRONG>VirtualHost</STRONG></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 <STRONG>User</STRONG> and <STRONG>Group</STRONG> defined for that
 <STRONG>&lt;VirtualHost&gt;</STRONG>. If only one or
 neither of these directives are specified for a
 <STRONG>&lt;VirtualHost&gt;</STRONG> then the main
-server userid is assumed.<p>
+server userid is assumed.<P>
 
 <STRONG>suEXEC</STRONG> can also be used to to execute CGI programs as
 the user to which the request is being directed. This is accomplished by
@@ -437,7 +437,7 @@ using the <STRONG>~</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.
+scrutiny of the <A HREF="#model">security checks</A> above.
 
 <P ALIGN="CENTER">
 <STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
@@ -446,7 +446,7 @@ scrutiny of the <a href="#model">security checks</a> above.
 <H3><A NAME="debug">Debugging suEXEC</A></H3>
 <P ALIGN="LEFT">
 The suEXEC wrapper will write log information to the location defined in
-the <code>suexec.h</code> as indicated above. If you feel you have
+the <CODE>suexec.h</CODE> 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>
index e64973edd738b4e989a6bccb7f95505789be6dae..e0792c3abaf94e049ecde627eb54bd62eb42b053 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>An In-Depth Discussion of Virtual Host Matching</title>
-</head>
+<HTML><HEAD>
+<TITLE>An In-Depth Discussion of Virtual Host Matching</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">An In-Depth Discussion of Virtual Host Matching</h1>
+<h1 ALIGN="CENTER">An In-Depth Discussion of Virtual Host Matching</H1>
 
-<p>The virtual host code was completely rewritten in <B>Apache 1.3</B>.
+<P>The virtual host code was completely rewritten in <STRONG>Apache 1.3</STRONG>.
 This document attempts to explain exactly what Apache does when
 deciding what virtual host to serve a hit from. With the help of the
 new <A HREF="../mod/core.html#namevirtualhost"><SAMP>NameVirtualHost</SAMP></A>
 directive  virtual host configuration should be a lot easier and safer
 than with versions prior to 1.3.
 
-<p>If you just want to <cite>make it work</cite> without understanding
-how, here are <a href="examples.html">some examples</a>.
+<P>If you just want to <CITE>make it work</CITE> without understanding
+how, here are <A HREF="examples.html">some examples</A>.
 
 <h3>Config File Parsing</h3>
 
-<p>There is a <EM>main_server</EM> which consists of all
+<P>There is a <EM>main_server</EM> which consists of all
 the definitions appearing outside of <CODE>&lt;VirtualHost&gt;</CODE> sections.
 There are virtual servers, called <EM>vhosts</EM>, which are defined by
 <A HREF="../mod/core.html#virtualhost"><SAMP>&lt;VirtualHost&gt;</SAMP></A>
 sections.
 
-<p>The directives
+<P>The directives
 <A HREF="../mod/core.html#port"><SAMP>Port</SAMP></A>,
 <A HREF="../mod/core.html#servername"><SAMP>ServerName</SAMP></A>,
 <A HREF="../mod/core.html#serverpath"><SAMP>ServerPath</SAMP></A>,
@@ -42,25 +42,25 @@ can appear anywhere within the definition of
 a server.  However, each appearance overrides the previous appearance
 (within that server).
 
-<p>The default value of the <code>Port</code> field for main_server
-is 80.  The main_server has no default <code>ServerPath</code>, or
-<code>ServerAlias</code>. The default <code>ServerName</code> is
+<P>The default value of the <CODE>Port</CODE> field for main_server
+is 80.  The main_server has no default <CODE>ServerPath</CODE>, or
+<CODE>ServerAlias</CODE>. The default <CODE>ServerName</CODE> is
 deduced from the servers IP address.
 
-<p>The main_server Port directive has two functions due to legacy
+<P>The main_server Port directive has two functions due to legacy
 compatibility with NCSA configuration files.  One function is
 to determine the default network port Apache will bind to.  This
 default is overridden by the existence of any
-<A HREF="../mod/core.html#listen"><code>Listen</code></A> directives.
+<A HREF="../mod/core.html#listen"><CODE>Listen</CODE></A> directives.
 The second function is to specify the port number which is used
 in absolute URIs during redirects.
 
-<p>Unlike the main_server, vhost ports <em>do not</em> affect what
+<P>Unlike the main_server, vhost ports <EM>do not</EM> affect what
 ports Apache listens for connections on.
 
-<p>Each address appearing in the <code>VirtualHost</code> directive
+<P>Each address appearing in the <CODE>VirtualHost</CODE> directive
 can have an optional port.  If the port is unspecified it defaults to
-the value of the main_server's most recent <code>Port</code> statement.
+the value of the main_server's most recent <CODE>Port</CODE> statement.
 The special port <SAMP>*</SAMP> indicates a wildcard that matches any port.
 Collectively the entire set of addresses (including multiple
 <SAMP>A</SAMP> record
@@ -70,22 +70,22 @@ results from DNS lookups) are called the vhost's <EM>address set</EM>.
 directive is used for a specific IP address the first vhost with
 that address is treated as an IP-based vhost.
 
-<P>If name-based vhosts should be used a <code>NameVirtualHost</code>
-directive <em>must</em> appear with the IP address set to be used for the
+<P>If name-based vhosts should be used a <CODE>NameVirtualHost</CODE>
+directive <EM>must</EM> appear with the IP address set to be used for the
 name-based vhosts. In other words, you must specify the IP address that
 holds the hostname aliases (CNAMEs) for your name-based vhosts via a
-<code>NameVirtualHost</code> directive in your configuration file.
+<CODE>NameVirtualHost</CODE> directive in your configuration file.
 
-<P>Multiple <code>NameVirtualHost</code> directives can be used each
-with a set of <code>VirtualHost</code> directives.
+<P>Multiple <CODE>NameVirtualHost</CODE> directives can be used each
+with a set of <CODE>VirtualHost</CODE> directives.
 
-<P>The ordering of <code>NameVirtualHost</code> and 
-<code>VirtualHost</code> directives is not important which makes the
+<P>The ordering of <CODE>NameVirtualHost</CODE> and 
+<CODE>VirtualHost</CODE> directives is not important which makes the
 following two examples identical (only the order of the
-<code>VirtualHost</code> directives for <em>one</em> address set
+<CODE>VirtualHost</CODE> directives for <EM>one</EM> address set
 is important, see below):
 
-<pre>
+<PRE>
                                 |
   NameVirtualHost 111.22.33.44  | &lt;VirtualHost 111.22.33.44&gt;
   &lt;VirtualHost 111.22.33.44&gt;    | # server A
@@ -107,58 +107,58 @@ is important, see below):
   ...                          | NameVirtualHost 111.22.33.55
   &lt;/VirtualHost&gt;         |
                                 |
-</pre>
+</PRE>
 
-<p>(To aid the readability of your configuration you should prefer the
+<P>(To aid the readability of your configuration you should prefer the
 left variant.)
 
-<p> After parsing the <code>VirtualHost</code> directive, the vhost server
-is given a default <code>Port</code> equal to the port assigned to the
-first name in its <code>VirtualHost</code> directive.
+<P> After parsing the <CODE>VirtualHost</CODE> directive, the vhost server
+is given a default <CODE>Port</CODE> equal to the port assigned to the
+first name in its <CODE>VirtualHost</CODE> directive.
 
-<p>The complete list of names in the <code>VirtualHost</code> directive
-are treated just like a <code>ServerAlias</code> (but are not overridden by any
-<code>ServerAlias</code> statement) if all names resolve to the same address set.
-Note that subsequent <code>Port</code> statements for this vhost will not affect
+<P>The complete list of names in the <CODE>VirtualHost</CODE> directive
+are treated just like a <CODE>ServerAlias</CODE> (but are not overridden by any
+<CODE>ServerAlias</CODE> statement) if all names resolve to the same address set.
+Note that subsequent <CODE>Port</CODE> statements for this vhost will not affect
 the ports assigned in the address set.
 
-<p>During initialization a list for each IP address
+<P>During initialization a list for each IP address
 is generated an inserted into an hash table. If the IP address is
-used in a <code>NameVirtualHost</code> directive the list contains
+used in a <CODE>NameVirtualHost</CODE> directive the list contains
 all name-based vhosts for the given IP address. If there are no
-vhosts defined for that address the <code>NameVirtualHost</code> directive
+vhosts defined for that address the <CODE>NameVirtualHost</CODE> directive
 is ignored and an error is logged. For an IP-based vhost the list in the
 hash table is empty.
 
-<p>Due to a fast hashing function the overhead of hashing an IP address
+<P>Due to a fast hashing function the overhead of hashing an IP address
 during a request is minimal and almost not existent. Additionally
 the table is optimized for IP addresses which vary in the last octet.
 
-<p>For every vhost various default values are set. In particular:
-
-<ol>
-<li>If a vhost has no
-    <A HREF="../mod/core.html#serveradmin"><code>ServerAdmin</code></A>,
-    <A HREF="../mod/core.html#resourceconfig"><code>ResourceConfig</code></A>,
-    <A HREF="../mod/core.html#accessconfig"><code>AccessConfig</code></A>,
-    <A HREF="../mod/core.html#timeout"><code>Timeout</code></A>,
-    <A HREF="../mod/core.html#keepalivetimeout"><code>KeepAliveTimeout</code></A>,
-    <A HREF="../mod/core.html#keepalive"><code>KeepAlive</code></A>,
-    <A HREF="../mod/core.html#maxkeepaliverequests"><code>MaxKeepAliveRequests</code></A>,
+<P>For every vhost various default values are set. In particular:
+
+<OL>
+<LI>If a vhost has no
+    <A HREF="../mod/core.html#serveradmin"><CODE>ServerAdmin</CODE></A>,
+    <A HREF="../mod/core.html#resourceconfig"><CODE>ResourceConfig</CODE></A>,
+    <A HREF="../mod/core.html#accessconfig"><CODE>AccessConfig</CODE></A>,
+    <A HREF="../mod/core.html#timeout"><CODE>Timeout</CODE></A>,
+    <A HREF="../mod/core.html#keepalivetimeout"><CODE>KeepAliveTimeout</CODE></A>,
+    <A HREF="../mod/core.html#keepalive"><CODE>KeepAlive</CODE></A>,
+    <A HREF="../mod/core.html#maxkeepaliverequests"><CODE>MaxKeepAliveRequests</CODE></A>,
     or
-    <A HREF="../mod/core.html#sendbuffersize"><code>SendBufferSize</code></A>
+    <A HREF="../mod/core.html#sendbuffersize"><CODE>SendBufferSize</CODE></A>
     directive then the respective value is
     inherited from the main_server.  (That is, inherited from whatever
     the final setting of that value is in the main_server.)
 
-<li>The &quot;lookup defaults&quot; that define the default directory
+<LI>The &quot;lookup defaults&quot; that define the default directory
     permissions
     for a vhost are merged with those of the main_server.  This includes
     any per-directory configuration information for any module.
 
-<li>The per-server configs for each module from the main_server are
+<LI>The per-server configs for each module from the main_server are
     merged into the vhost server.
-</ol>
+</OL>
 
 Essentially, the main_server is treated as &quot;defaults&quot; or a
 &quot;base&quot; on which to build each vhost.
@@ -168,33 +168,33 @@ config of the main_server has been parsed when this final merging occurs.
 So even if a main_server definition appears after a vhost definition
 it might affect the vhost definition.
 
-<p> If the main_server has no <code>ServerName</code> at this point,
+<P> If the main_server has no <CODE>ServerName</CODE> at this point,
 then the hostname of the machine that httpd is running on is used
 instead.  We will call the <EM>main_server address set</EM> those IP
-addresses returned by a DNS lookup on the <code>ServerName</code> of
+addresses returned by a DNS lookup on the <CODE>ServerName</CODE> of
 the main_server.
 
-<p> For any undefined <code>ServerName</code> fields, a name-based vhost
-defaults to the address given first in the <code>VirtualHost</code>
+<P> For any undefined <CODE>ServerName</CODE> fields, a name-based vhost
+defaults to the address given first in the <CODE>VirtualHost</CODE>
 statement defining the vhost.
 
 <P>Any vhost that includes the magic <SAMP>_default_</SAMP> wildcard
-is given the same <code>ServerName</code> as the main_server.
+is given the same <CODE>ServerName</CODE> as the main_server.
 
 
 <h3>Virtual Host Matching</h3>
 
-<p>The server determines which vhost to use for a request as follows:
+<P>The server determines which vhost to use for a request as follows:
 
 <h4>Hash table lookup</h4>
 
-<p>When the connection is first made by a client, the IP address to
+<P>When the connection is first made by a client, the IP address to
 which the client connected is looked up in the internal IP hash table.
 
 <P>If the lookup fails (the IP address wasn't found) the request is
-served from the <samp>_default_</samp> vhost if there is such a vhost
+served from the <SAMP>_default_</SAMP> vhost if there is such a vhost
 for the port to which the client sent the request. If there is no
-matching <samp>_default_</samp> vhost the request is served from the
+matching <SAMP>_default_</SAMP> vhost the request is served from the
 main_server.
 
 <P>If the lookup succeeded (a corresponding list for the IP address was
@@ -209,36 +209,36 @@ served from that vhost.
 
 <h4>Name-based vhost</h4>
 
-<p>If the entry corresponds to a name-based vhost the name list contains
+<P>If the entry corresponds to a name-based vhost the name list contains
 one or more vhost structures. This list contains the vhosts in the same
-order as the <code>VirtualHost</code> directives appear in the config
+order as the <CODE>VirtualHost</CODE> directives appear in the config
 file.
 
-<p>The first vhost on this list (the first vhost that appears after the
-corresponding <code>NameVirtualHost</code> directive in the config file)
+<P>The first vhost on this list (the first vhost that appears after the
+corresponding <CODE>NameVirtualHost</CODE> directive in the config file)
 has the highest priority and catches any request to an unknown 
-server name or a request without a <code>Host:</code> header.
+server name or a request without a <CODE>Host:</CODE> header.
 
-<p>If the client provided a <code>Host:</code> header the list is
-searched for a matching vhost and the first hit on a <code>ServerName</code>
-or <code>ServerAlias</code> is taken and the request is served from
-that vhost. A <code>Host:</code> header can contain a port number, but
+<P>If the client provided a <CODE>Host:</CODE> header the list is
+searched for a matching vhost and the first hit on a <CODE>ServerName</CODE>
+or <CODE>ServerAlias</CODE> is taken and the request is served from
+that vhost. A <CODE>Host:</CODE> header can contain a port number, but
 Apache always matches against the real port to which the client sent
 the request.
 
-<p>If the client submitted a HTTP/1.0 request without <code>Host:</code>
+<P>If the client submitted a HTTP/1.0 request without <CODE>Host:</CODE>
 header we don't know to what server the client tried to connect and
-any existing <code>ServerPath</code> is matched against the URI
+any existing <CODE>ServerPath</CODE> is matched against the URI
 from the request. The first matching path on the list is used and the
 request is served from that vhost.
 
-<p>If no matching vhost could be found the request is served from the
+<P>If no matching vhost could be found the request is served from the
 first vhost with a matching port number that is on the list for the IP
 to which the client connected (as already mentioned before).
 
 <h4>Persistent connections</h4>
-The IP lookup described above is only done <em>once</em> for a particular
-TCP/IP session while the name lookup is done on <em>every</em> request
+The IP lookup described above is only done <EM>once</EM> for a particular
+TCP/IP session while the name lookup is done on <EM>every</EM> request
 during a KeepAlive/persistent connection. In other words a client may
 request pages from different name-based vhosts during a single
 persistent connection.
@@ -246,9 +246,9 @@ persistent connection.
 
 <h4>Absolute URI</h4>
 
-<p>If the URI from the request is an absolute URI, and its hostname and
+<P>If the URI from the request is an absolute URI, and its hostname and
 port match the main server or one of the configured virtual hosts
-<em>and</em> match the address and port to which the client sent the request,
+<EM>and</EM> match the address and port to which the client sent the request,
 then the scheme/hostname/port prefix is stripped off and the remaining
 relative URI is served by the corresponding main server or virtual host.
 If it does not match, then the URI remains untouched and the request is
@@ -257,110 +257,110 @@ taken to be a proxy request.
 
 <h3>Observations</h3>
 
-<ul>
+<UL>
 
-<li>A name-based vhost can never interfere with an IP-base vhost and
+<LI>A name-based vhost can never interfere with an IP-base vhost and
     vice versa. IP-based vhosts can only be reached through an IP address
     of its own address set and never through any other address.
     The same applies to name-based vhosts, they can only be reached
     through an IP address of the corresponding address set which must
-    be defined with a <code>NameVirtualHost</code> directive.
-    <p>
+    be defined with a <CODE>NameVirtualHost</CODE> directive.
+    <P>
 
-<li><code>ServerAlias</code> and <code>ServerPath</code> checks are never
+<LI><CODE>ServerAlias</CODE> and <CODE>ServerPath</CODE> checks are never
     performed for an IP-based vhost.
-    <p>
+    <P>
     
-<li>The order of name-/IP-based, the <samp>_default_</samp>
-    vhost and the <code>NameVirtualHost</code> directive within the config
+<LI>The order of name-/IP-based, the <SAMP>_default_</SAMP>
+    vhost and the <CODE>NameVirtualHost</CODE> directive within the config
     file is not important. Only the ordering
     of name-based vhosts for a specific address set is significant. The one
     name-based vhosts that comes first in the configuration file has
     the highest priority for its corresponding address set.
-    <p>
+    <P>
 
-<li>For security reasons the port number given in a <code>Host:</code>
+<LI>For security reasons the port number given in a <CODE>Host:</CODE>
     header is never used during the matching process. Apache always
     uses the real port to which the client sent the request.
-    <p>
+    <P>
 
-<li>If a <code>ServerPath</code> directive exists which is a prefix of
-    another <code>ServerPath</code> directive that appears later in
+<LI>If a <CODE>ServerPath</CODE> directive exists which is a prefix of
+    another <CODE>ServerPath</CODE> directive that appears later in
     the configuration file, then the former will always be matched
     and the latter will never be matched.  (That is assuming that no
     Host header was available to disambiguate the two.)
-    <p>
+    <P>
 
-<li>If two IP-based vhosts have an address in common, the vhost appearing
+<LI>If two IP-based vhosts have an address in common, the vhost appearing
     first in the config file is always matched.  Such a thing might happen
     inadvertently. The server will give a warning in the error
     logfile when it detects this.
-    <p>
+    <P>
     
-<li>A <code>_default_</code> vhost catches a request only if there is no
-    other vhost with a matching IP address <em>and</em> a matching port
+<LI>A <CODE>_default_</CODE> vhost catches a request only if there is no
+    other vhost with a matching IP address <EM>and</EM> a matching port
     number for the request. The request is only caught if the port number
     to which the client sent the request matches the port number of your
-    <code>_default_</code> vhost which is your standard <code>Port</code>
+    <CODE>_default_</CODE> vhost which is your standard <CODE>Port</CODE>
     by default. A wildcard port can be specified (i.e.
-    <code>_default_:*</code>) to catch requests to any available port.
-    <p>
+    <CODE>_default_:*</CODE>) to catch requests to any available port.
+    <P>
     
-<li>The main_server is only used to serve a request if the IP address
+<LI>The main_server is only used to serve a request if the IP address
     and port number to which the client connected is unspecified
-    and does not match any other vhost (including a <code>_default_</code>
+    and does not match any other vhost (including a <CODE>_default_</CODE>
     vhost). In other words the main_server only catches a request for an
-    unspecified address/port combination (unless there is a <code>_default_</code>
+    unspecified address/port combination (unless there is a <CODE>_default_</CODE>
     vhost which matches that port).
-    <p>
+    <P>
     
-<li>A <code>_default_</code> vhost or the main_server is <em>never</em>
-    matched for a request with an unknown or missing <code>Host:</code> header
+<LI>A <CODE>_default_</CODE> vhost or the main_server is <EM>never</EM>
+    matched for a request with an unknown or missing <CODE>Host:</CODE> header
     if the client connected to an address (and port) which is used
-    for name-based vhosts, e.g. in a <code>NameVirtualHost</code> directive.
-    <p>
+    for name-based vhosts, e.g. in a <CODE>NameVirtualHost</CODE> directive.
+    <P>
     
-<li>You should never specify DNS names in <code>VirtualHost</code>
+<LI>You should never specify DNS names in <CODE>VirtualHost</CODE>
     directives because it will force your server to rely on DNS to boot.
     Furthermore it poses a security threat if you do not control the
     DNS for all the domains listed.
-    There's <a href="../dns-caveats.html">more information</a>
+    There's <A HREF="../dns-caveats.html">more information</A>
     available on this and the next two topics.
-    <p>
+    <P>
 
-<li><code>ServerName</code> should always be set for each vhost.  Otherwise
+<LI><CODE>ServerName</CODE> should always be set for each vhost.  Otherwise
     A DNS lookup is required for each vhost.
-    <p>
+    <P>
 
-</ul>
+</UL>
 
 <h3>Tips</h3>
 
-<p>In addition to the tips on the <a href="../dns-caveats.html#tips">DNS
-Issues</a> page, here are some further tips:
+<P>In addition to the tips on the <A HREF="../dns-caveats.html#tips">DNS
+Issues</A> page, here are some further tips:
 
-<ul>
+<UL>
 
-<li>Place all main_server definitions before any <code>VirtualHost</code>
+<LI>Place all main_server definitions before any <CODE>VirtualHost</CODE>
     definitions. (This is to aid the readability of the configuration --
     the post-config merging process makes it non-obvious that definitions 
     mixed in around virtual hosts might affect all virtual hosts.)
-    <p>
+    <P>
 
-<li>Group corresponding <code>NameVirtualHost</code> and
-    <code>VirtualHost</code> definitions in your configuration to ensure
+<LI>Group corresponding <CODE>NameVirtualHost</CODE> and
+    <CODE>VirtualHost</CODE> definitions in your configuration to ensure
     better readability.
-    <p>
+    <P>
 
-<li>Avoid <code>ServerPaths</code> which are prefixes of other
-    <code>ServerPaths</code>.  If you cannot avoid this then you have to
+<LI>Avoid <CODE>ServerPaths</CODE> which are prefixes of other
+    <CODE>ServerPaths</CODE>.  If you cannot avoid this then you have to
     ensure that the longer (more specific) prefix vhost appears earlier in
     the configuration file than the shorter (less specific) prefix
     (<EM>i.e.</EM>, &quot;ServerPath /abc&quot; should appear after
     &quot;ServerPath /abc/def&quot;).
-    <p>
+    <P>
 
-</ul>
+</UL>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index d2339bff81a8a514fa49c2cbfb3d10881e014bd0..b378f6859166b7e62b9f34c6384e8d8736abe497 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>An In-Depth Discussion of VirtualHost Matching</title>
-</head>
+<HTML><HEAD>
+<TITLE>An In-Depth Discussion of VirtualHost Matching</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">An In-Depth Discussion of VirtualHost Matching</h1>
+<h1 ALIGN="CENTER">An In-Depth Discussion of VirtualHost Matching</H1>
 
-<p>This is a very rough document that was probably out of date the moment
+<P>This is a very rough document that was probably out of date the moment
 it was written.  It attempts to explain exactly what the code does when
 deciding what virtual host to serve a hit from.  It's provided on the
 assumption that something is better than nothing.  The server version
 under discussion is Apache 1.2.
 
-<p>If you just want to &quot;make it work&quot; without understanding
-how, there's a <a href="#whatworks">What Works</a> section at the bottom.
+<P>If you just want to &quot;make it work&quot; without understanding
+how, there's a <A HREF="#whatworks">What Works</A> section at the bottom.
 
 <h3>Config File Parsing</h3>
 
-<p>There is a main_server which consists of all the definitions appearing
+<P>There is a main_server which consists of all the definitions appearing
 outside of <CODE>VirtualHost</CODE> sections.  There are virtual servers,
 called <EM>vhosts</EM>, which are defined by
 <A
@@ -33,7 +33,7 @@ called <EM>vhosts</EM>, which are defined by
 ><SAMP>VirtualHost</SAMP></A>
 sections.
 
-<p>The directives
+<P>The directives
 <A
  HREF="mod/core.html#port"
 ><SAMP>Port</SAMP></A>,
@@ -51,47 +51,47 @@ can appear anywhere within the definition of
 a server.  However, each appearance overrides the previous appearance
 (within that server).
 
-<p>The default value of the <code>Port</code> field for main_server
-is 80.  The main_server has no default <code>ServerName</code>,
-<code>ServerPath</code>, or <code>ServerAlias</code>.
+<P>The default value of the <CODE>Port</CODE> field for main_server
+is 80.  The main_server has no default <CODE>ServerName</CODE>,
+<CODE>ServerPath</CODE>, or <CODE>ServerAlias</CODE>.
 
-<p>In the absence of any
+<P>In the absence of any
 <A
  HREF="mod/core.html#listen"
 ><SAMP>Listen</SAMP></A>
 directives, the (final if there
-are multiple) <code>Port</code> directive in the main_server indicates
+are multiple) <CODE>Port</CODE> directive in the main_server indicates
 which port httpd will listen on.
 
-<p> The <code>Port</code> and <code>ServerName</code> directives for
+<P> The <CODE>Port</CODE> and <CODE>ServerName</CODE> directives for
 any server main or virtual are used when generating URLs such as during
 redirects.
 
-<p> Each address appearing in the <code>VirtualHost</code> directive
+<P> Each address appearing in the <CODE>VirtualHost</CODE> directive
 can have an optional port.  If the port is unspecified it defaults to
-the value of the main_server's most recent <code>Port</code> statement.
+the value of the main_server's most recent <CODE>Port</CODE> statement.
 The special port <SAMP>*</SAMP> indicates a wildcard that matches any port.
 Collectively the entire set of addresses (including multiple
 <SAMP>A</SAMP> record
 results from DNS lookups) are called the vhost's <EM>address set</EM>.
 
-<p> The magic <code>_default_</code> address has significance during
+<P> The magic <CODE>_default_</CODE> address has significance during
 the matching algorithm.  It essentially matches any unspecified address.
 
-<p> After parsing the <code>VirtualHost</code> directive, the vhost server
-is given a default <code>Port</code> equal to the port assigned to the
-first name in its <code>VirtualHost</code> directive.  The complete
-list of names in the <code>VirtualHost</code> directive are treated
-just like a <code>ServerAlias</code> (but are not overridden by any
-<code>ServerAlias</code> statement).  Note that subsequent <code>Port</code>
+<P> After parsing the <CODE>VirtualHost</CODE> directive, the vhost server
+is given a default <CODE>Port</CODE> equal to the port assigned to the
+first name in its <CODE>VirtualHost</CODE> directive.  The complete
+list of names in the <CODE>VirtualHost</CODE> directive are treated
+just like a <CODE>ServerAlias</CODE> (but are not overridden by any
+<CODE>ServerAlias</CODE> statement).  Note that subsequent <CODE>Port</CODE>
 statements for this vhost will not affect the ports assigned in the
 address set.
 
-<p>
+<P>
 All vhosts are stored in a list which is in the reverse order that
 they appeared in the config file.  For example, if the config file is:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost A&gt;
     ...
     &lt;/VirtualHost&gt;
@@ -103,53 +103,53 @@ they appeared in the config file.  For example, if the config file is:
     &lt;VirtualHost C&gt;
     ...
     &lt;/VirtualHost&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 Then the list will be ordered: main_server, C, B, A.  Keep this in mind.
 
-<p>
+<P>
 After parsing has completed, the list of servers is scanned, and various
 merges and default values are set.  In particular:
 
-<ol>
-<li>If a vhost has no
+<OL>
+<LI>If a vhost has no
     <A
      HREF="mod/core.html#serveradmin"
-    ><code>ServerAdmin</code></A>,
+    ><CODE>ServerAdmin</CODE></A>,
     <A
      HREF="mod/core.html#resourceconfig"
-    ><code>ResourceConfig</code></A>,
+    ><CODE>ResourceConfig</CODE></A>,
     <A
      HREF="mod/core.html#accessconfig"
-    ><code>AccessConfig</code></A>,
+    ><CODE>AccessConfig</CODE></A>,
     <A
      HREF="mod/core.html#timeout"
-    ><code>Timeout</code></A>,
+    ><CODE>Timeout</CODE></A>,
     <A
      HREF="mod/core.html#keepalivetimeout"
-    ><code>KeepAliveTimeout</code></A>,
+    ><CODE>KeepAliveTimeout</CODE></A>,
     <A
      HREF="mod/core.html#keepalive"
-    ><code>KeepAlive</code></A>,
+    ><CODE>KeepAlive</CODE></A>,
     <A
      HREF="mod/core.html#maxkeepaliverequests"
-    ><code>MaxKeepAliveRequests</code></A>,
+    ><CODE>MaxKeepAliveRequests</CODE></A>,
     or
     <A
      HREF="mod/core.html#sendbuffersize"
-    ><code>SendBufferSize</code></A>
+    ><CODE>SendBufferSize</CODE></A>
     directive then the respective value is
     inherited from the main_server.  (That is, inherited from whatever
     the final setting of that value is in the main_server.)
 
-<li>The &quot;lookup defaults&quot; that define the default directory
+<LI>The &quot;lookup defaults&quot; that define the default directory
     permissions
     for a vhost are merged with those of the main server.  This includes
     any per-directory configuration information for any module.
 
-<li>The per-server configs for each module from the main_server are
+<LI>The per-server configs for each module from the main_server are
     merged into the vhost server.
-</ol>
+</OL>
 
 Essentially, the main_server is treated as &quot;defaults&quot; or a
 &quot;base&quot; on
@@ -159,134 +159,134 @@ config of the main_server has been parsed when this final merging occurs.
 So even if a main_server definition appears after a vhost definition
 it might affect the vhost definition.
 
-<p> If the main_server has no <code>ServerName</code> at this point,
+<P> If the main_server has no <CODE>ServerName</CODE> at this point,
 then the hostname of the machine that httpd is running on is used
 instead.  We will call the <EM>main_server address set</EM> those IP
-addresses returned by a DNS lookup on the <code>ServerName</code> of
+addresses returned by a DNS lookup on the <CODE>ServerName</CODE> of
 the main_server.
 
-<p> Now a pass is made through the vhosts to fill in any missing
-<code>ServerName</code> fields and to classify the vhost as either
+<P> Now a pass is made through the vhosts to fill in any missing
+<CODE>ServerName</CODE> fields and to classify the vhost as either
 an <EM>IP-based</EM> vhost or a <EM>name-based</EM> vhost.  A vhost is
 considered a name-based vhost if any of its address set overlaps the
 main_server (the port associated with each address must match the
-main_server's <code>Port</code>).  Otherwise it is considered an IP-based
+main_server's <CODE>Port</CODE>).  Otherwise it is considered an IP-based
 vhost.
 
-<p> For any undefined <code>ServerName</code> fields, a name-based vhost
-defaults to the address given first in the <code>VirtualHost</code>
+<P> For any undefined <CODE>ServerName</CODE> fields, a name-based vhost
+defaults to the address given first in the <CODE>VirtualHost</CODE>
 statement defining the vhost.  Any vhost that includes the magic
-<SAMP>_default_</SAMP> wildcard is given the same <code>ServerName</code> as
+<SAMP>_default_</SAMP> wildcard is given the same <CODE>ServerName</CODE> as
 the main_server.  Otherwise the vhost (which is necessarily an IP-based
-vhost) is given a <code>ServerName</code> based on the result of a reverse
-DNS lookup on the first address given in the <code>VirtualHost</code>
+vhost) is given a <CODE>ServerName</CODE> based on the result of a reverse
+DNS lookup on the first address given in the <CODE>VirtualHost</CODE>
 statement.
 
-<p>
+<P>
 
 <h3>Vhost Matching</h3>
 
 
-<p><strong>Apache 1.3 differs from what is documented
-here, and documentation still has to be written.</strong>
+<P><STRONG>Apache 1.3 differs from what is documented
+here, and documentation still has to be written.</STRONG>
 
-<p>
+<P>
 The server determines which vhost to use for a request as follows:
 
-<p> <code>find_virtual_server</code>: When the connection is first made
+<P> <CODE>find_virtual_server</CODE>: When the connection is first made
 by the client, the local IP address (the IP address to which the client
 connected) is looked up in the server list.  A vhost is matched if it
 is an IP-based vhost, the IP address matches and the port matches
 (taking into account wildcards).
 
-<p> If no vhosts are matched then the last occurrence, if it appears,
+<P> If no vhosts are matched then the last occurrence, if it appears,
 of a <SAMP>_default_</SAMP> address (which if you recall the ordering of the
 server list mentioned above means that this would be the first occurrence
 of <SAMP>_default_</SAMP> in the config file) is matched.
 
-<p> In any event, if nothing above has matched, then the main_server is
+<P> In any event, if nothing above has matched, then the main_server is
 matched.
 
-<p> The vhost resulting from the above search is stored with data
+<P> The vhost resulting from the above search is stored with data
 about the connection.  We'll call this the <EM>connection vhost</EM>.
 The connection vhost is constant over all requests in a particular TCP/IP
 session -- that is, over all requests in a KeepAlive/persistent session.
 
-<p> For each request made on the connection the following sequence of
+<P> For each request made on the connection the following sequence of
 events further determines the actual vhost that will be used to serve
 the request.
 
-<p> <code>check_fulluri</code>: If the requestURI is an absoluteURI, that
-is it includes <code>http://hostname/</code>, then an attempt is made to
+<P> <CODE>check_fulluri</CODE>: If the requestURI is an absoluteURI, that
+is it includes <CODE>http://hostname/</CODE>, then an attempt is made to
 determine if the hostname's address (and optional port) match that of
 the connection vhost.  If it does then the hostname portion of the URI
 is saved as the <EM>request_hostname</EM>.  If it does not match, then the
 URI remains untouched.  <STRONG>Note</STRONG>: to achieve this address
 comparison,
 the hostname supplied goes through a DNS lookup unless it matches the
-<code>ServerName</code> or the local IP address of the client's socket.
+<CODE>ServerName</CODE> or the local IP address of the client's socket.
 
-<p> <code>parse_uri</code>: If the URI begins with a protocol
-(<EM>i.e.</EM>, <code>http:</code>, <code>ftp:</code>) then the request is
+<P> <CODE>parse_uri</CODE>: If the URI begins with a protocol
+(<EM>i.e.</EM>, <CODE>http:</CODE>, <CODE>ftp:</CODE>) then the request is
 considered a proxy request.  Note that even though we may have stripped
-an <code>http://hostname/</code> in the previous step, this could still
+an <CODE>http://hostname/</CODE> in the previous step, this could still
 be a proxy request.
 
-<p> <code>read_request</code>: If the request does not have a hostname
-from the earlier step, then any <code>Host:</code> header sent by the
+<P> <CODE>read_request</CODE>: If the request does not have a hostname
+from the earlier step, then any <CODE>Host:</CODE> header sent by the
 client is used as the request hostname.
 
-<p> <code>check_hostalias</code>: If the request now has a hostname,
+<P> <CODE>check_hostalias</CODE>: If the request now has a hostname,
 then an attempt is made to match for this hostname.  The first step
 of this match is to compare any port, if one was given in the request,
-against the <code>Port</code> field of the connection vhost.  If there's
+against the <CODE>Port</CODE> field of the connection vhost.  If there's
 a mismatch then the vhost used for the request is the connection vhost.
 (This is a bug, see observations.)
 
-<p>
+<P>
 If the port matches, then httpd scans the list of vhosts starting with
 the next server <STRONG>after</STRONG> the connection vhost.  This scan does not
 stop if there are any matches, it goes through all possible vhosts,
 and in the end uses the last match it found.  The comparisons performed
 are as follows:
 
-<ul>
-<li>Compare the request hostname:port with the vhost
-    <code>ServerName</code> and <code>Port</code>.
+<UL>
+<LI>Compare the request hostname:port with the vhost
+    <CODE>ServerName</CODE> and <CODE>Port</CODE>.
 
-<li>Compare the request hostname against any and all addresses given in
-    the <code>VirtualHost</code> directive for this vhost.
+<LI>Compare the request hostname against any and all addresses given in
+    the <CODE>VirtualHost</CODE> directive for this vhost.
 
-<li>Compare the request hostname against the <code>ServerAlias</code>
+<LI>Compare the request hostname against the <CODE>ServerAlias</CODE>
     given for the vhost.
-</ul>
+</UL>
 
-<p>
-<code>check_serverpath</code>: If the request has no hostname
+<P>
+<CODE>check_serverpath</CODE>: If the request has no hostname
 (back up a few paragraphs) then a scan similar to the one
-in <code>check_hostalias</code> is performed to match any
-<code>ServerPath</code> directives given in the vhosts.  Note that the
+in <CODE>check_hostalias</CODE> is performed to match any
+<CODE>ServerPath</CODE> directives given in the vhosts.  Note that the
 <STRONG>last match</STRONG> is used regardless (again consider the ordering of
 the virtual hosts).
 
 <h3>Observations</h3>
 
-<ul>
+<UL>
 
-<li>It is difficult to define an IP-based vhost for the machine's
+<LI>It is difficult to define an IP-based vhost for the machine's
     &quot;main IP address&quot;.  You essentially have to create a bogus
-    <code>ServerName</code> for the main_server that does not match the
+    <CODE>ServerName</CODE> for the main_server that does not match the
     machine's IPs.
     <P>
 
-<li>During the scans in both <code>check_hostalias</code> and
-    <code>check_serverpath</code> no check is made that the vhost being
+<LI>During the scans in both <CODE>check_hostalias</CODE> and
+    <CODE>check_serverpath</CODE> no check is made that the vhost being
     scanned is actually a name-based vhost.  This means, for example, that
     it's possible to match an IP-based vhost through another address.  But
     because the scan starts in the vhost list at the first vhost that
     matched the local IP address of the connection, not all IP-based vhosts
     can be matched.
-    <p>
+    <P>
     Consider the config file above with three vhosts A, B, C.  Suppose
     that B is a named-based vhost, and A and C are IP-based vhosts.  If
     a request comes in on B or C's address containing a header
@@ -294,102 +294,102 @@ the virtual hosts).
     it will be served from A's config.  If a request comes in on A's
     address then it will always be served from A's config regardless of
     any Host: header.
-    </p>
+    </P>
 
-<li>Unless you have a <SAMP>_default_</SAMP> vhost,
+<LI>Unless you have a <SAMP>_default_</SAMP> vhost,
     it doesn't matter if you mix name-based vhosts in amongst IP-based
-    vhosts.  During the <code>find_virtual_server</code> phase above no
+    vhosts.  During the <CODE>find_virtual_server</CODE> phase above no
     named-based vhost will be matched, so the main_server will remain the
     connection vhost.  Then scans will cover all vhosts in the vhost list.
-    <p>
+    <P>
     If you do have a <SAMP>_default_</SAMP> vhost, then you cannot place
     named-based vhosts after it in the config.  This is because on any
     connection to the main server IPs the connection vhost will always be
     the <SAMP>_default_</SAMP> vhost since none of the name-based are
-    considered during <code>find_virtual_server</code>.
-    </p>
+    considered during <CODE>find_virtual_server</CODE>.
+    </P>
 
-<li>You should never specify DNS names in <code>VirtualHost</code>
+<LI>You should never specify DNS names in <CODE>VirtualHost</CODE>
     directives because it will force your server to rely on DNS to boot.
     Furthermore it poses a security threat if you do not control the
     DNS for all the domains listed.
-    <a href="dns-caveats.html">There's more information
-    available on this and the next two topics</a>.
-    <p>
+    <A HREF="dns-caveats.html">There's more information
+    available on this and the next two topics</A>.
+    <P>
 
-<li><code>ServerName</code> should always be set for each vhost.  Otherwise
+<LI><CODE>ServerName</CODE> should always be set for each vhost.  Otherwise
     A DNS lookup is required for each vhost.
-    <p>
+    <P>
 
-<li>A DNS lookup is always required for the main_server's
-    <code>ServerName</code> (or to generate that if it isn't specified
+<LI>A DNS lookup is always required for the main_server's
+    <CODE>ServerName</CODE> (or to generate that if it isn't specified
     in the config).
-    <p>
+    <P>
 
-<li>If a <code>ServerPath</code> directive exists which is a prefix of
-    another <code>ServerPath</code> directive that appears later in
+<LI>If a <CODE>ServerPath</CODE> directive exists which is a prefix of
+    another <CODE>ServerPath</CODE> directive that appears later in
     the configuration file, then the former will always be matched
     and the latter will never be matched.  (That is assuming that no
     Host header was available to disambiguate the two.)
-    <p>
+    <P>
 
-<li>If a vhost that would otherwise be a name-vhost includes a
-    <code>Port</code> statement that doesn't match the main_server
-    <code>Port</code> then it will be considered an IP-based vhost.
-    Then <code>find_virtual_server</code> will match it (because
+<LI>If a vhost that would otherwise be a name-vhost includes a
+    <CODE>Port</CODE> statement that doesn't match the main_server
+    <CODE>Port</CODE> then it will be considered an IP-based vhost.
+    Then <CODE>find_virtual_server</CODE> will match it (because
     the ports associated with each address in the address set default
     to the port of the main_server) as the connection vhost.  Then
-    <code>check_hostalias</code> will refuse to check any other name-based
+    <CODE>check_hostalias</CODE> will refuse to check any other name-based
     vhost because of the port mismatch.  The result is that the vhost
     will steal all hits going to the main_server address.
-    <p>
+    <P>
 
-<li>If two IP-based vhosts have an address in common, the vhost appearing
+<LI>If two IP-based vhosts have an address in common, the vhost appearing
     later in the file is always matched.  Such a thing might happen
     inadvertently.  If the config has name-based vhosts and for some reason
-    the main_server <code>ServerName</code> resolves to the wrong address
+    the main_server <CODE>ServerName</CODE> resolves to the wrong address
     then all the name-based vhosts will be parsed as ip-based vhosts.
     Then the last of them will steal all the hits.
     <P>
 
-<li>The last name-based vhost in the config is always matched for any hit
+<LI>The last name-based vhost in the config is always matched for any hit
     which doesn't match one of the other name-based vhosts.
 
-</ul>
+</UL>
 
-<h3><a name="whatworks">What Works</a></h3>
+<h3><A name="whatworks">What Works</A></h3>
 
-<p>In addition to the tips on the <a href="dns-caveats.html#tips">DNS
-Issues</a> page, here are some further tips:
+<P>In addition to the tips on the <A HREF="dns-caveats.html#tips">DNS
+Issues</A> page, here are some further tips:
 
-<ul>
+<UL>
 
-<li>Place all main_server definitions before any VirtualHost definitions.
+<LI>Place all main_server definitions before any VirtualHost definitions.
 (This is to aid the readability of the configuration -- the post-config
 merging process makes it non-obvious that definitions mixed in around
 virtualhosts might affect all virtualhosts.)
-<p>
+<P>
 
-<li>Arrange your VirtualHosts such
+<LI>Arrange your VirtualHosts such
 that all name-based virtual hosts come first, followed by IP-based
 virtual hosts, followed by any <SAMP>_default_</SAMP> virtual host
-<p>
+<P>
 
-<li>Avoid <code>ServerPaths</code> which are prefixes of other
-<code>ServerPaths</code>.  If you cannot avoid this then you have to
+<LI>Avoid <CODE>ServerPaths</CODE> which are prefixes of other
+<CODE>ServerPaths</CODE>.  If you cannot avoid this then you have to
 ensure that the longer (more specific) prefix vhost appears earlier in
 the configuration file than the shorter (less specific) prefix
 (<EM>i.e.</EM>, &quot;ServerPath /abc&quot; should appear after
 &quot;ServerPath /abcdef&quot;).
-<p>
+<P>
 
-<li>Do not use <EM>port-based</EM> vhosts in the same server as
+<LI>Do not use <EM>port-based</EM> vhosts in the same server as
 name-based vhosts.  A loose definition for port-based is a vhost which
-is determined by the port on the server (<em>i.e.</em>, one server with
+is determined by the port on the server (<EM>i.e.</EM>, one server with
 ports 8000, 8080, and 80 - all of which have different configurations).
-<p>
+<P>
 
-</ul>
+</UL>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index fbf159ecaf0d29ddc49a21e07676f090c6c75706..46fdb58e5a9d85238d04ddfbc478b4c00564331d 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>VirtualHost Examples</title>
-</head>
+<HTML><HEAD>
+<TITLE>VirtualHost Examples</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Virtual Host examples for common setups</h1>
+<h1 ALIGN="CENTER">Virtual Host examples for common setups</H1>
 
 
 <h2>Base configuration</h2>
 
-<ul>
-<li><A HREF="#ip">IP-based vhosts only</A>
-<li><A HREF="#name">Name-based vhosts only</A>
-<li><A HREF="#mixed">Mixed name-/IP-based vhosts</A>
-<li><A HREF="#port">Port-based vhosts</A>
-</ul>
+<UL>
+<LI><A HREF="#ip">IP-based vhosts only</A>
+<LI><A HREF="#name">Name-based vhosts only</A>
+<LI><A HREF="#mixed">Mixed name-/IP-based vhosts</A>
+<LI><A HREF="#port">Port-based vhosts</A>
+</UL>
 
 <h2>Additional features</h2>
 
-<ul>
-<li><A HREF="#default">Using <code>_default_</code> vhosts</A>
-<li><A HREF="#migrate">Migrating a named-based vhost to an IP-based vhost</A>
-<li><A HREF="#serverpath">Using the <code>ServerPath</code> directive</A>
-</ul>
+<UL>
+<LI><A HREF="#default">Using <CODE>_default_</CODE> vhosts</A>
+<LI><A HREF="#migrate">Migrating a named-based vhost to an IP-based vhost</A>
+<LI><A HREF="#serverpath">Using the <CODE>ServerPath</CODE> directive</A>
+</UL>
 
 <HR>
 
 <h3><A NAME="ip">IP-based vhosts only</A></h3>
 
-<ul>
+<UL>
 
-<li><b>Setup 1:</b>
-    The server machine has two IP addresses (<samp>111.22.33.44</samp>
-    and <samp>111.22.33.55</samp>)
-    which resolve to the names <samp>server.domain.tld</samp> and
-    <samp>www.otherdomain.tld</samp> respectively.
-    The hostname <samp>www.domain.tld</samp> is an alias (CNAME)
-    for <samp>server.domain.tld</samp> and will represent the
+<LI><STRONG>Setup 1:</STRONG>
+    The server machine has two IP addresses (<SAMP>111.22.33.44</SAMP>
+    and <SAMP>111.22.33.55</SAMP>)
+    which resolve to the names <SAMP>server.domain.tld</SAMP> and
+    <SAMP>www.otherdomain.tld</SAMP> respectively.
+    The hostname <SAMP>www.domain.tld</SAMP> is an alias (CNAME)
+    for <SAMP>server.domain.tld</SAMP> and will represent the
     main server.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     DocumentRoot /www/domain
     ServerName www.otherdomain.tld
     ...
     &lt;/VirtualHost&gt;
-    </pre>
-    <samp>www.otherdomain.tld</samp> can only be reached through the
-    address <samp>111.22.33.55</samp>, while <samp>www.domain.tld</samp>
-    can only be reached through <samp>111.22.33.44</samp>
+    </PRE>
+    <SAMP>www.otherdomain.tld</SAMP> can only be reached through the
+    address <SAMP>111.22.33.55</SAMP>, while <SAMP>www.domain.tld</SAMP>
+    can only be reached through <SAMP>111.22.33.44</SAMP>
     (which represents our main server).
-    </blockquote>
-    <p>
+    </BLOCKQUOTE>
+    <P>
 
-<li><b>Setup 2:</b>
+<LI><STRONG>Setup 2:</STRONG>
     Same as setup 1, but we don't want to have a dedicated main server.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     ServerName server.domain.tld
     ServerName www.otherdomain.tld
     ...
     &lt;/VirtualHost&gt;
-    </pre>
+    </PRE>
     The main server can never catch a request, because all IP addresses
     of our machine are in use for IP-based virtual hosts
-    (only <samp>localhost</samp> requests can hit the main server).
-    </blockquote>
-    <p>
+    (only <SAMP>localhost</SAMP> requests can hit the main server).
+    </BLOCKQUOTE>
+    <P>
     
-<li><b>Setup 3:</b>
-    The server machine has two IP addresses (<samp>111.22.33.44</samp>
-    and <samp>111.22.33.55</samp>)
-    which resolve to the names <samp>server.domain.tld</samp> and
-    <samp>www-cache.domain.tld</samp> respectively.
-    The hostname <samp>www.domain.tld</samp> is an alias (CNAME)
-    for <samp>server.domain.tld</samp> and will represent the
+<LI><STRONG>Setup 3:</STRONG>
+    The server machine has two IP addresses (<SAMP>111.22.33.44</SAMP>
+    and <SAMP>111.22.33.55</SAMP>)
+    which resolve to the names <SAMP>server.domain.tld</SAMP> and
+    <SAMP>www-cache.domain.tld</SAMP> respectively.
+    The hostname <SAMP>www.domain.tld</SAMP> is an alias (CNAME)
+    for <SAMP>server.domain.tld</SAMP> and will represent the
     main server.
-    <samp>www-cache.domain.tld</samp> will become our proxy-cache 
+    <SAMP>www-cache.domain.tld</SAMP> will become our proxy-cache 
     listening on port 8080, while the web server itself uses the default
     port 80.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     Listen 111.22.33.44:80
       allow from 111.22.33
       &lt;/Directory&gt;
     &lt;/VirtualHost&gt;
-    </pre>
+    </PRE>
     The main server can never catch a request, because all IP addresses
-    (apart from <samp>localhost</samp>) of our machine are in use for IP-based
+    (apart from <SAMP>localhost</SAMP>) of our machine are in use for IP-based
     virtual hosts. The web server can only be reached on the first address
     through port 80 and the proxy only on the second address through port 8080.
-    </blockquote>
-</ul>
+    </BLOCKQUOTE>
+</UL>
 <HR>
 
 <h3><A NAME="name">Name-based vhosts only</A></h3>
 
-<ul>
+<UL>
 
-<li><b>Setup 1:</b>
-    The server machine has one IP address (<samp>111.22.33.44</samp>)
-    which resolves to the name <samp>server.domain.tld</samp>.
-    There are two aliases (CNAMEs) <samp>www.domain.tld</samp> and
-    <samp>www.sub.domain.tld</samp> for the address <samp>111.22.33.44</samp>.
-    <p>
-    <b>Server configuration:</b>
+<LI><STRONG>Setup 1:</STRONG>
+    The server machine has one IP address (<SAMP>111.22.33.44</SAMP>)
+    which resolves to the name <SAMP>server.domain.tld</SAMP>.
+    There are two aliases (CNAMEs) <SAMP>www.domain.tld</SAMP> and
+    <SAMP>www.sub.domain.tld</SAMP> for the address <SAMP>111.22.33.44</SAMP>.
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     ServerName server.domain.tld
     ServerName www.sub.domain.tld
     ...
     &lt;/VirtualHost&gt; 
-    </pre>
-    Apart from <samp>localhost</samp> there are no unspecified
+    </PRE>
+    Apart from <SAMP>localhost</SAMP> there are no unspecified
     addresses/ports, therefore the main server only serves
-    <samp>localhost</samp> requests. Due to the fact
-    that <samp>www.domain.tld</samp> has the highest priority
-    it can be seen as the <cite>default</cite> or
-    <cite>primary</cite> server.
-    </blockquote>
-    <p>
+    <SAMP>localhost</SAMP> requests. Due to the fact
+    that <SAMP>www.domain.tld</SAMP> has the highest priority
+    it can be seen as the <CITE>default</CITE> or
+    <CITE>primary</CITE> server.
+    </BLOCKQUOTE>
+    <P>
    
-<li><b>Setup 2:</b>
-    The server machine has two IP addresses (<samp>111.22.33.44</samp>
-    and <samp>111.22.33.55</samp>)
-    which resolve to the names <samp>server1.domain.tld</samp> and
-    <samp>server2.domain.tld</samp> respectively.
-    The alias <samp>www.domain.tld</samp> should be used for the
+<LI><STRONG>Setup 2:</STRONG>
+    The server machine has two IP addresses (<SAMP>111.22.33.44</SAMP>
+    and <SAMP>111.22.33.55</SAMP>)
+    which resolve to the names <SAMP>server1.domain.tld</SAMP> and
+    <SAMP>server2.domain.tld</SAMP> respectively.
+    The alias <SAMP>www.domain.tld</SAMP> should be used for the
     main server which should also catch any unspecified addresses. 
     We want to use a virtual host for the alias
-    <samp>www.otherdomain.tld</samp> and one virtual host should
+    <SAMP>www.otherdomain.tld</SAMP> and one virtual host should
     catch any request to hostnames of the form
-    <samp>*.sub.domain.tld</samp> with <samp>www.sub.domain.tld</samp>
-    as its server name. The address <samp>111.22.33.55</samp> should be
+    <SAMP>*.sub.domain.tld</SAMP> with <SAMP>www.sub.domain.tld</SAMP>
+    as its server name. The address <SAMP>111.22.33.55</SAMP> should be
     used for the virtual hosts.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     ServerName www.domain.tld
     ServerAlias *.sub.domain.tld
     ...
     &lt;/VirtualHost&gt; 
-    </pre>
-    Any request to an address other than <samp>111.22.33.55</samp>
+    </PRE>
+    Any request to an address other than <SAMP>111.22.33.55</SAMP>
     will be served from the main server. A request to
-    <samp>111.22.33.55</samp> with an unknown or no <code>Host:</code>
-    header will be served from <samp>www.otherdomain.tld</samp>.
-    </blockquote>
-</ul>
+    <SAMP>111.22.33.55</SAMP> with an unknown or no <CODE>Host:</CODE>
+    header will be served from <SAMP>www.otherdomain.tld</SAMP>.
+    </BLOCKQUOTE>
+</UL>
 
 <HR>
 
 
 <Ul>
 
-<li><b>Setup:</b>
-    The server machine has three IP addresses (<samp>111.22.33.44</samp>,
-    <samp>111.22.33.55</samp> and <samp>111.22.33.66</samp>)
-    which resolve to the names <samp>server.domain.tld</samp>,
-    <samp>www.otherdomain1.tld</samp> and <samp>www.otherdomain2.tld</samp>
+<LI><STRONG>Setup:</STRONG>
+    The server machine has three IP addresses (<SAMP>111.22.33.44</SAMP>,
+    <SAMP>111.22.33.55</SAMP> and <SAMP>111.22.33.66</SAMP>)
+    which resolve to the names <SAMP>server.domain.tld</SAMP>,
+    <SAMP>www.otherdomain1.tld</SAMP> and <SAMP>www.otherdomain2.tld</SAMP>
     respectively.
-    The address <samp>111.22.33.44</samp> should we used for a couple
+    The address <SAMP>111.22.33.44</SAMP> should we used for a couple
     of name-based vhosts and the other addresses for IP-based vhosts. 
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     ServerName server.domain.tld
     ServerName www.otherdomain2.tld
     ...
     &lt;/VirtualHost&gt;     
-    </pre></blockquote>
+    </PRE></BLOCKQUOTE>
 
-</ul>
+</UL>
 
 <HR>
 
 <h3><A NAME="port">Port-based vhosts</A></h3>
 
-<ul>
+<UL>
 
-<li><b>Setup:</b>
-    The server machine has one IP address (<samp>111.22.33.44</samp>)
-    which resolves to the name <samp>www.domain.tld</samp>.
+<LI><STRONG>Setup:</STRONG>
+    The server machine has one IP address (<SAMP>111.22.33.44</SAMP>)
+    which resolves to the name <SAMP>www.domain.tld</SAMP>.
     If we don't have the option to get another address or alias
     for our server we can use port-based vhosts if we need
     a virtual host with a different configuration.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Listen 80
     Listen 8080
     DocumentRoot /www/domain2
     ...
     &lt;/VirtualHost&gt;
-    </pre>
-    A request to <samp>www.domain.tld</samp> on port 80 is served
+    </PRE>
+    A request to <SAMP>www.domain.tld</SAMP> on port 80 is served
     from the main server and a request to port 8080 is served from
     the virtual host.
-    </blockquote>
-</ul
+    </BLOCKQUOTE>
+</UL
    
 <HR>
 
-<h3><A NAME="default">Using <code>_default_</code> vhosts</A></h3>
+<h3><A NAME="default">Using <CODE>_default_</CODE> vhosts</A></h3>
 
-<ul>
+<UL>
 
-<li><b>Setup 1:</b
-    Catching <em>every</em> request to any unspecified IP address and port,
+<LI><STRONG>Setup 1:</STRONG
+    Catching <EM>every</EM> request to any unspecified IP address and port,
     i.e. an address/port combination that is not used for any other
     virtual host.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     &lt;VirtualHost _default_:*&gt;
     DocumentRoot /www/default
     ...
     &lt;/VirtualHost&gt;
-    </pre>
+    </PRE>
     Using such a default vhost with a wildcard port effectively
-    prevents any request going to the main server.<br>
+    prevents any request going to the main server.<BR>
     A default vhost never serves a request that was sent to an
     address/port that is used for name-based vhosts. If the request
-    contained an unknown or no <code>Host:</code> header it is
+    contained an unknown or no <CODE>Host:</CODE> header it is
     always served from the primary name-based vhost (the
     vhost for that address/port appearing first in the configuration
-    file).<br>
+    file).<BR>
     You can use
-    <A HREF="../mod/mod_alias.html#aliasmatch"><code>AliasMatch</code></A>
+    <A HREF="../mod/mod_alias.html#aliasmatch"><CODE>AliasMatch</CODE></A>
     or
-    <A HREF="../mod/mod_rewrite.html#RewriteRule"><code>RewriteRule</code></A>
+    <A HREF="../mod/mod_rewrite.html#RewriteRule"><CODE>RewriteRule</CODE></A>
     to rewrite any request to a single information page (or script).
-    </blockquote>
-    <p>
+    </BLOCKQUOTE>
+    <P>
     
-<li><b>Setup 2:</b
+<LI><STRONG>Setup 2:</STRONG
     Same as setup 1, but the server listens on several ports and
-    we want to use a second <code>_default_</code> vhost for port 80.
-    <p>
-    <b>Server configuration:</b>
+    we want to use a second <CODE>_default_</CODE> vhost for port 80.
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     &lt;VirtualHost _default_:80&gt;
     DocumentRoot /www/default80
     DocumentRoot /www/default
     ...
     &lt;/VirtualHost&gt;    
-    </pre>
-    The default vhost for port 80 (which <em>must</em> appear before
+    </PRE>
+    The default vhost for port 80 (which <EM>must</EM> appear before
     any default vhost with a wildcard port) catches all requests that
     were sent to an unspecified IP address. The main server is
     never used to serve a request.
-    </blockquote>    
-    <p>
+    </BLOCKQUOTE>    
+    <P>
     
-<li><b>Setup 3:</b
+<LI><STRONG>Setup 3:</STRONG
     We want to have a default vhost for port 80, but no other default vhosts.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     &lt;VirtualHost _default_:80&gt;
     DocumentRoot /www/default
     ...
     &lt;/VirtualHost&gt;
-    </pre>
+    </PRE>
     A request to an unspecified address on port 80 is served from the
     default vhost any other request to an unspecified address and port
     is served from the main server.
-    </blockquote>
+    </BLOCKQUOTE>
 
-</ul>
+</UL>
 
 <HR>
 
 <h3><A NAME="migrate">Migrating a name-based vhost to an IP-based vhost</A></h3>
 
-<ul>
+<UL>
 
-<li><b>Setup:</b>
+<LI><STRONG>Setup:</STRONG>
     The name-based vhost with the hostname
-    <samp>www.otherdomain.tld</samp> (from our <a href="#name">name-based</A>
+    <SAMP>www.otherdomain.tld</SAMP> (from our <A HREF="#name">name-based</A>
     example, setup 2) should get its own IP address.
     To avoid problems with name servers or proxies who cached the old
     IP address for the name-based vhost we want to provide both variants
-    during a migration phase.<br>
+    during a migration phase.<BR>
     The solution is easy, because we can simply add the new IP address
-    (<samp>111.22.33.66</samp>) to the <code>VirtualHost</code> directive.
-    <p>
-    <b>Server configuration:</b>
+    (<SAMP>111.22.33.66</SAMP>) to the <CODE>VirtualHost</CODE> directive.
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     Port 80
     ServerName www.domain.tld
     ServerAlias *.sub.domain.tld
     ...
     &lt;/VirtualHost&gt;
-    </pre>
+    </PRE>
     The vhost can now be accessed through the new address (as an IP-based
     vhost) and through the old address (as a name-based vhost).
-    </blockquote>
+    </BLOCKQUOTE>
 
-</ul>
+</UL>
 
 <HR>
 
-<h3><A NAME="serverpath">Using the <code>ServerPath</code> directive</A></h3>
+<h3><A NAME="serverpath">Using the <CODE>ServerPath</CODE> directive</A></h3>
 
-<ul>
+<UL>
 
-<li><b>Setup:</b>
+<LI><STRONG>Setup:</STRONG>
     We have a server with two name-based vhosts. In order to match the correct
-    virtual host a client must send the correct <code>Host:</code> header.
+    virtual host a client must send the correct <CODE>Host:</CODE> header.
     Old HTTP/1.0 clients do not send such a header and Apache has no clue
     what vhost the client tried to reach (and serves the request from
     the primary vhost). To provide as much backward compatibility
     as possible we create a primary vhost which returns a single page
     containing links with an URL prefix to the name-based virtual hosts.
-    <p>
-    <b>Server configuration:</b>
+    <P>
+    <STRONG>Server configuration:</STRONG>
 
-    <blockquote><pre>
+    <BLOCKQUOTE><PRE>
     ...
     NameVirtualHost 111.22.33.44
 
     RewriteRule ^(/sub2/.*) /www/subdomain$1 
     ...
     &lt;/VirtualHost&gt;
-    </pre>
-    Due to the <A HREF="../mod/core.html#serverpath"><code>ServerPath</code></A>
+    </PRE>
+    Due to the <A HREF="../mod/core.html#serverpath"><CODE>ServerPath</CODE></A>
     directive a request to the
-    URL <samp>http://www.sub1.domain.tld/sub1/</samp> is <em>always</em>
-    served from the sub1-vhost. <br>
-    A request to the URL <samp>http://www.sub1.domain.tld/</samp>
+    URL <SAMP>http://www.sub1.domain.tld/sub1/</SAMP> is <EM>always</EM>
+    served from the sub1-vhost. <BR>
+    A request to the URL <SAMP>http://www.sub1.domain.tld/</SAMP>
     is only served from the sub1-vhost if the client sent a correct
-    <code>Host:</code> header.
-    If no <code>Host:</code> header is sent the client gets the
-    information page from the primary host.<br>
+    <CODE>Host:</CODE> header.
+    If no <CODE>Host:</CODE> header is sent the client gets the
+    information page from the primary host.<BR>
     Please note that there is one oddity: A request to
-    <samp>http://www.sub2.domain.tld/sub1/</samp> is also served from
-    the sub1-vhost if the client sent no <code>Host:</code> header. <br>
-    The <code>RewriteRule</code> directives are used to make sure that
-    a client which sent a correct <code>Host:</code> header can use
+    <SAMP>http://www.sub2.domain.tld/sub1/</SAMP> is also served from
+    the sub1-vhost if the client sent no <CODE>Host:</CODE> header. <BR>
+    The <CODE>RewriteRule</CODE> directives are used to make sure that
+    a client which sent a correct <CODE>Host:</CODE> header can use
     both URL variants, i.e. with or without URL prefix.
-    </blockquote>
+    </BLOCKQUOTE>
 
-</ul
+</UL
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 77f4d8254d9b4db7789b590cced728fa213442b8..ad8fc0c7cf2cf9e99f9235f069cdb39681327656 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache Server Virtual Host Support</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache Server Virtual Host Support</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">File Descriptor Limits</h1>
+<h1 ALIGN="CENTER">File Descriptor Limits</H1>
 
 <P>
 When using a large number of Virtual Hosts, Apache may run out of available
-file descriptors (sometimes called <cite>file handles</cite> if each Virtual
+file descriptors (sometimes called <CITE>file handles</CITE> if each Virtual
 Host specifies different log files.
 The total number of file descriptors used by Apache is one for each distinct
 error log file, one for every other log file directive, plus 10-20 for
 internal use. Unix operating systems limit the number of file descriptors that
 may be used by a process; the limit is typically 64, and may usually be
 increased up to a large hard-limit.
-<p>
+<P>
 Although Apache attempts to increase the limit as required, this
 may not work if:
-<ol>
-<li>Your system does not provide the setrlimit() system call.
-<li>The setrlimit(RLIMIT_NOFILE) call does not function on your system
+<OL>
+<LI>Your system does not provide the setrlimit() system call.
+<LI>The setrlimit(RLIMIT_NOFILE) call does not function on your system
  (such as Solaris 2.3)
-<li>The number of file descriptors required exceeds the hard limit.
-<li>Your system imposes other limits on file descriptors, such as a limit
+<LI>The number of file descriptors required exceeds the hard limit.
+<LI>Your system imposes other limits on file descriptors, such as a limit
 on stdio streams only using file descriptors below 256. (Solaris 2)
-</ol>
+</OL>
 
 In the event of problems you can:
-<ul>
-<li>Reduce the number of log files; don't specify log files in the VirtualHost
+<UL>
+<LI>Reduce the number of log files; don't specify log files in the VirtualHost
 sections, but only log to the main log files.
-<li>If you system falls into 1 or 2 (above), then increase the file descriptor
+<LI>If you system falls into 1 or 2 (above), then increase the file descriptor
 limit before starting Apache, using a script like
-<blockquote><code>
-#!/bin/sh <br>
-ulimit -S -n 100 <br>
-exec httpd</code></blockquote>
-</ul>
+<BLOCKQUOTE><CODE>
+#!/bin/sh <BR>
+ulimit -S -n 100 <BR>
+exec httpd</CODE></BLOCKQUOTE>
+</UL>
 <P>
 Please see the
 <A HREF="../misc/descriptors.html">Descriptors and Apache</A>
@@ -55,5 +55,5 @@ they can be solved on your operating system.
 </P>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
 
index 77f4d8254d9b4db7789b590cced728fa213442b8..ad8fc0c7cf2cf9e99f9235f069cdb39681327656 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache Server Virtual Host Support</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache Server Virtual Host Support</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">File Descriptor Limits</h1>
+<h1 ALIGN="CENTER">File Descriptor Limits</H1>
 
 <P>
 When using a large number of Virtual Hosts, Apache may run out of available
-file descriptors (sometimes called <cite>file handles</cite> if each Virtual
+file descriptors (sometimes called <CITE>file handles</CITE> if each Virtual
 Host specifies different log files.
 The total number of file descriptors used by Apache is one for each distinct
 error log file, one for every other log file directive, plus 10-20 for
 internal use. Unix operating systems limit the number of file descriptors that
 may be used by a process; the limit is typically 64, and may usually be
 increased up to a large hard-limit.
-<p>
+<P>
 Although Apache attempts to increase the limit as required, this
 may not work if:
-<ol>
-<li>Your system does not provide the setrlimit() system call.
-<li>The setrlimit(RLIMIT_NOFILE) call does not function on your system
+<OL>
+<LI>Your system does not provide the setrlimit() system call.
+<LI>The setrlimit(RLIMIT_NOFILE) call does not function on your system
  (such as Solaris 2.3)
-<li>The number of file descriptors required exceeds the hard limit.
-<li>Your system imposes other limits on file descriptors, such as a limit
+<LI>The number of file descriptors required exceeds the hard limit.
+<LI>Your system imposes other limits on file descriptors, such as a limit
 on stdio streams only using file descriptors below 256. (Solaris 2)
-</ol>
+</OL>
 
 In the event of problems you can:
-<ul>
-<li>Reduce the number of log files; don't specify log files in the VirtualHost
+<UL>
+<LI>Reduce the number of log files; don't specify log files in the VirtualHost
 sections, but only log to the main log files.
-<li>If you system falls into 1 or 2 (above), then increase the file descriptor
+<LI>If you system falls into 1 or 2 (above), then increase the file descriptor
 limit before starting Apache, using a script like
-<blockquote><code>
-#!/bin/sh <br>
-ulimit -S -n 100 <br>
-exec httpd</code></blockquote>
-</ul>
+<BLOCKQUOTE><CODE>
+#!/bin/sh <BR>
+ulimit -S -n 100 <BR>
+exec httpd</CODE></BLOCKQUOTE>
+</UL>
 <P>
 Please see the
 <A HREF="../misc/descriptors.html">Descriptors and Apache</A>
@@ -55,5 +55,5 @@ they can be solved on your operating system.
 </P>
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
 
index 8c37eaccae40176f90c90107349c20f01ba9e6ac..437c66e50d3b26cde1f190d746ad2a0003475cea 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache non-IP Virtual Hosts</title>
-</head>
+<HTML><HEAD>
+<TITLE>Apache non-IP Virtual Hosts</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache non-IP Virtual Hosts</h1>
+<h1 ALIGN="CENTER">Apache non-IP Virtual Hosts</H1>
 
-<strong>See Also:</strong>
-<a href="virtual-host.html">Virtual Host Support</a>
+<STRONG>See Also:</STRONG>
+<A HREF="virtual-host.html">Virtual Host Support</A>
 
-<hr>
+<HR>
 
 <h2>What is a Virtual Host</h2>
 
-<p>The "Virtual Host" refers to the practice of maintaining more than
+<P>The "Virtual Host" refers to the practice of maintaining more than
 one server on one machine, as differentiated by their apparent
 hostname. For example, it is often desirable for companies sharing a
 web server to have their own domains, with web servers accessible as
-<code>www.company1.com</code> and <code>www.company2.com</code>,
-without requiring the user to know any extra path information.</p>
+<CODE>www.company1.com</CODE> and <CODE>www.company2.com</CODE>,
+without requiring the user to know any extra path information.</P>
 
-<p>Apache was one of the first servers to support virtual hosts right
-out of the box, but since the base <code>HTTP</code> (HyperText
+<P>Apache was one of the first servers to support virtual hosts right
+out of the box, but since the base <CODE>HTTP</CODE> (HyperText
 Transport Protocol) standard does not allow any method for the server
 to determine the hostname it is being addressed as, Apache's virtual
 host support has required a separate IP address for each
 server. Documentation on using this approach (which still works very
-well) <a href="virtual-host.html">is available</a>.
+well) <A HREF="virtual-host.html">is available</A>.
 
-<p>While the approach described above works, with the available IP
+<P>While the approach described above works, with the available IP
 address space growing smaller, and the number of domains increasing,
 it is not the most elegant solution, and is hard to implement on some
-machines. The <code>HTTP/1.1</code> protocol contains a method for the
+machines. The <CODE>HTTP/1.1</CODE> protocol contains a method for the
 server to identify what name it is being addressed as. Apache 1.1 and
 later support this approach as well as the traditional
-IP-address-per-hostname method.</p>
+IP-address-per-hostname method.</P>
 
-<p>The benefits of using the new virtual host support is a practically
+<P>The benefits of using the new virtual host support is a practically
 unlimited number of servers, ease of configuration and use, and
 requires no additional hardware or software. The main disadvantage is
 that the user's browser must support this part of the protocol. The
 latest versions of many browsers (including Netscape Navigator 2.0 and
 later) do, but many browsers, especially older ones, do not. This can
-cause problems, although a possible solution is addressed below.</p>
+cause problems, although a possible solution is addressed below.</P>
 
 <h2>Using non-IP Virtual Hosts</h2>
 
-<p>Using the new virtual hosts is quite easy, and superficially looks
+<P>Using the new virtual hosts is quite easy, and superficially looks
 like the old method. You simply add to one of the Apache configuration
-files (most likely <code>httpd.conf</code> or <code>srm.conf</code>)
-code similar to the following:</p>
-<pre>
+files (most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>)
+code similar to the following:</P>
+<PRE>
     &lt;VirtualHost www.apache.org&gt;
     ServerName www.apache.org
     DocumentRoot /usr/web/apache
     &lt;/VirtualHost&gt;
-</pre>
+</PRE>
 
-<p>Of course, any additional directives can (and should) be placed
-into the <code>&lt;VirtualHost&gt;</code> section. To make this work,
-all that is needed is to make sure that the <code>www.apache.org</code>
+<P>Of course, any additional directives can (and should) be placed
+into the <CODE>&lt;VirtualHost&gt;</CODE> section. To make this work,
+all that is needed is to make sure that the <CODE>www.apache.org</CODE>
 DNS entry points to the same IP address as the main
 server. Optionally, you could simply use that IP address in the
-&lt;VirtualHost&gt; entry.</p>
+&lt;VirtualHost&gt; entry.</P>
 
-<p>Additionally, many servers may wish to be accessible by more than
+<P>Additionally, many servers may wish to be accessible by more than
 one name. For example, the Apache server might want to be accessible
-as <code>apache.org</code>, or <code>ftp.apache.org</code>, assuming
+as <CODE>apache.org</CODE>, or <CODE>ftp.apache.org</CODE>, assuming
 the IP addresses pointed to the same server. In fact, one might want it
-so that all addresses at <code>apache.org</code> were picked up by the
-server. This is possible with the <code>ServerAlias</code>
+so that all addresses at <CODE>apache.org</CODE> were picked up by the
+server. This is possible with the <CODE>ServerAlias</CODE>
 directive, placed inside the &lt;VirtualHost&gt; section. For
-example:</p>
+example:</P>
 
-<pre>
+<PRE>
     ServerAlias apache.org *.apache.org
-</pre>
+</PRE>
 
-<p>Note that you can use <code>*</code> and <code>?</code> as wild-card
-characters.</p>
+<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
+characters.</P>
 
-<p>You also might need ServerAlias if you are serving local users who
+<P>You also might need ServerAlias if you are serving local users who
 do not always include the domain name.  For example, if local users are
 familiar with typing "www" or "www.physics" then you will need to add
-<code>ServerAlias www www.physics</code>.  It isn't possible for the
+<CODE>ServerAlias www www.physics</CODE>.  It isn't possible for the
 server to know what domain the client uses for their name resolution
-because the client doesn't provide that information in the request.</p>
+because the client doesn't provide that information in the request.</P>
 
 <h2>Security Considerations</h2>
 
 Apache allows all virtual hosts to be made accessible via the
-<code>Host:</code> header through all IP interfaces, even those which
+<CODE>Host:</CODE> header through all IP interfaces, even those which
 are configured to use different IP interfaces.  For example, if the
-configuration for <code>www.foo.com</code> contained a virtual host
-section for <code>www.bar.com</code>, and <code>www.bar.com</code> was
+configuration for <CODE>www.foo.com</CODE> contained a virtual host
+section for <CODE>www.bar.com</CODE>, and <CODE>www.bar.com</CODE> was
 a separate IP interface, such that
-non-<code>Host:</code>-header-supporting browsers can use it, as
+non-<CODE>Host:</CODE>-header-supporting browsers can use it, as
 before with Apache 1.0.  If a request is made to
-<code>www.foo.com</code> and the request includes the header
-<code>Host: www.bar.com</code>, a page from <code>www.bar.com</code>
+<CODE>www.foo.com</CODE> and the request includes the header
+<CODE>Host: www.bar.com</CODE>, a page from <CODE>www.bar.com</CODE>
 will be sent.
 
 <P>
 
 This is a security concern if you are controlling access to a
 particular server based on IP-layer controls, such as from within a
-firewall or router.  Let's say <code>www.bar.com</code> in the above
+firewall or router.  Let's say <CODE>www.bar.com</CODE> in the above
 example was instead an intra-net server called
-<code>private.foo.com</code>, and the router used by foo.com only let
-internal users access <code>private.foo.com</code>.  Obviously,
-<code>Host:</code> header functionality now allows someone who has
-access to <code>www.foo.com</code> to get
-<code>private.foo.com</code>, if they send a <code>Host:
-private.foo.com</code> header.  It is important to note that this
+<CODE>private.foo.com</CODE>, and the router used by foo.com only let
+internal users access <CODE>private.foo.com</CODE>.  Obviously,
+<CODE>Host:</CODE> header functionality now allows someone who has
+access to <CODE>www.foo.com</CODE> to get
+<CODE>private.foo.com</CODE>, if they send a <CODE>Host:
+private.foo.com</CODE> header.  It is important to note that this
 condition exists only if you only implement this policy at the IP
 layer - all security controls used by Apache (i.e., <A
 HREF="mod/mod_access.html">allow, deny from,</A> etc.) are consistently
@@ -128,44 +128,44 @@ respected.
 
 <h2>Compatibility with Older Browsers</h2>
 
-<p>As mentioned earlier, a majority of browsers do not send the
+<P>As mentioned earlier, a majority of browsers do not send the
 required data for the new virtual hosts to work properly. These
 browsers will always be sent to the main server's pages. There is a
-workaround, albeit a slightly cumbersome one:</p>
+workaround, albeit a slightly cumbersome one:</P>
 
-<p>To continue the <code>www.apache.org</code> example (Note: Apache's
+<P>To continue the <CODE>www.apache.org</CODE> example (Note: Apache's
 web server does not actually function in this manner), we might use the
-new <code>ServerPath</code> directive in the <code>www.apache.org</code> virtual host,
+new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE> virtual host,
 for example:
 
-<pre>
+<PRE>
     ServerPath /apache
-</pre>
-<p>What does this mean? It means that a request for any file beginning
-with "<code>/apache</code>" will be looked for in the Apache
+</PRE>
+<P>What does this mean? It means that a request for any file beginning
+with "<CODE>/apache</CODE>" will be looked for in the Apache
 docs. This means that the pages can be accessed as
-<code>http://www.apache.org/apache/</code> for all browsers, although
+<CODE>http://www.apache.org/apache/</CODE> for all browsers, although
 new browsers can also access it as
-<code>http://www.apache.org/</code>.</p>
+<CODE>http://www.apache.org/</CODE>.</P>
 
-<p>In order to make this work, put a link on your main server's page
-to <code>http://www.apache.org/apache/</code> (Note: Do not use
-<code>http://www.apache.org/</code> - this would create an endless
+<P>In order to make this work, put a link on your main server's page
+to <CODE>http://www.apache.org/apache/</CODE> (Note: Do not use
+<CODE>http://www.apache.org/</CODE> - this would create an endless
 loop). Then, in the virtual host's pages, be sure to use either purely
-relative links (e.g. "<code>file.html</code>" or
-"<code>../icons/image.gif</code>" or links containing the prefacing
-<code>/apache/</code>
-(e.g. "<code>http://www.apache.org/apache/file.html</code>" or
-"<code>/apache/docs/1.1/index.html</code>").</p>
+relative links (e.g. "<CODE>file.html</CODE>" or
+"<CODE>../icons/image.gif</CODE>" or links containing the prefacing
+<CODE>/apache/</CODE>
+(e.g. "<CODE>http://www.apache.org/apache/file.html</CODE>" or
+"<CODE>/apache/docs/1.1/index.html</CODE>").</P>
 
-<p>This requires a bit of
+<P>This requires a bit of
 discipline, but adherence to these guidelines will, for the most part,
 ensure that your pages will work with all browsers, new and old. When
-a new browser contacts <code>http://www.apache.org/</code>, they will
+a new browser contacts <CODE>http://www.apache.org/</CODE>, they will
 be directly taken to the Apache pages. Older browsers will be able to
 click on the link from the main server, go to
-<code>http://www.apache.org/apache/</code>, and then access the
-pages.</p>
+<CODE>http://www.apache.org/apache/</CODE>, and then access the
+pages.</P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 0b1a22678ee50fd75541f57faca334a599ca579c..d2df6e08244ac3406af0d6634df20f267b2229ee 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache Virtual Host documentation</h1>
+<H1 ALIGN="CENTER">Apache Virtual Host documentation</H1>
 
-<p>The term <cite>Virtual Host</cite> refers to the practice of maintaining
+<P>The term <CITE>Virtual Host</CITE> refers to the practice of maintaining
 more than one server on one machine, as differentiated by their apparent
 hostname. For example, it is often desirable for companies sharing a
 web server to have their own domains, with web servers accessible as
-<samp>www.company1.com</samp> and <samp>www.company2.com</samp>,
-without requiring the user to know any extra path information.</p>
+<SAMP>www.company1.com</SAMP> and <SAMP>www.company2.com</SAMP>,
+without requiring the user to know any extra path information.</P>
 
-<p>Apache was one of the first servers to support IP-based
+<P>Apache was one of the first servers to support IP-based
 virtual hosts right out of the box. Versions 1.1 and later of
 Apache support both, IP-based and name-based virtual hosts (vhosts).
 The latter variant of virtual hosts is sometimes also called host-based or
index 0b1a22678ee50fd75541f57faca334a599ca579c..d2df6e08244ac3406af0d6634df20f267b2229ee 100644 (file)
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Apache Virtual Host documentation</h1>
+<H1 ALIGN="CENTER">Apache Virtual Host documentation</H1>
 
-<p>The term <cite>Virtual Host</cite> refers to the practice of maintaining
+<P>The term <CITE>Virtual Host</CITE> refers to the practice of maintaining
 more than one server on one machine, as differentiated by their apparent
 hostname. For example, it is often desirable for companies sharing a
 web server to have their own domains, with web servers accessible as
-<samp>www.company1.com</samp> and <samp>www.company2.com</samp>,
-without requiring the user to know any extra path information.</p>
+<SAMP>www.company1.com</SAMP> and <SAMP>www.company2.com</SAMP>,
+without requiring the user to know any extra path information.</P>
 
-<p>Apache was one of the first servers to support IP-based
+<P>Apache was one of the first servers to support IP-based
 virtual hosts right out of the box. Versions 1.1 and later of
 Apache support both, IP-based and name-based virtual hosts (vhosts).
 The latter variant of virtual hosts is sometimes also called host-based or
index b31fb8da07e805e5de69253cbdc054039aad9cda..4e090890a59142ffe3ac2d4b278a690423703a7e 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache IP-based Virtual Host Support</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache IP-based Virtual Host Support</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache IP-based Virtual Host Support</h1>
+<h1 ALIGN="CENTER">Apache IP-based Virtual Host Support</H1>
 
-<strong>See also:</strong>
-<a href="name-based.html">Name-based Virtual Hosts Support</a>
+<STRONG>See also:</STRONG>
+<A HREF="name-based.html">Name-based Virtual Hosts Support</A>
 
 <HR>
 
 <h2>System requirements</h2>
-As the term <cite>IP-based</cite> indicates, the server <strong>must have a
-different IP address for each IP-based virtual host</strong>.
+As the term <CITE>IP-based</CITE> indicates, the server <STRONG>must have a
+different IP address for each IP-based virtual host</STRONG>.
 This can be achieved by the machine having several physical network connections,
 or by use of virtual interfaces which are supported by most modern
 operating systems (see system documentation for details, these are
@@ -33,18 +33,18 @@ is most commonly used to set them up).
 There are two ways of configuring apache to support multiple hosts.
 Either by running a separate httpd daemon for each hostname, or by running a
 single daemon which supports all the virtual hosts.
-<p>
+<P>
 Use multiple daemons when:
-<ul>
-<li>There are security partitioning issues, such as company1 does not want
+<UL>
+<LI>There are security partitioning issues, such as company1 does not want
     anyone at company2 to be able to read their data except via the web.
     In this case you would need two daemons, each running with different
     <A HREF="../mod/core.html#user">User</A>,
     <A HREF="../mod/core.html#group">Group</A>,
     <A HREF="../mod/core.html#listen">Listen</A>, and
     <A HREF="../mod/core.html#serverroot">ServerRoot</A> settings.
-<li>You can afford the memory and
-    <a href="../misc/descriptors.html">file descriptor requirements</a> of
+<LI>You can afford the memory and
+    <A HREF="../misc/descriptors.html">file descriptor requirements</A> of
     listening to every IP alias on the machine.  It's only possible to
     <A HREF="../mod/core.html#listen">Listen</A>
     to the "wildcard" address, or to specific addresses.  So if you have
@@ -52,13 +52,13 @@ Use multiple daemons when:
     will need to listen to all specific addresses.  (Although one httpd
     could listen to N-1 of the addresses, and another could listen to
     the remaining address.)
-</ul>
+</UL>
 Use a single daemon when:
-<ul>
-<li>Sharing of the httpd configuration between virtual hosts is acceptable.
-<li>The machine services a large number of requests, and so the performance
+<UL>
+<LI>Sharing of the httpd configuration between virtual hosts is acceptable.
+<LI>The machine services a large number of requests, and so the performance
    loss in running separate daemons may be significant.
-</ul>
+</UL>
 
 <h2>Setting up multiple daemons</h2>
 Create a separate httpd installation for each virtual host.
@@ -66,9 +66,9 @@ For each installation, use the
 <A HREF="../mod/core.html#listen">Listen</A> directive in the configuration
 file to select which IP address (or virtual host) that daemon services.
 e.g.
-<pre>
+<PRE>
     Listen www.smallco.com:80
-</pre>
+</PRE>
 It is recommended that you use an IP address instead of a hostname
 (see <A HREF="../dns-caveats.html">DNS caveats</A>).
 
@@ -85,7 +85,7 @@ The <A HREF="../mod/core.html#virtualhost">VirtualHost</A> directive in the
 <A HREF="../mod/mod_log_config.html#customlog">CustomLog</A>
 configuration directives to different values for each virtual host.
 e.g.
-<pre>
+<PRE>
     &lt;VirtualHost www.smallco.com&gt;
     ServerAdmin webmaster@mail.smallco.com
     DocumentRoot /groups/smallco/www
@@ -101,14 +101,14 @@ e.g.
     ErrorLog /groups/baygroup/logs/error_log
     TransferLog /groups/baygroup/logs/access_log
     &lt;/VirtualHost&gt;
-</pre>
+</PRE>
 
 It is recommended that you use an IP address instead of a hostname
 (see <A HREF="../dns-caveats.html">DNS caveats</A>).
 
 <P>
 
-Almost <strong>any</strong> configuration directive can be put
+Almost <STRONG>any</STRONG> configuration directive can be put
 in the VirtualHost directive, with the exception of
 <A HREF="../mod/core.html#servertype">ServerType</A>,
 <A HREF="../mod/core.html#startservers">StartServers</A>,
@@ -135,6 +135,6 @@ tips</A> document for details.
 </P>
 
 <!--#include virtual="footer.html" -->
-</body>
-</html>
+</BODY>
+</HTML>
 
index 8c77f4fb0b386c44576ea01e096c84312dd775f0..567cab8b58d07e2a5c34c0fe4aecadf77e156539 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache name-based Virtual Hosts</title>
-</head>
+<HTML><HEAD>
+<TITLE>Apache name-based Virtual Hosts</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache name-based Virtual Host Support</h1>
+<h1 ALIGN="CENTER">Apache name-based Virtual Host Support</H1>
 
-<strong>See Also:</strong>
-<a href="ip-based.html">IP-based Virtual Host Support</a>
+<STRONG>See Also:</STRONG>
+<A HREF="ip-based.html">IP-based Virtual Host Support</A>
 
-<hr>
+<HR>
 
 <h2>Name-based vs. IP-based virtual hosts</h2>
 
-<p>While the approach with IP-based virtual hosts works very well,
+<P>While the approach with IP-based virtual hosts works very well,
 it is not the most elegant solution, because a dedicated IP address
 is needed for every virtual host and it is hard to implement on some
-machines. The <code>HTTP/1.1</code> protocol contains a method for the
+machines. The <CODE>HTTP/1.1</CODE> protocol contains a method for the
 server to identify what name it is being addressed as. Apache 1.1 and
 later support this approach as well as the traditional
-IP-address-per-hostname method.</p>
+IP-address-per-hostname method.</P>
 
-<p>The benefits of using the new name-based virtual host support is a
+<P>The benefits of using the new name-based virtual host support is a
 practically unlimited number of servers, ease of configuration and use, and
 requires no additional hardware or software. 
 The main disadvantage is that the client must support this part of the
 protocol. The latest versions of most browsers do, but there are still
 old browsers in use who do not. This can cause problems, although a possible
-solution is addressed below.</p>
+solution is addressed below.</P>
 
 <h2>Using non-IP Virtual Hosts</h2>
 
-<p>Using the new virtual hosts is quite easy, and superficially looks
+<P>Using the new virtual hosts is quite easy, and superficially looks
 like the old method. You simply add to one of the Apache configuration
-files (most likely <code>httpd.conf</code> or <code>srm.conf</code>)
-code similar to the following:</p>
-<pre>
+files (most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>)
+code similar to the following:</P>
+<PRE>
     NameVirtualHost 111.22.33.44
 
     &lt;VirtualHost 111.22.33.44&gt;
     ServerName www.domain.tld
     DocumentRoot /web/domain
     &lt;/VirtualHost&gt;
-</pre>
+</PRE>
 
-<p>The notable difference between IP-based and name-based virtual host
+<P>The notable difference between IP-based and name-based virtual host
 configuration is the
-<A HREF="../mod/core.html#namevirtualhost"><code>NameVirtualHost</code></A>
+<A HREF="../mod/core.html#namevirtualhost"><CODE>NameVirtualHost</CODE></A>
 directive which specifies an IP address that should be used as a target for
 name-based virtual hosts.
 
-<p>Of course, any additional directives can (and should) be placed
-into the <code>&lt;VirtualHost&gt;</code> section. To make this work,
+<P>Of course, any additional directives can (and should) be placed
+into the <CODE>&lt;VirtualHost&gt;</CODE> section. To make this work,
 all that is needed is to make sure that the name
-<samp>www.domain.tld</samp> is an alias (CNAME) pointing to the IP address
-<samp>111.22.33.44</samp></p>
+<SAMP>www.domain.tld</SAMP> is an alias (CNAME) pointing to the IP address
+<SAMP>111.22.33.44</SAMP></P>
 
-<p>Additionally, many servers may wish to be accessible by more than
+<P>Additionally, many servers may wish to be accessible by more than
 one name. For example, the example server might want to be accessible
-as <code>domain.tld</code>, or <code>www2.domain.tld</code>, assuming
+as <CODE>domain.tld</CODE>, or <CODE>www2.domain.tld</CODE>, assuming
 the IP addresses pointed to the same server. In fact, one might want it
-so that all addresses at <code>domain.tld</code> were picked up by the
+so that all addresses at <CODE>domain.tld</CODE> were picked up by the
 server. This is possible with the
-<A HREF="../mod/core.html#serveralias"><code>ServerAlias</code></A>
+<A HREF="../mod/core.html#serveralias"><CODE>ServerAlias</CODE></A>
 directive, placed inside the &lt;VirtualHost&gt; section. For
-example:</p>
+example:</P>
 
-<pre>
+<PRE>
     ServerAlias domain.tld *.domain.tld
-</pre>
+</PRE>
 
-<p>Note that you can use <code>*</code> and <code>?</code> as wild-card
-characters.</p>
+<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
+characters.</P>
 
-<p>You also might need <code>ServerAlias</code> if you are
+<P>You also might need <CODE>ServerAlias</CODE> if you are
 serving local users who do not always include the domain name.
 For example, if local users are
 familiar with typing "www" or "www.foobar" then you will need to add
-<code>ServerAlias www www.foobar</code>.  It isn't possible for the
+<CODE>ServerAlias www www.foobar</CODE>.  It isn't possible for the
 server to know what domain the client uses for their name resolution
-because the client doesn't provide that information in the request.</p>
+because the client doesn't provide that information in the request.</P>
 
 <h2>Compatibility with Older Browsers</h2>
 
-<p>As mentioned earlier, there are still some clients in use who
+<P>As mentioned earlier, there are still some clients in use who
 do not send the required data for the name-based virtual hosts to work
 properly. These clients will always be sent the pages from the
-<cite>primary</cite> name-based virtual host (the first virtual host
-appearing in the configuration file for a specific IP address).</p>
+<CITE>primary</CITE> name-based virtual host (the first virtual host
+appearing in the configuration file for a specific IP address).</P>
 
-<p>There is a possible workaround with the
-<A HREF="../mod/core.html#serverpath"><code>ServerPath</code></A>
-directive, albeit a slightly cumbersome one:</p>
+<P>There is a possible workaround with the
+<A HREF="../mod/core.html#serverpath"><CODE>ServerPath</CODE></A>
+directive, albeit a slightly cumbersome one:</P>
 
-<p>Example configuration:
+<P>Example configuration:
 
-<pre>
+<PRE>
     NameVirtualHost 111.22.33.44
 
     &lt;VirtualHost 111.22.33.44&gt;
@@ -111,30 +111,30 @@ directive, albeit a slightly cumbersome one:</p>
     ServerPath /domain
     DocumentRoot /web/domain
     &lt;/VirtualHost&gt;
-</pre>
+</PRE>
 
-<p>What does this mean? It means that a request for any URI beginning
-with "<samp>/domain</samp>" will be served from the virtual host
-<samp>www.domain.tld</samp> This means that the pages can be accessed as
-<code>http://www.domain.tld/domain/</code> for all clients, although
-clients sending a <samp>Host:</samp> header can also access it as
-<code>http://www.domain.tld/</code>.</p>
+<P>What does this mean? It means that a request for any URI beginning
+with "<SAMP>/domain</SAMP>" will be served from the virtual host
+<SAMP>www.domain.tld</SAMP> This means that the pages can be accessed as
+<CODE>http://www.domain.tld/domain/</CODE> for all clients, although
+clients sending a <SAMP>Host:</SAMP> header can also access it as
+<CODE>http://www.domain.tld/</CODE>.</P>
 
-<p>In order to make this work, put a link on your primary virtual host's page
-to <samp>http://www.domain.tld/domain/</samp>
+<P>In order to make this work, put a link on your primary virtual host's page
+to <SAMP>http://www.domain.tld/domain/</SAMP>
 Then, in the virtual host's pages, be sure to use either purely
-relative links (e.g. "<samp>file.html</samp>" or
-"<samp>../icons/image.gif</samp>" or links containing the prefacing
-<samp>/domain/</samp>
-(e.g. "<samp>http://www.domain.tld/domain/misc/file.html</samp>" or
-"<samp>/domain/misc/file.html</samp>").</p>
+relative links (e.g. "<SAMP>file.html</SAMP>" or
+"<SAMP>../icons/image.gif</SAMP>" or links containing the prefacing
+<SAMP>/domain/</SAMP>
+(e.g. "<SAMP>http://www.domain.tld/domain/misc/file.html</SAMP>" or
+"<SAMP>/domain/misc/file.html</SAMP>").</P>
 
-<p>This requires a bit of
+<P>This requires a bit of
 discipline, but adherence to these guidelines will, for the most part,
-ensure that your pages will work with all browsers, new and old.</p>
+ensure that your pages will work with all browsers, new and old.</P>
 
-<p>See also: <A HREF="examples.html#serverpath">ServerPath configuration
-example</A></p>
+<P>See also: <A HREF="examples.html#serverpath">ServerPath configuration
+example</A></P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 8c77f4fb0b386c44576ea01e096c84312dd775f0..567cab8b58d07e2a5c34c0fe4aecadf77e156539 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache name-based Virtual Hosts</title>
-</head>
+<HTML><HEAD>
+<TITLE>Apache name-based Virtual Hosts</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache name-based Virtual Host Support</h1>
+<h1 ALIGN="CENTER">Apache name-based Virtual Host Support</H1>
 
-<strong>See Also:</strong>
-<a href="ip-based.html">IP-based Virtual Host Support</a>
+<STRONG>See Also:</STRONG>
+<A HREF="ip-based.html">IP-based Virtual Host Support</A>
 
-<hr>
+<HR>
 
 <h2>Name-based vs. IP-based virtual hosts</h2>
 
-<p>While the approach with IP-based virtual hosts works very well,
+<P>While the approach with IP-based virtual hosts works very well,
 it is not the most elegant solution, because a dedicated IP address
 is needed for every virtual host and it is hard to implement on some
-machines. The <code>HTTP/1.1</code> protocol contains a method for the
+machines. The <CODE>HTTP/1.1</CODE> protocol contains a method for the
 server to identify what name it is being addressed as. Apache 1.1 and
 later support this approach as well as the traditional
-IP-address-per-hostname method.</p>
+IP-address-per-hostname method.</P>
 
-<p>The benefits of using the new name-based virtual host support is a
+<P>The benefits of using the new name-based virtual host support is a
 practically unlimited number of servers, ease of configuration and use, and
 requires no additional hardware or software. 
 The main disadvantage is that the client must support this part of the
 protocol. The latest versions of most browsers do, but there are still
 old browsers in use who do not. This can cause problems, although a possible
-solution is addressed below.</p>
+solution is addressed below.</P>
 
 <h2>Using non-IP Virtual Hosts</h2>
 
-<p>Using the new virtual hosts is quite easy, and superficially looks
+<P>Using the new virtual hosts is quite easy, and superficially looks
 like the old method. You simply add to one of the Apache configuration
-files (most likely <code>httpd.conf</code> or <code>srm.conf</code>)
-code similar to the following:</p>
-<pre>
+files (most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>)
+code similar to the following:</P>
+<PRE>
     NameVirtualHost 111.22.33.44
 
     &lt;VirtualHost 111.22.33.44&gt;
     ServerName www.domain.tld
     DocumentRoot /web/domain
     &lt;/VirtualHost&gt;
-</pre>
+</PRE>
 
-<p>The notable difference between IP-based and name-based virtual host
+<P>The notable difference between IP-based and name-based virtual host
 configuration is the
-<A HREF="../mod/core.html#namevirtualhost"><code>NameVirtualHost</code></A>
+<A HREF="../mod/core.html#namevirtualhost"><CODE>NameVirtualHost</CODE></A>
 directive which specifies an IP address that should be used as a target for
 name-based virtual hosts.
 
-<p>Of course, any additional directives can (and should) be placed
-into the <code>&lt;VirtualHost&gt;</code> section. To make this work,
+<P>Of course, any additional directives can (and should) be placed
+into the <CODE>&lt;VirtualHost&gt;</CODE> section. To make this work,
 all that is needed is to make sure that the name
-<samp>www.domain.tld</samp> is an alias (CNAME) pointing to the IP address
-<samp>111.22.33.44</samp></p>
+<SAMP>www.domain.tld</SAMP> is an alias (CNAME) pointing to the IP address
+<SAMP>111.22.33.44</SAMP></P>
 
-<p>Additionally, many servers may wish to be accessible by more than
+<P>Additionally, many servers may wish to be accessible by more than
 one name. For example, the example server might want to be accessible
-as <code>domain.tld</code>, or <code>www2.domain.tld</code>, assuming
+as <CODE>domain.tld</CODE>, or <CODE>www2.domain.tld</CODE>, assuming
 the IP addresses pointed to the same server. In fact, one might want it
-so that all addresses at <code>domain.tld</code> were picked up by the
+so that all addresses at <CODE>domain.tld</CODE> were picked up by the
 server. This is possible with the
-<A HREF="../mod/core.html#serveralias"><code>ServerAlias</code></A>
+<A HREF="../mod/core.html#serveralias"><CODE>ServerAlias</CODE></A>
 directive, placed inside the &lt;VirtualHost&gt; section. For
-example:</p>
+example:</P>
 
-<pre>
+<PRE>
     ServerAlias domain.tld *.domain.tld
-</pre>
+</PRE>
 
-<p>Note that you can use <code>*</code> and <code>?</code> as wild-card
-characters.</p>
+<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
+characters.</P>
 
-<p>You also might need <code>ServerAlias</code> if you are
+<P>You also might need <CODE>ServerAlias</CODE> if you are
 serving local users who do not always include the domain name.
 For example, if local users are
 familiar with typing "www" or "www.foobar" then you will need to add
-<code>ServerAlias www www.foobar</code>.  It isn't possible for the
+<CODE>ServerAlias www www.foobar</CODE>.  It isn't possible for the
 server to know what domain the client uses for their name resolution
-because the client doesn't provide that information in the request.</p>
+because the client doesn't provide that information in the request.</P>
 
 <h2>Compatibility with Older Browsers</h2>
 
-<p>As mentioned earlier, there are still some clients in use who
+<P>As mentioned earlier, there are still some clients in use who
 do not send the required data for the name-based virtual hosts to work
 properly. These clients will always be sent the pages from the
-<cite>primary</cite> name-based virtual host (the first virtual host
-appearing in the configuration file for a specific IP address).</p>
+<CITE>primary</CITE> name-based virtual host (the first virtual host
+appearing in the configuration file for a specific IP address).</P>
 
-<p>There is a possible workaround with the
-<A HREF="../mod/core.html#serverpath"><code>ServerPath</code></A>
-directive, albeit a slightly cumbersome one:</p>
+<P>There is a possible workaround with the
+<A HREF="../mod/core.html#serverpath"><CODE>ServerPath</CODE></A>
+directive, albeit a slightly cumbersome one:</P>
 
-<p>Example configuration:
+<P>Example configuration:
 
-<pre>
+<PRE>
     NameVirtualHost 111.22.33.44
 
     &lt;VirtualHost 111.22.33.44&gt;
@@ -111,30 +111,30 @@ directive, albeit a slightly cumbersome one:</p>
     ServerPath /domain
     DocumentRoot /web/domain
     &lt;/VirtualHost&gt;
-</pre>
+</PRE>
 
-<p>What does this mean? It means that a request for any URI beginning
-with "<samp>/domain</samp>" will be served from the virtual host
-<samp>www.domain.tld</samp> This means that the pages can be accessed as
-<code>http://www.domain.tld/domain/</code> for all clients, although
-clients sending a <samp>Host:</samp> header can also access it as
-<code>http://www.domain.tld/</code>.</p>
+<P>What does this mean? It means that a request for any URI beginning
+with "<SAMP>/domain</SAMP>" will be served from the virtual host
+<SAMP>www.domain.tld</SAMP> This means that the pages can be accessed as
+<CODE>http://www.domain.tld/domain/</CODE> for all clients, although
+clients sending a <SAMP>Host:</SAMP> header can also access it as
+<CODE>http://www.domain.tld/</CODE>.</P>
 
-<p>In order to make this work, put a link on your primary virtual host's page
-to <samp>http://www.domain.tld/domain/</samp>
+<P>In order to make this work, put a link on your primary virtual host's page
+to <SAMP>http://www.domain.tld/domain/</SAMP>
 Then, in the virtual host's pages, be sure to use either purely
-relative links (e.g. "<samp>file.html</samp>" or
-"<samp>../icons/image.gif</samp>" or links containing the prefacing
-<samp>/domain/</samp>
-(e.g. "<samp>http://www.domain.tld/domain/misc/file.html</samp>" or
-"<samp>/domain/misc/file.html</samp>").</p>
+relative links (e.g. "<SAMP>file.html</SAMP>" or
+"<SAMP>../icons/image.gif</SAMP>" or links containing the prefacing
+<SAMP>/domain/</SAMP>
+(e.g. "<SAMP>http://www.domain.tld/domain/misc/file.html</SAMP>" or
+"<SAMP>/domain/misc/file.html</SAMP>").</P>
 
-<p>This requires a bit of
+<P>This requires a bit of
 discipline, but adherence to these guidelines will, for the most part,
-ensure that your pages will work with all browsers, new and old.</p>
+ensure that your pages will work with all browsers, new and old.</P>
 
-<p>See also: <A HREF="examples.html#serverpath">ServerPath configuration
-example</A></p>
+<P>See also: <A HREF="examples.html#serverpath">ServerPath configuration
+example</A></P>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index d2339bff81a8a514fa49c2cbfb3d10881e014bd0..b378f6859166b7e62b9f34c6384e8d8736abe497 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>An In-Depth Discussion of VirtualHost Matching</title>
-</head>
+<HTML><HEAD>
+<TITLE>An In-Depth Discussion of VirtualHost Matching</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">An In-Depth Discussion of VirtualHost Matching</h1>
+<h1 ALIGN="CENTER">An In-Depth Discussion of VirtualHost Matching</H1>
 
-<p>This is a very rough document that was probably out of date the moment
+<P>This is a very rough document that was probably out of date the moment
 it was written.  It attempts to explain exactly what the code does when
 deciding what virtual host to serve a hit from.  It's provided on the
 assumption that something is better than nothing.  The server version
 under discussion is Apache 1.2.
 
-<p>If you just want to &quot;make it work&quot; without understanding
-how, there's a <a href="#whatworks">What Works</a> section at the bottom.
+<P>If you just want to &quot;make it work&quot; without understanding
+how, there's a <A HREF="#whatworks">What Works</A> section at the bottom.
 
 <h3>Config File Parsing</h3>
 
-<p>There is a main_server which consists of all the definitions appearing
+<P>There is a main_server which consists of all the definitions appearing
 outside of <CODE>VirtualHost</CODE> sections.  There are virtual servers,
 called <EM>vhosts</EM>, which are defined by
 <A
@@ -33,7 +33,7 @@ called <EM>vhosts</EM>, which are defined by
 ><SAMP>VirtualHost</SAMP></A>
 sections.
 
-<p>The directives
+<P>The directives
 <A
  HREF="mod/core.html#port"
 ><SAMP>Port</SAMP></A>,
@@ -51,47 +51,47 @@ can appear anywhere within the definition of
 a server.  However, each appearance overrides the previous appearance
 (within that server).
 
-<p>The default value of the <code>Port</code> field for main_server
-is 80.  The main_server has no default <code>ServerName</code>,
-<code>ServerPath</code>, or <code>ServerAlias</code>.
+<P>The default value of the <CODE>Port</CODE> field for main_server
+is 80.  The main_server has no default <CODE>ServerName</CODE>,
+<CODE>ServerPath</CODE>, or <CODE>ServerAlias</CODE>.
 
-<p>In the absence of any
+<P>In the absence of any
 <A
  HREF="mod/core.html#listen"
 ><SAMP>Listen</SAMP></A>
 directives, the (final if there
-are multiple) <code>Port</code> directive in the main_server indicates
+are multiple) <CODE>Port</CODE> directive in the main_server indicates
 which port httpd will listen on.
 
-<p> The <code>Port</code> and <code>ServerName</code> directives for
+<P> The <CODE>Port</CODE> and <CODE>ServerName</CODE> directives for
 any server main or virtual are used when generating URLs such as during
 redirects.
 
-<p> Each address appearing in the <code>VirtualHost</code> directive
+<P> Each address appearing in the <CODE>VirtualHost</CODE> directive
 can have an optional port.  If the port is unspecified it defaults to
-the value of the main_server's most recent <code>Port</code> statement.
+the value of the main_server's most recent <CODE>Port</CODE> statement.
 The special port <SAMP>*</SAMP> indicates a wildcard that matches any port.
 Collectively the entire set of addresses (including multiple
 <SAMP>A</SAMP> record
 results from DNS lookups) are called the vhost's <EM>address set</EM>.
 
-<p> The magic <code>_default_</code> address has significance during
+<P> The magic <CODE>_default_</CODE> address has significance during
 the matching algorithm.  It essentially matches any unspecified address.
 
-<p> After parsing the <code>VirtualHost</code> directive, the vhost server
-is given a default <code>Port</code> equal to the port assigned to the
-first name in its <code>VirtualHost</code> directive.  The complete
-list of names in the <code>VirtualHost</code> directive are treated
-just like a <code>ServerAlias</code> (but are not overridden by any
-<code>ServerAlias</code> statement).  Note that subsequent <code>Port</code>
+<P> After parsing the <CODE>VirtualHost</CODE> directive, the vhost server
+is given a default <CODE>Port</CODE> equal to the port assigned to the
+first name in its <CODE>VirtualHost</CODE> directive.  The complete
+list of names in the <CODE>VirtualHost</CODE> directive are treated
+just like a <CODE>ServerAlias</CODE> (but are not overridden by any
+<CODE>ServerAlias</CODE> statement).  Note that subsequent <CODE>Port</CODE>
 statements for this vhost will not affect the ports assigned in the
 address set.
 
-<p>
+<P>
 All vhosts are stored in a list which is in the reverse order that
 they appeared in the config file.  For example, if the config file is:
 
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
     &lt;VirtualHost A&gt;
     ...
     &lt;/VirtualHost&gt;
@@ -103,53 +103,53 @@ they appeared in the config file.  For example, if the config file is:
     &lt;VirtualHost C&gt;
     ...
     &lt;/VirtualHost&gt;
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
 
 Then the list will be ordered: main_server, C, B, A.  Keep this in mind.
 
-<p>
+<P>
 After parsing has completed, the list of servers is scanned, and various
 merges and default values are set.  In particular:
 
-<ol>
-<li>If a vhost has no
+<OL>
+<LI>If a vhost has no
     <A
      HREF="mod/core.html#serveradmin"
-    ><code>ServerAdmin</code></A>,
+    ><CODE>ServerAdmin</CODE></A>,
     <A
      HREF="mod/core.html#resourceconfig"
-    ><code>ResourceConfig</code></A>,
+    ><CODE>ResourceConfig</CODE></A>,
     <A
      HREF="mod/core.html#accessconfig"
-    ><code>AccessConfig</code></A>,
+    ><CODE>AccessConfig</CODE></A>,
     <A
      HREF="mod/core.html#timeout"
-    ><code>Timeout</code></A>,
+    ><CODE>Timeout</CODE></A>,
     <A
      HREF="mod/core.html#keepalivetimeout"
-    ><code>KeepAliveTimeout</code></A>,
+    ><CODE>KeepAliveTimeout</CODE></A>,
     <A
      HREF="mod/core.html#keepalive"
-    ><code>KeepAlive</code></A>,
+    ><CODE>KeepAlive</CODE></A>,
     <A
      HREF="mod/core.html#maxkeepaliverequests"
-    ><code>MaxKeepAliveRequests</code></A>,
+    ><CODE>MaxKeepAliveRequests</CODE></A>,
     or
     <A
      HREF="mod/core.html#sendbuffersize"
-    ><code>SendBufferSize</code></A>
+    ><CODE>SendBufferSize</CODE></A>
     directive then the respective value is
     inherited from the main_server.  (That is, inherited from whatever
     the final setting of that value is in the main_server.)
 
-<li>The &quot;lookup defaults&quot; that define the default directory
+<LI>The &quot;lookup defaults&quot; that define the default directory
     permissions
     for a vhost are merged with those of the main server.  This includes
     any per-directory configuration information for any module.
 
-<li>The per-server configs for each module from the main_server are
+<LI>The per-server configs for each module from the main_server are
     merged into the vhost server.
-</ol>
+</OL>
 
 Essentially, the main_server is treated as &quot;defaults&quot; or a
 &quot;base&quot; on
@@ -159,134 +159,134 @@ config of the main_server has been parsed when this final merging occurs.
 So even if a main_server definition appears after a vhost definition
 it might affect the vhost definition.
 
-<p> If the main_server has no <code>ServerName</code> at this point,
+<P> If the main_server has no <CODE>ServerName</CODE> at this point,
 then the hostname of the machine that httpd is running on is used
 instead.  We will call the <EM>main_server address set</EM> those IP
-addresses returned by a DNS lookup on the <code>ServerName</code> of
+addresses returned by a DNS lookup on the <CODE>ServerName</CODE> of
 the main_server.
 
-<p> Now a pass is made through the vhosts to fill in any missing
-<code>ServerName</code> fields and to classify the vhost as either
+<P> Now a pass is made through the vhosts to fill in any missing
+<CODE>ServerName</CODE> fields and to classify the vhost as either
 an <EM>IP-based</EM> vhost or a <EM>name-based</EM> vhost.  A vhost is
 considered a name-based vhost if any of its address set overlaps the
 main_server (the port associated with each address must match the
-main_server's <code>Port</code>).  Otherwise it is considered an IP-based
+main_server's <CODE>Port</CODE>).  Otherwise it is considered an IP-based
 vhost.
 
-<p> For any undefined <code>ServerName</code> fields, a name-based vhost
-defaults to the address given first in the <code>VirtualHost</code>
+<P> For any undefined <CODE>ServerName</CODE> fields, a name-based vhost
+defaults to the address given first in the <CODE>VirtualHost</CODE>
 statement defining the vhost.  Any vhost that includes the magic
-<SAMP>_default_</SAMP> wildcard is given the same <code>ServerName</code> as
+<SAMP>_default_</SAMP> wildcard is given the same <CODE>ServerName</CODE> as
 the main_server.  Otherwise the vhost (which is necessarily an IP-based
-vhost) is given a <code>ServerName</code> based on the result of a reverse
-DNS lookup on the first address given in the <code>VirtualHost</code>
+vhost) is given a <CODE>ServerName</CODE> based on the result of a reverse
+DNS lookup on the first address given in the <CODE>VirtualHost</CODE>
 statement.
 
-<p>
+<P>
 
 <h3>Vhost Matching</h3>
 
 
-<p><strong>Apache 1.3 differs from what is documented
-here, and documentation still has to be written.</strong>
+<P><STRONG>Apache 1.3 differs from what is documented
+here, and documentation still has to be written.</STRONG>
 
-<p>
+<P>
 The server determines which vhost to use for a request as follows:
 
-<p> <code>find_virtual_server</code>: When the connection is first made
+<P> <CODE>find_virtual_server</CODE>: When the connection is first made
 by the client, the local IP address (the IP address to which the client
 connected) is looked up in the server list.  A vhost is matched if it
 is an IP-based vhost, the IP address matches and the port matches
 (taking into account wildcards).
 
-<p> If no vhosts are matched then the last occurrence, if it appears,
+<P> If no vhosts are matched then the last occurrence, if it appears,
 of a <SAMP>_default_</SAMP> address (which if you recall the ordering of the
 server list mentioned above means that this would be the first occurrence
 of <SAMP>_default_</SAMP> in the config file) is matched.
 
-<p> In any event, if nothing above has matched, then the main_server is
+<P> In any event, if nothing above has matched, then the main_server is
 matched.
 
-<p> The vhost resulting from the above search is stored with data
+<P> The vhost resulting from the above search is stored with data
 about the connection.  We'll call this the <EM>connection vhost</EM>.
 The connection vhost is constant over all requests in a particular TCP/IP
 session -- that is, over all requests in a KeepAlive/persistent session.
 
-<p> For each request made on the connection the following sequence of
+<P> For each request made on the connection the following sequence of
 events further determines the actual vhost that will be used to serve
 the request.
 
-<p> <code>check_fulluri</code>: If the requestURI is an absoluteURI, that
-is it includes <code>http://hostname/</code>, then an attempt is made to
+<P> <CODE>check_fulluri</CODE>: If the requestURI is an absoluteURI, that
+is it includes <CODE>http://hostname/</CODE>, then an attempt is made to
 determine if the hostname's address (and optional port) match that of
 the connection vhost.  If it does then the hostname portion of the URI
 is saved as the <EM>request_hostname</EM>.  If it does not match, then the
 URI remains untouched.  <STRONG>Note</STRONG>: to achieve this address
 comparison,
 the hostname supplied goes through a DNS lookup unless it matches the
-<code>ServerName</code> or the local IP address of the client's socket.
+<CODE>ServerName</CODE> or the local IP address of the client's socket.
 
-<p> <code>parse_uri</code>: If the URI begins with a protocol
-(<EM>i.e.</EM>, <code>http:</code>, <code>ftp:</code>) then the request is
+<P> <CODE>parse_uri</CODE>: If the URI begins with a protocol
+(<EM>i.e.</EM>, <CODE>http:</CODE>, <CODE>ftp:</CODE>) then the request is
 considered a proxy request.  Note that even though we may have stripped
-an <code>http://hostname/</code> in the previous step, this could still
+an <CODE>http://hostname/</CODE> in the previous step, this could still
 be a proxy request.
 
-<p> <code>read_request</code>: If the request does not have a hostname
-from the earlier step, then any <code>Host:</code> header sent by the
+<P> <CODE>read_request</CODE>: If the request does not have a hostname
+from the earlier step, then any <CODE>Host:</CODE> header sent by the
 client is used as the request hostname.
 
-<p> <code>check_hostalias</code>: If the request now has a hostname,
+<P> <CODE>check_hostalias</CODE>: If the request now has a hostname,
 then an attempt is made to match for this hostname.  The first step
 of this match is to compare any port, if one was given in the request,
-against the <code>Port</code> field of the connection vhost.  If there's
+against the <CODE>Port</CODE> field of the connection vhost.  If there's
 a mismatch then the vhost used for the request is the connection vhost.
 (This is a bug, see observations.)
 
-<p>
+<P>
 If the port matches, then httpd scans the list of vhosts starting with
 the next server <STRONG>after</STRONG> the connection vhost.  This scan does not
 stop if there are any matches, it goes through all possible vhosts,
 and in the end uses the last match it found.  The comparisons performed
 are as follows:
 
-<ul>
-<li>Compare the request hostname:port with the vhost
-    <code>ServerName</code> and <code>Port</code>.
+<UL>
+<LI>Compare the request hostname:port with the vhost
+    <CODE>ServerName</CODE> and <CODE>Port</CODE>.
 
-<li>Compare the request hostname against any and all addresses given in
-    the <code>VirtualHost</code> directive for this vhost.
+<LI>Compare the request hostname against any and all addresses given in
+    the <CODE>VirtualHost</CODE> directive for this vhost.
 
-<li>Compare the request hostname against the <code>ServerAlias</code>
+<LI>Compare the request hostname against the <CODE>ServerAlias</CODE>
     given for the vhost.
-</ul>
+</UL>
 
-<p>
-<code>check_serverpath</code>: If the request has no hostname
+<P>
+<CODE>check_serverpath</CODE>: If the request has no hostname
 (back up a few paragraphs) then a scan similar to the one
-in <code>check_hostalias</code> is performed to match any
-<code>ServerPath</code> directives given in the vhosts.  Note that the
+in <CODE>check_hostalias</CODE> is performed to match any
+<CODE>ServerPath</CODE> directives given in the vhosts.  Note that the
 <STRONG>last match</STRONG> is used regardless (again consider the ordering of
 the virtual hosts).
 
 <h3>Observations</h3>
 
-<ul>
+<UL>
 
-<li>It is difficult to define an IP-based vhost for the machine's
+<LI>It is difficult to define an IP-based vhost for the machine's
     &quot;main IP address&quot;.  You essentially have to create a bogus
-    <code>ServerName</code> for the main_server that does not match the
+    <CODE>ServerName</CODE> for the main_server that does not match the
     machine's IPs.
     <P>
 
-<li>During the scans in both <code>check_hostalias</code> and
-    <code>check_serverpath</code> no check is made that the vhost being
+<LI>During the scans in both <CODE>check_hostalias</CODE> and
+    <CODE>check_serverpath</CODE> no check is made that the vhost being
     scanned is actually a name-based vhost.  This means, for example, that
     it's possible to match an IP-based vhost through another address.  But
     because the scan starts in the vhost list at the first vhost that
     matched the local IP address of the connection, not all IP-based vhosts
     can be matched.
-    <p>
+    <P>
     Consider the config file above with three vhosts A, B, C.  Suppose
     that B is a named-based vhost, and A and C are IP-based vhosts.  If
     a request comes in on B or C's address containing a header
@@ -294,102 +294,102 @@ the virtual hosts).
     it will be served from A's config.  If a request comes in on A's
     address then it will always be served from A's config regardless of
     any Host: header.
-    </p>
+    </P>
 
-<li>Unless you have a <SAMP>_default_</SAMP> vhost,
+<LI>Unless you have a <SAMP>_default_</SAMP> vhost,
     it doesn't matter if you mix name-based vhosts in amongst IP-based
-    vhosts.  During the <code>find_virtual_server</code> phase above no
+    vhosts.  During the <CODE>find_virtual_server</CODE> phase above no
     named-based vhost will be matched, so the main_server will remain the
     connection vhost.  Then scans will cover all vhosts in the vhost list.
-    <p>
+    <P>
     If you do have a <SAMP>_default_</SAMP> vhost, then you cannot place
     named-based vhosts after it in the config.  This is because on any
     connection to the main server IPs the connection vhost will always be
     the <SAMP>_default_</SAMP> vhost since none of the name-based are
-    considered during <code>find_virtual_server</code>.
-    </p>
+    considered during <CODE>find_virtual_server</CODE>.
+    </P>
 
-<li>You should never specify DNS names in <code>VirtualHost</code>
+<LI>You should never specify DNS names in <CODE>VirtualHost</CODE>
     directives because it will force your server to rely on DNS to boot.
     Furthermore it poses a security threat if you do not control the
     DNS for all the domains listed.
-    <a href="dns-caveats.html">There's more information
-    available on this and the next two topics</a>.
-    <p>
+    <A HREF="dns-caveats.html">There's more information
+    available on this and the next two topics</A>.
+    <P>
 
-<li><code>ServerName</code> should always be set for each vhost.  Otherwise
+<LI><CODE>ServerName</CODE> should always be set for each vhost.  Otherwise
     A DNS lookup is required for each vhost.
-    <p>
+    <P>
 
-<li>A DNS lookup is always required for the main_server's
-    <code>ServerName</code> (or to generate that if it isn't specified
+<LI>A DNS lookup is always required for the main_server's
+    <CODE>ServerName</CODE> (or to generate that if it isn't specified
     in the config).
-    <p>
+    <P>
 
-<li>If a <code>ServerPath</code> directive exists which is a prefix of
-    another <code>ServerPath</code> directive that appears later in
+<LI>If a <CODE>ServerPath</CODE> directive exists which is a prefix of
+    another <CODE>ServerPath</CODE> directive that appears later in
     the configuration file, then the former will always be matched
     and the latter will never be matched.  (That is assuming that no
     Host header was available to disambiguate the two.)
-    <p>
+    <P>
 
-<li>If a vhost that would otherwise be a name-vhost includes a
-    <code>Port</code> statement that doesn't match the main_server
-    <code>Port</code> then it will be considered an IP-based vhost.
-    Then <code>find_virtual_server</code> will match it (because
+<LI>If a vhost that would otherwise be a name-vhost includes a
+    <CODE>Port</CODE> statement that doesn't match the main_server
+    <CODE>Port</CODE> then it will be considered an IP-based vhost.
+    Then <CODE>find_virtual_server</CODE> will match it (because
     the ports associated with each address in the address set default
     to the port of the main_server) as the connection vhost.  Then
-    <code>check_hostalias</code> will refuse to check any other name-based
+    <CODE>check_hostalias</CODE> will refuse to check any other name-based
     vhost because of the port mismatch.  The result is that the vhost
     will steal all hits going to the main_server address.
-    <p>
+    <P>
 
-<li>If two IP-based vhosts have an address in common, the vhost appearing
+<LI>If two IP-based vhosts have an address in common, the vhost appearing
     later in the file is always matched.  Such a thing might happen
     inadvertently.  If the config has name-based vhosts and for some reason
-    the main_server <code>ServerName</code> resolves to the wrong address
+    the main_server <CODE>ServerName</CODE> resolves to the wrong address
     then all the name-based vhosts will be parsed as ip-based vhosts.
     Then the last of them will steal all the hits.
     <P>
 
-<li>The last name-based vhost in the config is always matched for any hit
+<LI>The last name-based vhost in the config is always matched for any hit
     which doesn't match one of the other name-based vhosts.
 
-</ul>
+</UL>
 
-<h3><a name="whatworks">What Works</a></h3>
+<h3><A name="whatworks">What Works</A></h3>
 
-<p>In addition to the tips on the <a href="dns-caveats.html#tips">DNS
-Issues</a> page, here are some further tips:
+<P>In addition to the tips on the <A HREF="dns-caveats.html#tips">DNS
+Issues</A> page, here are some further tips:
 
-<ul>
+<UL>
 
-<li>Place all main_server definitions before any VirtualHost definitions.
+<LI>Place all main_server definitions before any VirtualHost definitions.
 (This is to aid the readability of the configuration -- the post-config
 merging process makes it non-obvious that definitions mixed in around
 virtualhosts might affect all virtualhosts.)
-<p>
+<P>
 
-<li>Arrange your VirtualHosts such
+<LI>Arrange your VirtualHosts such
 that all name-based virtual hosts come first, followed by IP-based
 virtual hosts, followed by any <SAMP>_default_</SAMP> virtual host
-<p>
+<P>
 
-<li>Avoid <code>ServerPaths</code> which are prefixes of other
-<code>ServerPaths</code>.  If you cannot avoid this then you have to
+<LI>Avoid <CODE>ServerPaths</CODE> which are prefixes of other
+<CODE>ServerPaths</CODE>.  If you cannot avoid this then you have to
 ensure that the longer (more specific) prefix vhost appears earlier in
 the configuration file than the shorter (less specific) prefix
 (<EM>i.e.</EM>, &quot;ServerPath /abc&quot; should appear after
 &quot;ServerPath /abcdef&quot;).
-<p>
+<P>
 
-<li>Do not use <EM>port-based</EM> vhosts in the same server as
+<LI>Do not use <EM>port-based</EM> vhosts in the same server as
 name-based vhosts.  A loose definition for port-based is a vhost which
-is determined by the port on the server (<em>i.e.</em>, one server with
+is determined by the port on the server (<EM>i.e.</EM>, one server with
 ports 8000, 8080, and 80 - all of which have different configurations).
-<p>
+<P>
 
-</ul>
+</UL>
 
 <!--#include virtual="footer.html" -->
 </BODY>
index 79b6b3a920d492576ffade5ff9d5eed8d694f71a..69a06852e564da9ee65527e882610024137a55d3 100644 (file)
@@ -1,8 +1,8 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>Apache Server Virtual Host Support</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>Apache Server Virtual Host Support</TITLE>
+</HEAD>
 
 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  ALINK="#FF0000"
 >
 <!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Virtual Host Support</h1>
+<h1 ALIGN="CENTER">Virtual Host Support</H1>
 
-<strong>See Also:</strong>
-<a href="host.html">Non-IP based virtual hosts</a>
+<STRONG>See Also:</STRONG>
+<A HREF="host.html">Non-IP based virtual hosts</A>
 
 <h2>What are virtual hosts?</h2>
 This is the ability of a single machine to be a web server for multiple
 domains. For example, an Internet service provider might have a machine
-called <code>www.serve.com</code> which provides Web space for several
-organizations including, say, <em>smallco</em> and <em>baygroup</em>.
+called <CODE>www.serve.com</CODE> which provides Web space for several
+organizations including, say, <EM>smallco</EM> and <EM>baygroup</EM>.
 Ordinarily, these groups would be given parts of the Web tree on www.serve.com.
 So smallco's home page would have the URL
-<blockquote>
+<BLOCKQUOTE>
 http://www.serve.com/smallco/
-</blockquote>
+</BLOCKQUOTE>
 and baygroup's home page would have the URL
-<blockquote>
+<BLOCKQUOTE>
 http://www.serve.com/baygroup/
-</blockquote>
-<p>
+</BLOCKQUOTE>
+<P>
 For esthetic reasons, however, both organizations would rather their home
 pages appeared under their own names rather than that of the service
 provider's; but they do not want to set up their own Internet links and
 servers.
-<p>
+<P>
 Virtual hosts are the solution to this problem. smallco and baygroup would
-have their own Internet name registrations, <code>www.smallco.com</code> and
-<code>www.baygroup.org</code> respectively. These hostnames would both
+have their own Internet name registrations, <CODE>www.smallco.com</CODE> and
+<CODE>www.baygroup.org</CODE> respectively. These hostnames would both
 correspond to the service provider's machine (www.serve.com). Thus
 smallco's home page would now have the URL
-<blockquote>
+<BLOCKQUOTE>
 http://www.smallco.com/
-</blockquote>
+</BLOCKQUOTE>
 and baygroup's home page would would have the URL
-<blockquote>
+<BLOCKQUOTE>
 http://www.baygroup.org/
-</blockquote>
+</BLOCKQUOTE>
 
 <h2>System requirements</h2>
-Due to limitations in the HTTP/1.0 protocol, the web server <strong>must have a
-different IP address for each virtual host</strong>. This can be achieved
+Due to limitations in the HTTP/1.0 protocol, the web server <STRONG>must have a
+different IP address for each virtual host</STRONG>. This can be achieved
 by the machine having several physical network connections, or by use
-of a <a href="misc/vif-info.html">virtual interface</a> on some operating systems.
+of a <A HREF="misc/vif-info.html">virtual interface</A> on some operating systems.
 
 <h2>How to set up Apache</h2>
 There are two ways of configuring apache to support multiple hosts.
 Either by running a separate httpd daemon for each hostname, or by running a
 single daemon which supports all the virtual hosts.
-<p>
+<P>
 Use multiple daemons when:
-<ul>
-<li>The different virtual hosts need very different httpd configurations, such
+<UL>
+<LI>The different virtual hosts need very different httpd configurations, such
    as different values for: <A HREF="mod/core.html#servertype">ServerType</A>,
    <A HREF="mod/core.html#user">User</A>,
    <A HREF="mod/core.html#group">Group</A>,
    <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> or
    <A HREF="mod/core.html#serverroot">ServerRoot</A>.
-<li>The machine does not process a very high request rate.
-</ul>
+<LI>The machine does not process a very high request rate.
+</UL>
 Use a single daemon when:
-<ul>
-<li>Sharing of the httpd configuration between virtual hosts is acceptable.
-<li>The machine services a large number of requests, and so the performance
+<UL>
+<LI>Sharing of the httpd configuration between virtual hosts is acceptable.
+<LI>The machine services a large number of requests, and so the performance
    loss in running separate daemons may be significant.
-</ul>
+</UL>
 
 <h2>Setting up multiple daemons</h2>
 Create a separate httpd installation for each virtual host.
@@ -85,7 +85,7 @@ For each installation, use the
 <A HREF="mod/core.html#bindaddress">BindAddress</A> directive in the configuration
 file to select which IP address (or virtual host) that daemon services.
 e.g.
-<blockquote><code>BindAddress www.smallco.com</code></blockquote>
+<BLOCKQUOTE><CODE>BindAddress www.smallco.com</CODE></BLOCKQUOTE>
 This hostname can also be given as an IP address.
 
 <h2>Setting up a single daemon</h2>
@@ -99,29 +99,29 @@ The <A HREF="mod/core.html#virtualhost">VirtualHost</A> directive in the
 <A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> configuration
 directives to different values for each virtual host.
 e.g.
-<blockquote><code>
-&lt;VirtualHost www.smallco.com&gt;<br>
-ServerAdmin webmaster@mail.smallco.com<br>
-DocumentRoot /groups/smallco/www<br>
-ServerName www.smallco.com<br>
-ErrorLog /groups/smallco/logs/error_log<br>
-TransferLog /groups/smallco/logs/access_log<br>
-&lt;/VirtualHost&gt;<br>
-<br>
-&lt;VirtualHost www.baygroup.org&gt;<br>
-ServerAdmin webmaster@mail.baygroup.org<br>
-DocumentRoot /groups/baygroup/www<br>
-ServerName www.baygroup.org<br>
-ErrorLog /groups/baygroup/logs/error_log<br>
-TransferLog /groups/baygroup/logs/access_log<br>
-&lt;/VirtualHost&gt;<br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+&lt;VirtualHost www.smallco.com&gt;<BR>
+ServerAdmin webmaster@mail.smallco.com<BR>
+DocumentRoot /groups/smallco/www<BR>
+ServerName www.smallco.com<BR>
+ErrorLog /groups/smallco/logs/error_log<BR>
+TransferLog /groups/smallco/logs/access_log<BR>
+&lt;/VirtualHost&gt;<BR>
+<BR>
+&lt;VirtualHost www.baygroup.org&gt;<BR>
+ServerAdmin webmaster@mail.baygroup.org<BR>
+DocumentRoot /groups/baygroup/www<BR>
+ServerName www.baygroup.org<BR>
+ErrorLog /groups/baygroup/logs/error_log<BR>
+TransferLog /groups/baygroup/logs/access_log<BR>
+&lt;/VirtualHost&gt;<BR>
+</CODE></BLOCKQUOTE>
 
 This VirtualHost hostnames can also be given as IP addresses.
 
 <P>
 
-Almost <strong>ANY</strong> configuration directive can be put
+Almost <STRONG>ANY</STRONG> configuration directive can be put
 in the VirtualHost directive, with the exception of
 <A HREF="mod/core.html#servertype">ServerType</A>,
 <A HREF="mod/core.html#user">User</A>,
@@ -153,36 +153,36 @@ error log file, one for every other log file directive, plus 10-20 for
 internal use. Unix operating systems limit the number of file descriptors that
 may be used by a process; the limit is typically 64, and may usually be
 increased up to a large hard-limit.
-<p>
+<P>
 Although Apache attempts to increase the limit as required, this
 may not work if:
-<ol>
-<li>Your system does not provide the setrlimit() system call.
-<li>The setrlimit(RLIMIT_NOFILE) call does not function on your system
+<OL>
+<LI>Your system does not provide the setrlimit() system call.
+<LI>The setrlimit(RLIMIT_NOFILE) call does not function on your system
  (such as Solaris 2.3)
-<li>The number of file descriptors required exceeds the hard limit.
-<li>Your system imposes other limits on file descriptors, such as a limit
+<LI>The number of file descriptors required exceeds the hard limit.
+<LI>Your system imposes other limits on file descriptors, such as a limit
 on stdio streams only using file descriptors below 256. (Solaris 2)
-</ol>
+</OL>
 
 In the event of problems you can:
-<ul>
-<li>Reduce the number of log files; don't specify log files in the VirtualHost
+<UL>
+<LI>Reduce the number of log files; don't specify log files in the VirtualHost
 sections, but only log to the main log files.
-<li>If you system falls into 1 or 2 (above), then increase the file descriptor
+<LI>If you system falls into 1 or 2 (above), then increase the file descriptor
 limit before starting Apache, using a script like
-<blockquote><code>
-#!/bin/sh <br>
-ulimit -S -n 100 <br>
-exec httpd</code></blockquote>
-</ul>
+<BLOCKQUOTE><CODE>
+#!/bin/sh <BR>
+ulimit -S -n 100 <BR>
+exec httpd</CODE></BLOCKQUOTE>
+</UL>
 
 The have been reports that Apache may start running out of resources allocated
 for the root process. This will exhibit itself as errors in the error log like
 "unable to fork". There are two ways you can bump this up:
 
 <OL>
-<LI>Have a <code>csh</code> script wrapper around httpd which sets the
+<LI>Have a <CODE>csh</CODE> script wrapper around httpd which sets the
 "rlimit" to some large number, like 512.
 <LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines of
 <PRE>
@@ -200,5 +200,5 @@ for the root process. This will exhibit itself as errors in the error log like
 The latter will probably manifest itself in a later version of Apache.
 
 <!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>