You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by co...@hyperreal.org on 1998/01/26 17:54:49 UTC
cvs commit: apachen/htdocs/manual/vhosts details.html details_1_2.html examples.html fd-limits.html host.html index.html ip-based.html name-based.html vhosts-in-depth.html virtual-host.html
coar 98/01/26 08:54:38
Modified: htdocs/manual bind.html cgi_path.html
content-negotiation.html custom-error.html
dns-caveats.html env.html handler.html index.html
install.html invoking.html keepalive.html
location.html man-template.html multilogs.html
new_features_1_0.html new_features_1_1.html
new_features_1_2.html new_features_1_3.html
process-model.html sections.html sourcereorg.html
stopping.html suexec.html unixware.html
upgrading_to_1_3.html windows.html
htdocs/manual/misc API.html FAQ.html client_block_api.html
compat_notes.html descriptors.html fin_wait_2.html
howto.html index.html known_bugs.html
known_client_problems.html nopgp.html
perf-bsd44.html perf-dec.html perf-hp.html
perf-tuning.html perf.html security_tips.html
htdocs/manual/mod core.html directives.html index.html
mod_access.html mod_actions.html mod_alias.html
mod_asis.html mod_auth.html mod_auth_anon.html
mod_auth_db.html mod_auth_dbm.html
mod_autoindex.html mod_browser.html
mod_cern_meta.html mod_cgi.html mod_cookies.html
mod_digest.html mod_dir.html mod_dld.html
mod_dll.html mod_env.html mod_example.html
mod_expires.html mod_headers.html mod_imap.html
mod_include.html mod_info.html mod_isapi.html
mod_log_agent.html mod_log_common.html
mod_log_config.html mod_log_referer.html
mod_mime.html mod_mime_magic.html
mod_negotiation.html mod_proxy.html
mod_rewrite.html mod_speling.html mod_status.html
mod_unique_id.html mod_userdir.html
mod_usertrack.html
htdocs/manual/vhosts details.html details_1_2.html
examples.html fd-limits.html host.html index.html
ip-based.html name-based.html vhosts-in-depth.html
virtual-host.html
Log:
A truly mighty mod normalising HTML tags to uppercase, and
'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.
Revision Changes Path
1.10 +36 -36 apachen/htdocs/manual/bind.html
Index: bind.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/bind.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- bind.html 1997/11/11 23:46:47 1.9
+++ bind.html 1998/01/26 16:53:27 1.10
@@ -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
@@ -12,71 +12,71 @@
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 @@
<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"><VirtualHost> section</a>.
+<A HREF="mod/core.html#virtualhost"><VirtualHost> section</A>.
<!--#include virtual="footer.html" -->
</BODY>
1.5 +34 -34 apachen/htdocs/manual/cgi_path.html
Index: cgi_path.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/cgi_path.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- cgi_path.html 1997/06/04 11:07:47 1.4
+++ cgi_path.html 1998/01/26 16:53:27 1.5
@@ -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
@@ -12,80 +12,80 @@
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>
1.13 +193 -193 apachen/htdocs/manual/content-negotiation.html
Index: content-negotiation.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/content-negotiation.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- content-negotiation.html 1997/12/20 20:42:29 1.12
+++ content-negotiation.html 1998/01/26 16:53:28 1.13
@@ -13,25 +13,25 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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; 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; 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><Directory></code>,
-<code><Location></code> or <code><Files></code>
-section in <code>access.conf</code>, or (if <code>AllowOverride</code>
-is properly set) in <code>.htaccess</code> files. Note that
-<code>Options All</code> does not set <code>MultiViews</code>; you
+<CODE>Options</CODE> directive within a <CODE><Directory></CODE>,
+<CODE><Location></CODE> or <CODE><Files></CODE>
+section in <CODE>access.conf</CODE>, or (if <CODE>AllowOverride</CODE>
+is properly set) in <CODE>.htaccess</CODE> files. Note that
+<CODE>Options All</CODE> does not set <CODE>MultiViews</CODE>; you
have to ask for it by name. (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 @@
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 @@
<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 @@
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 @@
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 @@
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 @@
<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>
+<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>
+<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 @@
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
1.11 +35 -35 apachen/htdocs/manual/custom-error.html
Index: custom-error.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/custom-error.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- custom-error.html 1997/07/06 17:18:53 1.10
+++ custom-error.html 1998/01/26 16:53:28 1.11
@@ -55,28 +55,28 @@
<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>
+ <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>note the <CODE>REDIRECT_</CODE> prefix.
- <P>At least <code>REDIRECT_URL</code> and <code>REDIRECT_QUERY_STRING</code> will
+ <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 @@
<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>
<3-digit-code> action
<P>where the action can be,
<OL>
<LI>Text to be displayed. Prefix the text with a quote ("). Whatever
- follows the quote is displayed. <em>Note: the (") prefix isn't
- displayed.</em>
+ follows the quote is displayed. <EM>Note: the (") prefix isn't
+ displayed.</EM>
<LI>An external URL to redirect to.
@@ -121,27 +121,27 @@
<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.
1.8 +66 -66 apachen/htdocs/manual/dns-caveats.html
Index: dns-caveats.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/dns-caveats.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- dns-caveats.html 1997/11/11 23:46:48 1.7
+++ dns-caveats.html 1998/01/26 16:53:29 1.8
@@ -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
@@ -12,10 +12,10 @@
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 @@
Consider this configuration snippet:
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</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>
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</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 @@
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>
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</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>
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
-</pre></blockquote>
+</PRE></BLOCKQUOTE>
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>
-</pre></blockquote>
+</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.
+<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><VirtualHost></code>
-<li> use IP addresses in <code>Listen</code>
-<li> use IP addresses in <code>BindAddress</code>
-<li> ensure all virtual hosts have an explicit <code>ServerName</code>
-<li> create a <code><VirtualHost _default_:*></code> server that
+<UL>
+<LI> use IP addresses in <CODE><VirtualHost></CODE>
+<LI> use IP addresses in <CODE>Listen</CODE>
+<LI> use IP addresses in <CODE>BindAddress</CODE>
+<LI> ensure all virtual hosts have an explicit <CODE>ServerName</CODE>
+<LI> create a <CODE><VirtualHost _default_:*></CODE> server that
has no pages to serve
-</ul>
+</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 @@
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
1.7 +2 -2 apachen/htdocs/manual/env.html
Index: env.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/env.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- env.html 1997/07/20 21:27:04 1.6
+++ env.html 1998/01/26 16:53:30 1.7
@@ -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 @@
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" -->
1.10 +74 -74 apachen/htdocs/manual/handler.html
Index: handler.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/handler.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- handler.html 1997/06/04 11:07:48 1.9
+++ handler.html 1998/01/26 16:53:30 1.10
@@ -13,127 +13,127 @@
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>
-
-<hr>
-
-<h2><a name="addhandler">AddHandler</a></h2>
-
-<strong>Syntax:</strong> <AddHandler <em>handler-name extension</em>><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>
+<UL>
+<LI><A HREF="#addhandler">AddHandler</A>
+<LI><A HREF="#sethandler">SetHandler</A>
+</UL>
+
+<HR>
+
+<h2><A name="addhandler">AddHandler</A></h2>
+
+<STRONG>Syntax:</STRONG> <AddHandler <EM>handler-name extension</EM>><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>
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> <SetHandler <em>handler-name</em>><br>
-<strong>Context:</strong> directory, .htaccess<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_mime
+<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
-<p>When placed into an <code>.htaccess</code> file or a
-<code><Directory></code> or <code><Location></code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE><Directory></CODE> or <CODE><Location></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>
<Location /status>
SetHandler server-status
</Location>
-</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->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->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>
1.20 +32 -32 apachen/htdocs/manual/index.html
Index: index.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/index.html,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- index.html 1997/11/11 23:46:48 1.19
+++ index.html 1998/01/26 16:53:31 1.20
@@ -13,25 +13,25 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache 1.3 User's Guide</h1>
+<h1 ALIGN="CENTER">Apache 1.3 User's Guide</H1>
-<hr>
+<HR>
-<h3><a name="new">Release Notes</a></h3>
-<ul>
-<li><a href="new_features_1_3.html">New features in Apache 1.3</a>
-<li><a href="upgrading_to_1_3.html">Upgrading to Apache 1.3</a>
-<li><a href="new_features_1_2.html">New features in Apache 1.2</a>
-<li><a href="new_features_1_1.html">New features in Apache 1.1</a>
-<li><a href="new_features_1_0.html">New features in Apache 1.0</a>
-</ul>
-<ul>
-<li><a href="misc/known_bugs.html">Known Bugs</a>
-<li><a href="misc/compat_notes.html">Compatibility Notes with NCSA httpd</a>
-<li><a href="LICENSE">Apache License</A>
-</ul>
+<h3><A name="new">Release Notes</A></h3>
+<UL>
+<LI><A HREF="new_features_1_3.html">New features in Apache 1.3</A>
+<LI><A HREF="upgrading_to_1_3.html">Upgrading to Apache 1.3</A>
+<LI><A HREF="new_features_1_2.html">New features in Apache 1.2</A>
+<LI><A HREF="new_features_1_1.html">New features in Apache 1.1</A>
+<LI><A HREF="new_features_1_0.html">New features in Apache 1.0</A>
+</UL>
+<UL>
+<LI><A HREF="misc/known_bugs.html">Known Bugs</A>
+<LI><A HREF="misc/compat_notes.html">Compatibility Notes with NCSA httpd</A>
+<LI><A HREF="LICENSE">Apache License</A>
+</UL>
-<H3><a name="ref">Apache Reference Manual</a></h3>
+<H3><A name="ref">Apache Reference Manual</A></h3>
<UL>
<LI><A
HREF="http://www.apache.org/manual-index.cgi/docs"
@@ -39,30 +39,30 @@
the master manual pages for key words
</LI>
</UL>
-<ul>
-<li><A HREF="install.html">Compiling and Installing Apache</A>
-<li><A HREF="invoking.html">Starting Apache</A>
-<li><A HREF="stopping.html">Stopping or Restarting Apache</A>
-<li><A HREF="mod/directives.html">Apache run-time configuration directives</A>
-<li><A HREF="mod/index.html">Apache modules</A>
-<li><A HREF="vhosts/index.html">Apache Virtual Host documentation</A>
-<li><A HREF="handler.html">Apache's handler use</A>
-<li><A HREF="env.html">Special purpose environment variables</A>
+<UL>
+<LI><A HREF="install.html">Compiling and Installing Apache</A>
+<LI><A HREF="invoking.html">Starting Apache</A>
+<LI><A HREF="stopping.html">Stopping or Restarting Apache</A>
+<LI><A HREF="mod/directives.html">Apache run-time configuration directives</A>
+<LI><A HREF="mod/index.html">Apache modules</A>
+<LI><A HREF="vhosts/index.html">Apache Virtual Host documentation</A>
+<LI><A HREF="handler.html">Apache's handler use</A>
+<LI><A HREF="env.html">Special purpose environment variables</A>
<LI><A HREF="misc/API.html">Highly generalized API to server functionality</A>
<LI><A HREF="suexec.html">Using SetUserID Execution for CGI</A>
-</ul>
+</UL>
-<h3><a name="oth">Other Notes</a></h3>
-<ul>
-<li><A HREF="misc/FAQ.html">Frequently Asked Questions list</a>
-<li><A href="misc/howto.html">How do I? documentation</A>
+<h3><A name="oth">Other Notes</A></h3>
+<UL>
+<LI><A HREF="misc/FAQ.html">Frequently Asked Questions list</A>
+<LI><A HREF="misc/howto.html">How do I? documentation</A>
<LI><A HREF="misc/security_tips.html">Security tips</A>
-<LI><A HREF="misc/perf.html">Performance hints</a> for heavily loaded web servers.
+<LI><A HREF="misc/perf.html">Performance hints</A> for heavily loaded web servers.
<LI><A HREF="misc/fin_wait_2.html">Discussion of the FIN_WAIT_2 problem</A>
<LI><A
HREF="http://www.apache.org/info/jdk-102.html"
>Java's 1.0.2 virtual machine and HTTP/1.1</A>
-</ul>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.19 +6 -6 apachen/htdocs/manual/install.html
Index: install.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/install.html,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- install.html 1997/12/14 00:49:18 1.18
+++ install.html 1998/01/26 16:53:31 1.19
@@ -36,7 +36,7 @@
<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 @@
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/"><URL:http://www.apache.org/dist/contrib/modules/></a>.
+HREF="http://www.apache.org/dist/contrib/modules/"><URL:http://www.apache.org/dist/contrib/modules/></A>.
There are instructions on that page for linking these modules into the
core Apache code.
@@ -126,11 +126,11 @@
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 @@
<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 @@
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.
1.16 +43 -43 apachen/htdocs/manual/invoking.html
Index: invoking.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/invoking.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- invoking.html 1997/12/16 22:22:55 1.15
+++ invoking.html 1998/01/26 16:53:32 1.16
@@ -13,84 +13,84 @@
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 @@
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>.
1.8 +22 -22 apachen/htdocs/manual/keepalive.html
Index: keepalive.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/keepalive.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- keepalive.html 1997/06/04 11:07:49 1.7
+++ keepalive.html 1998/01/26 16:53:32 1.8
@@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Apache Keep-Alive Support</title>
-</head>
+<HTML><HEAD>
+<TITLE>Apache Keep-Alive Support</TITLE>
+</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
@@ -12,14 +12,14 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Apache Keep-Alive Support</h1>
+<h1 ALIGN="CENTER">Apache Keep-Alive Support</H1>
-<hr>
+<HR>
<h2>What is Keep-Alive?</h2>
The Keep-Alive extension to HTTP, as defined by the
-<code>HTTP/1.1</code> draft, allows persistent connections. These
+<CODE>HTTP/1.1</CODE> draft, allows persistent connections. These
long-lived HTTP sessions allow multiple requests to be send over the
same TCP connection, and in some cases have been shown to result in an
almost 50% speedup in latency times for HTML documents with lots of
@@ -30,30 +30,30 @@
Apache 1.1 comes with Keep-Alive support on by default, however there
are some directives you can use to modify Apache's behavior:
-<p><strong>Note</strong>: Apache 1.2 uses a different syntax for the <a
-href="mod/core.html#keepalive">KeepAlive</a> directive.</p>
+<P><STRONG>Note</STRONG>: Apache 1.2 uses a different syntax for the <A
+HREF="mod/core.html#keepalive">KeepAlive</A> directive.</P>
<h3>KeepAlive</h3>
-<strong>Syntax:</strong> KeepAlive <em>max-requests</em><br>
-<strong>Default:</strong> <code>KeepAlive 5</code><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core<p>
+<STRONG>Syntax:</STRONG> KeepAlive <EM>max-requests</EM><BR>
+<STRONG>Default:</STRONG> <CODE>KeepAlive 5</CODE><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core<P>
-This directive enables Keep-Alive support. Set <em>max-requests</em>
+This directive enables Keep-Alive support. Set <EM>max-requests</EM>
to the maximum number of requests you want Apache to entertain per
connection. 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.
<h3>KeepAliveTimeout</h3>
-<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<p>
+<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<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="mod/core.html#timeout"><code>Timeout</code></a> directive
+value specified by the <A
+HREF="mod/core.html#timeout"><CODE>Timeout</CODE></A> directive
applies.
<h2>When Keep-Alive Is Used</h2>
@@ -67,11 +67,11 @@
when connecting to any Keep-Alive server, not just Apache. Netscape 3.0b5
and later versions are known to work around this problem.
-<p>However, Keep-Alive support only is active with files where the
+<P>However, Keep-Alive support only is active with files where the
length is known beforehand. This means that most CGI scripts,
server-side included files and directory listings will not use
the Keep-Alive protocol. While this should be completely transparent
-to the end user, it is something the web-master may want to keep in mind.</p>
+to the end user, it is something the web-master may want to keep in mind.</P>
<!--#include virtual="footer.html" -->
</BODY>
1.8 +17 -17 apachen/htdocs/manual/location.html
Index: location.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/location.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- location.html 1997/06/04 11:07:49 1.7
+++ location.html 1998/01/26 16:53:32 1.8
@@ -15,43 +15,43 @@
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Access Control by URL</H1>
-<h2><a name="location">The <code><Location></code> Directive</a></h2>
+<h2><A name="location">The <CODE><Location></CODE> Directive</A></h2>
-<strong>Syntax:</strong> <Location <em>URL prefix</em>><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> core<br>
+<STRONG>Syntax:</STRONG> <Location <EM>URL prefix</EM>><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> core<BR>
-<p>The <Location> directive provides for access control by
-URL. It is comparable to the <a
-href="mod/core.html#directory"><Directory></a> directive, and
+<P>The <Location> directive provides for access control by
+URL. It is comparable to the <A
+HREF="mod/core.html#directory"><Directory></A> directive, and
should be matched with a </Location> directive. Directives that
apply to the URL given should be listen
-within. <code><Location></code> sections are processed in the
+within. <CODE><Location></CODE> sections are processed in the
order they appear in the configuration file, after the
-<Directory> sections and <code>.htaccess</code> files are
-read.</p>
+<Directory> 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>
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>
-</pre>
+</PRE>
<!--#include virtual="footer.html" -->
</BODY>
1.10 +1 -1 apachen/htdocs/manual/man-template.html
Index: man-template.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/man-template.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- man-template.html 1997/10/16 02:14:41 1.9
+++ man-template.html 1998/01/26 16:53:33 1.10
@@ -18,7 +18,7 @@
<BLOCKQUOTE><EM>Add this file as a link in modules.html</EM></BLOCKQUOTE>
<P>
- This module is contained in the <code>mod_foobar.c</code> file, and
+ This module is contained in the <CODE>mod_foobar.c</CODE> file, and
<STRONG>is/is not</STRONG> compiled in by default. It provides for
<STRONG>the foobar feature</STRONG>. Any document with the mime type
<SAMP>foo/bar</SAMP> will be processed by this module.
1.7 +30 -30 apachen/htdocs/manual/multilogs.html
Index: multilogs.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/multilogs.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- multilogs.html 1997/07/06 17:18:55 1.6
+++ multilogs.html 1998/01/26 16:53:34 1.7
@@ -13,88 +13,88 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Multiple Log Files</h1>
+<h1 ALIGN="CENTER">Multiple Log Files</H1>
It is now possible to specify multiple log files, each with a fully
customizable format. This is compatible with existing
-configurations. Multiple log files are implemented as part of the <a
-href="mod/mod_log_config.html">mod_log_config</a> module which as of
+configurations. Multiple log files are implemented as part of the <A
+HREF="mod/mod_log_config.html">mod_log_config</A> module which as of
Apache 1.2 is the default log module.
-<hr>
+<HR>
<h2>Using Multiple Log Files</h2>
-Multiple log files be created with either the <code>TransferLog</code>
-or <code>CustomLog</code> directive. These directives can be
+Multiple log files be created with either the <CODE>TransferLog</CODE>
+or <CODE>CustomLog</CODE> directive. These directives can be
repeated to create more than one log file (in previous releases,
only one logfile could be given per server configuration).
-The <code>TransferLog</code> directive creates a log file
+The <CODE>TransferLog</CODE> directive creates a log file
in the standard "common log format", although this can be customized
-with <code>LogFormat</code>. The syntax of these two
+with <CODE>LogFormat</CODE>. The syntax of these two
directives is the same as for the config log module in previous
Apache releases.
-<p>
+<P>
The real power of multiple log files come from the ability to
create log files in different formats. For example, as well
as a CLF transfer log, the server could log the user agent of
each client, or the referrer information, or any other aspect of
the request, such as the language preferences of the user.
-<p>
+<P>
-The new <code>CustomLog</code> directive takes both a filename to log
+The new <CODE>CustomLog</CODE> directive takes both a filename to log
to, and a log file format.
-<hr>
+<HR>
-<strong>Syntax:</strong> CustomLog <em>filename "format"</em><br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> base<br>
-<strong>Module:</strong> mod_log_config<p>
+<STRONG>Syntax:</STRONG> CustomLog <EM>filename "format"</EM><BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> base<BR>
+<STRONG>Module:</STRONG> mod_log_config<P>
The first argument is the filename to log to. This is used
-exactly like the argument to <code>TransferLog</code>, that is,
+exactly like the argument to <CODE>TransferLog</CODE>, that is,
it is either a file as a full path or relative to the current
server root, or |programname. Be aware that anyone who can write to
the directory where a log file is written can gain access to the uid
that starts the server. See the <A HREF="misc/security_tips.html">
-security tips</A> document for details.<p>
+security tips</A> document for details.<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 <code>LogFormat</code> directive. If the format
+the argument of the <CODE>LogFormat</CODE> directive. If the format
includes any spaces (which it will do in almost all cases) it
should be enclosed in double quotes.
-<p>
+<P>
<h3>Use with Virtual Hosts</h3>
If a <VirtualHost> section does not contain any
-<code>TransferLog</code> or <code>CustomLog</code> directives, the
+<CODE>TransferLog</CODE> or <CODE>CustomLog</CODE> 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>
-<hr>
+<HR>
<h3>Examples</h3>
To create a normal (CLF) format log file in logs/access_log, and a
log of user agents:
-<pre>
+<PRE>
TransferLog logs/access_log
CustomLog logs/agents "%{user-agent}i"
-</pre>
+</PRE>
To define a CLF transfer log and a referrer log which log
all accesses to both the main server and a virtual host:
-<pre>
+<PRE>
TransferLog logs/access_log
CustomLog logs/referer "%{referer}i"
@@ -102,20 +102,20 @@
DocumentRoot /whatever
ServerName my.virtual.host
</VirtualHost>
-</pre>
+</PRE>
Since no TransferLog or CustomLog directives appear inside the
<VirtualHost> section, any requests for this virtual host
will be logged in the main server's log files. If however the
directive
-<pre>
+<PRE>
TransferLog logs/vhost_access_log
-</pre>
+</PRE>
was added inside the virtual host definition, then accesses to this
virtual host will be logged in vhost_access_log file (in common
-log format), and <i>not</i> in logs/access_log or logs/referer.
+log format), and <EM>not</EM> in logs/access_log or logs/referer.
<!--#include virtual="footer.html" -->
</BODY>
1.9 +19 -19 apachen/htdocs/manual/new_features_1_0.html
Index: new_features_1_0.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/new_features_1_0.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- new_features_1_0.html 1997/11/11 23:46:49 1.8
+++ new_features_1_0.html 1998/01/26 16:53:35 1.9
@@ -13,29 +13,29 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Overview of new features</h1>
+<h1 ALIGN="CENTER">Overview of new features</H1>
<H2>New Features with Apache 1.0</H2>
<P>New features with this release, as extensions of the Apache
-functionality (see also more detailed <code>CHANGES</code> file) in
+functionality (see also more detailed <CODE>CHANGES</CODE> file) in
the source directory. Because the core code has changed so
significantly, there are certain liberties that earlier versions of
Apache (and the NCSA daemon) took that Apache 1.0 is pickier about -
-please check the <a href="misc/compat_notes.html">compatibility notes</a> if you have any problems.
+please check the <A HREF="misc/compat_notes.html">compatibility notes</A> if you have any problems.
<UL>
<LI> API for server extensions --- see below for a brief sermon on
-philosophy, or see <a href="misc/API.html">src/API.html</a> for an actual
+philosophy, or see <A HREF="misc/API.html">src/API.html</A> for an actual
overview. Most server functionality (including includes, CGI, and
most forms of access control) are actually implemented as
API-conformant modules; you can also do other neat stuff (we've
included a sample module, for instance, which one of us is using to
-track click-trails using the <a
-href="http://home.netscape.com/newsref/std/cookie_spec.html">Netscape
-cookie mechanism</a>, for visitors who come in through Netscape
-clients). <a href="mod/mod_dld.html">Modules</a> can also be loaded dynamically using GNU DLD.
+track click-trails using the <A
+HREF="http://home.netscape.com/newsref/std/cookie_spec.html">Netscape
+cookie mechanism</A>, for visitors who come in through Netscape
+clients). <A HREF="mod/mod_dld.html">Modules</A> can also be loaded dynamically using GNU DLD.
<P>
The API is not yet quite stable (see src/TODO for some possible
@@ -44,7 +44,7 @@
<P>
-<LI> <a href="process-model.html">New Process Model - much less forking, no fixed number of children.</a>
+<LI> <A HREF="process-model.html">New Process Model - much less forking, no fixed number of children.</A>
We found that many people were using values for "MaxServers" either
too high or too low, and were hanging themselves on it. The model we
@@ -58,8 +58,8 @@
<P>
-<LI> <a href="vhosts/index.html"><VirtualHost> (the configuration directive for
-multiple-homed servers)</a> is more general now. Just about any srm.conf or
+<LI> <A HREF="vhosts/index.html"><VirtualHost> (the configuration directive for
+multiple-homed servers)</A> is more general now. Just about any srm.conf or
httpd.conf command can go in a <Virtualhost> section, with the
following specific exceptions: ServerType, UserId, GroupId,
StartServers, MaxRequestsPerChild, BindAddress, PidFile, TypesConfig,
@@ -67,7 +67,7 @@
<P>
-<LI> <a href="content-negotiation.html">Support for content negotiation of languages through MultiViews</a>
+<LI> <A HREF="content-negotiation.html">Support for content negotiation of languages through MultiViews</A>
(*.fr, *.de, *.en suffixes), via the new AddLanguage and LanguagePriority
commands (code written by Florent Guillaume, guillaum@clipper.ens.fr).
@@ -101,23 +101,23 @@
<P>
-<LI> <a href="mod/mod_log_config.html">Configurable logging module</a> --- this
+<LI> <A HREF="mod/mod_log_config.html">Configurable logging module</A> --- this
is a replacement for the standard plane-jane Common Log Format code, which
supports a LogFormat directive which allows you to control the formatting of
entries in the TransferLog, and add some new items if you like (in
particular, Referer and User-Agent). EXPERIMENTAL.
-</ul>
-<p><hr>
+</UL>
+<P><HR>
<H2>Other features of Apache</h2>
-<ul>
+<UL>
<LI><A HREF="mod/mod_dld.html">Dynamically loading modules using GNU DLD</A>
<LI><A HREF="mod/mod_imap.html">Imagemap Module</A>
-<li><A HREF="mod/mod_dir.html#directoryindex">Multiple DirectoryIndex filenames</A>
+<LI><A HREF="mod/mod_dir.html#directoryindex">Multiple DirectoryIndex filenames</A>
<LI><A HREF="mod/mod_asis.html"> "Send as is" file types</A>
-<li><A HREF="mod/mod_include.html#xbithack">XBITHACK last modified</A>
-</ul>
+<LI><A HREF="mod/mod_include.html#xbithack">XBITHACK last modified</A>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.10 +86 -86 apachen/htdocs/manual/new_features_1_1.html
Index: new_features_1_1.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/new_features_1_1.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- new_features_1_1.html 1997/11/11 23:46:49 1.9
+++ new_features_1_1.html 1998/01/26 16:53:35 1.10
@@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>New features with Apache 1.1</title>
-</head>
+<HTML><HEAD>
+<TITLE>New features with Apache 1.1</TITLE>
+</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
@@ -12,55 +12,55 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Overview of new features</h1>
+<h1 ALIGN="CENTER">Overview of new features</H1>
<h2>API Changes</h2>
A few changes to the Apache API were made for 1.1. It is possible
that some third-party modules will no longer work with 1.1, though
we have made every effort to provide backwards-compatibility. If you
-encounter a module that does not work with 1.1, please <a
-href="http://www.apache.org/bug_report.html">let us know</a>.
+encounter a module that does not work with 1.1, please <A
+HREF="http://www.apache.org/bug_report.html">let us know</A>.
<h2>New Features with Apache 1.1</h2>
-<p>New features with this release, as extensions of the Apache
-functionality (see also more detailed <code>CHANGES</code> file in
+<P>New features with this release, as extensions of the Apache
+functionality (see also more detailed <CODE>CHANGES</CODE> file in
the source directory.) Because the core code has changed so
significantly, there are certain liberties that earlier versions of
Apache (and the NCSA daemon) took that recent Apache versions are
-pickier about - please check the <a
-href="misc/compat_notes.html">compatibility notes</a> if you have any
-problems.</p>
-<hr>
-
-<p>In addition to a number of bug fixes and internal performance
-enhancements, <a href="http://www.apache.org/dist/">Apache
-1.1</a> has the following specific new user features:</p>
+pickier about - please check the <A
+HREF="misc/compat_notes.html">compatibility notes</A> if you have any
+problems.</P>
+<HR>
+
+<P>In addition to a number of bug fixes and internal performance
+enhancements, <A HREF="http://www.apache.org/dist/">Apache
+1.1</A> has the following specific new user features:</P>
-<ul>
+<UL>
-<li><b><a href="keepalive.html">Support for Keep-Alive Persistent
-Connections</a></b><br> Apache now has (optional) support for persistent
+<LI><STRONG><A HREF="keepalive.html">Support for Keep-Alive Persistent
+Connections</A></STRONG><BR> Apache now has (optional) support for persistent
connections, as defined by the HTTP/1.1 draft. This protocol,
supported by a number of current HTTP servers and browsers (including
Netscape Navigator 2.0) has been shown to increase speed of document
transfer by up to 50% in certain cases.
-<li><b><a href="vhosts/index.html">New non-IP Intensive VirtualHost
-Support</a></b><br>
+<LI><STRONG><A HREF="vhosts/index.html">New non-IP Intensive VirtualHost
+Support</A></STRONG><BR>
Apache's support for virtual hosts has been enhanced to be able to
use information sent by some new Web browsers to determine the server
being accessed, without requiring an additional IP address for each
host.
-<li><b><a href="bind.html">Listen to Multiple Addresses and
-Ports</a></b><br>
-Using the new <code>Listen</code> directive, Apache can listen to more
+<LI><STRONG><A HREF="bind.html">Listen to Multiple Addresses and
+Ports</A></STRONG><BR>
+Using the new <CODE>Listen</CODE> directive, Apache can listen to more
than one port and IP address, using the same configuration set.
-<li><b><a href="mod/mod_status.html">Status
-Module</a></b><br>
+<LI><STRONG><A HREF="mod/mod_status.html">Status
+Module</A></STRONG><BR>
Apache now contains a module that gives the web-master accurate,
up-to-date information about the server's status and its resource
consumption. It also gives the current state of each server process
@@ -68,7 +68,7 @@
<A HREF="http://www.apache.org/status">the status of the
www.apache.org server</A>.
-<li><b><a href="mod/mod_info.html">Server Information Module</a></b>
+<LI><STRONG><A HREF="mod/mod_info.html">Server Information Module</A></STRONG>
This module gives a plethora of information about the other modules
installed, their directives, and their configurations. It is
extremely helpful in debugging configuration problems. For an
@@ -76,136 +76,136 @@
HREF="http://www.apache.org/serv-info">information about the
www.apache.org server</A>.
-<li><b><a href="mod/mod_proxy.html">Experimental Caching Proxy Server</a></b><br>
+<LI><STRONG><A HREF="mod/mod_proxy.html">Experimental Caching Proxy Server</A></STRONG><BR>
Apache can now act as
an HTTP proxy server, allowing clients behind firewalls to use the
server to access the outside world. In addition, it can cache
documents it proxies, speeding up access to frequently requested
documents.
-<li><b><a href="location.html">URL-based Access Protection</a></b><br>
+<LI><STRONG><A HREF="location.html">URL-based Access Protection</A></STRONG><BR>
In addition to access checking and authorization by filename (with
-<code><a href="mod/core.html#directory"><Directory></a></code>),
-the new <code><Location></code> directive allows protection by
+<CODE><A HREF="mod/core.html#directory"><Directory></A></CODE>),
+the new <CODE><Location></CODE> directive allows protection by
URL.
-<li><b><a href="mod/mod_actions.html">Filetype-based Script "Actions"</a></b><br>
+<LI><STRONG><A HREF="mod/mod_actions.html">Filetype-based Script "Actions"</A></STRONG><BR>
You can now run CGI scripts whenever a file of a certain type is
requested. This makes it much easier to execute scripts that process
-files. In addition, you can use the new <a
-href="mod/mod_actions.html#script">Script</a> directive to enable scripts
+files. In addition, you can use the new <A
+HREF="mod/mod_actions.html#script">Script</A> directive to enable scripts
for files called with HTTP methods Apache does not natively support.
-<li><b><a href="handler.html">New "Handler" Directives</a></b><br>
-The new <code>AddHandler</code> and <code>SetHandler</code> directive
+<LI><STRONG><A HREF="handler.html">New "Handler" Directives</A></STRONG><BR>
+The new <CODE>AddHandler</CODE> and <CODE>SetHandler</CODE> directive
allows "handlers" to be defined for filename extensions or
directories. These handlers, which can either be built into Apache or
-added with the <a href="mod/mod_actions.html">Action</a> directive, extend
+added with the <A HREF="mod/mod_actions.html">Action</A> directive, extend
Apache's range of usability, and almost entirely remove the "magic"
media types.
-<li><b><a href="mod/mod_env.html">Customizable CGI Environment
-Variables</a></b><br>
-New <code>PassEnv</code> and <code>SetEnv</code> directives allow you to
+<LI><STRONG><A HREF="mod/mod_env.html">Customizable CGI Environment
+Variables</A></STRONG><BR>
+New <CODE>PassEnv</CODE> and <CODE>SetEnv</CODE> directives allow you to
modify the environment variables passed to CGI scripts.
-<li><b><a href="mod/mod_cern_meta.html">CERN Metafile Support</a></b><br>
+<LI><STRONG><A HREF="mod/mod_cern_meta.html">CERN Metafile Support</A></STRONG><BR>
Now emulates the CERN httpd's support for metafiles containing additional
HTTP headers to be supplied with a document.
-<li><b><a href="mod/mod_imap.html">Improved Imagemap Support</a></b><br>
+<LI><STRONG><A HREF="mod/mod_imap.html">Improved Imagemap Support</A></STRONG><BR>
The internal imagemap handling code has been rewritten and
reorganized, adding new handling of default, base and relative URLs,
and support for creating non-graphical menus for use with clients that
do not support imagemaps.
-<li><b><a href="mod/mod_userdir.html">Improved UserDir Directive</a></b><br>
+<LI><STRONG><A HREF="mod/mod_userdir.html">Improved UserDir Directive</A></STRONG><BR>
Now supports the ability to point user's files (as specified by URLs
-beginning with the "<code>~</code>" character) at directories other
+beginning with the "<CODE>~</CODE>" character) at directories other
than those specified by the Unix password file.
-<li><b>Minimal DNS Now Runtime Option</b><br>
-New <code>HostnameLookups</code>
-server configuration directive can be used to turn <code>On</code> or
-<code>Off</code> DNS lookups. This supersedes the -DMINIMAL_DNS
+<LI><STRONG>Minimal DNS Now Runtime Option</STRONG><BR>
+New <CODE>HostnameLookups</CODE>
+server configuration directive can be used to turn <CODE>On</CODE> or
+<CODE>Off</CODE> DNS lookups. This supersedes the -DMINIMAL_DNS
compile-time configuration option. This option can be set per-directory.
-<li><b>IdentityCheck Now Per-Directory Option</b><br>
-The <code>IdentityCheck</code> directive, which controls the use of
+<LI><STRONG>IdentityCheck Now Per-Directory Option</STRONG><BR>
+The <CODE>IdentityCheck</CODE> directive, which controls the use of
ident to check the remote user name, can now be set per directory. The
ident support is also RFC 1413-compliant.
-<li><b>Redirect Now Usable in <code>.htaccess</code> Files</b><br>
-The <a href="mod/mod_alias.html#redirect"><code>Redirect</code></a>
-directive can now be used in <code>.htaccess</code> files when the
-<code>FileInfo</code> directive has been set on. This allows users to
+<LI><STRONG>Redirect Now Usable in <CODE>.htaccess</CODE> Files</STRONG><BR>
+The <A HREF="mod/mod_alias.html#redirect"><CODE>Redirect</CODE></A>
+directive can now be used in <CODE>.htaccess</CODE> files when the
+<CODE>FileInfo</CODE> directive has been set on. This allows users to
redirect parts of their directories without requiring CGI scripts
-<li><b>ErrorDocument Now Usable in <code>.htaccess</code> Files</b><br>
-The <a href="custom-error.html"><code>ErrorDocument</code></a>
-directive can now be used in <code>.htaccess</code> files when the
-<code>FileInfo</code> directive has been set on. This allows users to
+<LI><STRONG>ErrorDocument Now Usable in <CODE>.htaccess</CODE> Files</STRONG><BR>
+The <A HREF="custom-error.html"><CODE>ErrorDocument</CODE></A>
+directive can now be used in <CODE>.htaccess</CODE> files when the
+<CODE>FileInfo</CODE> directive has been set on. This allows users to
have different error messages for different sections of a site.
-<li><b><code>ForceType</code> Directive</b><br>
-This new directive, in <code><Directory></code> sections or
+<LI><STRONG><CODE>ForceType</CODE> Directive</STRONG><BR>
+This new directive, in <CODE><Directory></CODE> sections or
.htaccess files, allows you to override the filename extensions and
-force a single content type. (e.g. <code>ForceType
-application/octet-stream</code>)
+force a single content type. (e.g. <CODE>ForceType
+application/octet-stream</CODE>)
-<li><b>File Owner Available to Included CGI Scripts</b><br>
+<LI><STRONG>File Owner Available to Included CGI Scripts</STRONG><BR>
Server-side includes that call CGI scripts will now set a
-<code>USER_NAME</code> environment variable that contains the owner of
+<CODE>USER_NAME</CODE> environment variable that contains the owner of
the file which included it.
-<li><b>Improved Icons</b><br>
-Thanks to <a href="mailto:kevinh@eit.com">Kevin
-Hughes</a>, Apache's nifty color GIF icons for directory listings have
-been updated. In addition, the <a
-href="../apache_pb.gif">Powered by Apache</a>
-(<code>apache_pb.gif</code>) logo has been included.
+<LI><STRONG>Improved Icons</STRONG><BR>
+Thanks to <A HREF="mailto:kevinh@eit.com">Kevin
+Hughes</A>, Apache's nifty color GIF icons for directory listings have
+been updated. In addition, the <A
+HREF="../apache_pb.gif">Powered by Apache</A>
+(<CODE>apache_pb.gif</CODE>) logo has been included.
-</ul>
+</UL>
-<hr>
+<HR>
<h3>New Authentication Modules</h3>
-<p><strong>Note:</strong> These modules are not
+<P><STRONG>Note:</STRONG> These modules are not
compiled into the server by default, as they require special support
on the host system. They must be enabled specifically in the
-<code>Configuration</code> file.</p>
+<CODE>Configuration</CODE> file.</P>
-<ul>
+<UL>
-<li><b><a href="mod/mod_auth_anon.html">Anonymous HTTP Logins</a></b><br>
+<LI><STRONG><A HREF="mod/mod_auth_anon.html">Anonymous HTTP Logins</A></STRONG><BR>
New options allow you to allow, using Basic HTTP Authentication,
anonymous logins, like those of FTP. This allows you to collect email
addresses of people accessing your site.
-<li><b><a href="mod/mod_digest.html">Support for Digest
-Authentication</a></b><br>
+<LI><STRONG><A HREF="mod/mod_digest.html">Support for Digest
+Authentication</A></STRONG><BR>
Apache now supports digest authentication using RSA MD5
encryption. When used with a supporting web browser, this provides a
more secure alternative to Basic authentication.
-<li><strong><a href="mod/mod_auth_db.html">Support for Unix DB
-Authentication</a></strong> - <code>mod_auth_db.c</code><br> In
-addition to <a href="mod/mod_auth_dbm.html">DBM</a> support, Apache now
+<LI><STRONG><A HREF="mod/mod_auth_db.html">Support for Unix DB
+Authentication</A></STRONG> - <CODE>mod_auth_db.c</CODE><BR> In
+addition to <A HREF="mod/mod_auth_dbm.html">DBM</A> support, Apache now
contains optional support for Berkeley DB databases.
-<li><strong><a href="mod/mod_auth_msql.html">mSQL Database
-Authentication</a></strong> - <code>mod_auth_msql.html</code> <BR>
+<LI><STRONG><A HREF="mod/mod_auth_msql.html">mSQL Database
+Authentication</A></STRONG> - <CODE>mod_auth_msql.html</CODE> <BR>
Support for the use of mSQL databases for user authentication via HTTP
is now supported.
-</ul>
+</UL>
-<hr>
+<HR>
<h3>OS/2 Support</h3>
-<p>Apache now includes support for OS/2, thanks to <a href="http://www.slink.com/ApacheOS2/">Softlink Services.</a></p>
+<P>Apache now includes support for OS/2, thanks to <A HREF="http://www.slink.com/ApacheOS2/">Softlink Services.</A></P>
<!--#include virtual="footer.html" -->
</BODY>
1.34 +82 -82 apachen/htdocs/manual/new_features_1_2.html
Index: new_features_1_2.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/new_features_1_2.html,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- new_features_1_2.html 1997/10/04 18:43:27 1.33
+++ new_features_1_2.html 1998/01/26 16:53:36 1.34
@@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>New features with Apache 1.2</title>
-</head>
+<HTML><HEAD>
+<TITLE>New features with Apache 1.2</TITLE>
+</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
@@ -12,95 +12,95 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Overview of new features</h1>
+<h1 ALIGN="CENTER">Overview of new features</H1>
<h2>API Changes</h2>
-<p>Some non-compatible changes were made to the Apache API in order to
+<P>Some non-compatible changes were made to the Apache API in order to
deal with HTTP/1.1 compatibility. It is possible that some modules
will no longer work (specifically, those that process input using the
POST or PUT methods). If you encounter a module that does not work,
-please contact the author. A <a
-href="misc/client_block_api.html">programmer's note</a> on the subject is
-available.</p>
+please contact the author. A <A
+HREF="misc/client_block_api.html">programmer's note</A> on the subject is
+available.</P>
-<p>Additionally, some changes were made to the CGI environment that
+<P>Additionally, some changes were made to the CGI environment that
may cause some CGI scripts to work incorrectly. If you are
experiencing trouble with a CGI that worked fine under Apache 1.1.1,
-please see <a href="cgi_path.html">our explanation of the changes.</a></p>
+please see <A HREF="cgi_path.html">our explanation of the changes.</A></P>
<h2>New Features with Apache 1.2</h2>
-<p>New features with this release, as extensions of the Apache
+<P>New features with this release, as extensions of the Apache
functionality. Because the core code has changed so
significantly, there are certain liberties that earlier versions of
Apache (and the NCSA daemon) took that recent Apache versions are
-pickier about - please check the <a
-href="misc/compat_notes.html">compatibility notes</a> if you have any
-problems.</p>
-<hr>
-
-<p>In addition to a number of bug fixes and internal performance
-enhancements, <a href="http://www.apache.org/dist/">Apache
-1.2</a> has the following specific new user features:</p>
+pickier about - please check the <A
+HREF="misc/compat_notes.html">compatibility notes</A> if you have any
+problems.</P>
+<HR>
+
+<P>In addition to a number of bug fixes and internal performance
+enhancements, <A HREF="http://www.apache.org/dist/">Apache
+1.2</A> has the following specific new user features:</P>
-<ul>
+<UL>
<!-- change the "name" to an "href" if/when there's such a document -->
-<li><b><a name="http11.html">HTTP/1.1 Compliance</a></b>
-[Documentation to be written]<br>
+<LI><STRONG><A name="http11.html">HTTP/1.1 Compliance</A></STRONG>
+[Documentation to be written]<BR>
Aside from the optional proxy module (which operates as HTTP/1.0),
Apache is conditionally compliant with the HTTP/1.1 proposed standard,
as approved by the IESG and the
-<a href="http://www.ics.uci.edu/pub/ietf/http/">IETF HTTP working group</a>.
+<A HREF="http://www.ics.uci.edu/pub/ietf/http/">IETF HTTP working group</A>.
HTTP/1.1 provides a much-improved protocol, and
should allow for greater performance and efficiency when transferring
files. Apache does, however, still work great with HTTP/1.0 browsers.
We are very close to being unconditionally compliant; if you note any
deviance from the proposed standard, please report it as a bug.
-<li><b><a href="mod/mod_include.html">eXtended Server Side Includes
-(XSSI)</a></b><br>
+<LI><STRONG><A HREF="mod/mod_include.html">eXtended Server Side Includes
+(XSSI)</A></STRONG><BR>
A new set of server-side include
directives allows the user to better create WWW pages. This includes
number of powerful new features, such as the ability to set variables
and use conditional HTML.
-<li><b><a href="mod/core.html#files">File-based and Regex-enabled
-Directive Sections</a></b><br>
+<LI><STRONG><A HREF="mod/core.html#files">File-based and Regex-enabled
+Directive Sections</A></STRONG><BR>
The new
-<a href="mod/core.html#files"><code><Files></code></a>
+<A HREF="mod/core.html#files"><CODE><Files></CODE></A>
section allows directives to be enabled based on full filename, not just directory and URL. In
-addition, <code><Files></code> sections can appear in
-<code>.htaccess</code> files. <code><Files></code>, along with
-<a href="mod/core.html#directory"><code><Directory></code></a>
- and <a href="mod/core.html#location"><code><Location></code></a>, can
+addition, <CODE><Files></CODE> sections can appear in
+<CODE>.htaccess</CODE> files. <CODE><Files></CODE>, along with
+<A HREF="mod/core.html#directory"><CODE><Directory></CODE></A>
+ and <A HREF="mod/core.html#location"><CODE><Location></CODE></A>, can
also now be based on regular expressions, not just simple prefix
matching.
-<li><b><a href="mod/mod_browser.html">Browser-based Environment
-Variables</a></b><br>
+<LI><STRONG><A HREF="mod/mod_browser.html">Browser-based Environment
+Variables</A></STRONG><BR>
Environment variables can now be set based on the
-<code>User-Agent</code> string of the browser. Combined with <a
-href="mod/mod_include.html">XSSI</a>, this allows you to write browser-based
+<CODE>User-Agent</CODE> string of the browser. Combined with <A
+HREF="mod/mod_include.html">XSSI</A>, this allows you to write browser-based
conditional HTML documents.
-<li><b><a href="suexec.html">SetUID CGI Execution</a></b><br>
+<LI><STRONG><A HREF="suexec.html">SetUID CGI Execution</A></STRONG><BR>
Apache now
supports the execution of CGI scripts as users other
than the server user. A number of security checks are built in
to try and make this as safe as possible.
-<li><b><a href="mod/mod_rewrite.html">URL Rewriting Module</a></b><br>
-The optional <code>mod_rewrite</code> module is now included. This
+<LI><STRONG><A HREF="mod/mod_rewrite.html">URL Rewriting Module</A></STRONG><BR>
+The optional <CODE>mod_rewrite</CODE> module is now included. This
module can provide powerful URL mapping, using regular
expressions. There's nothing this module can't do!
-<li><b><a href="mod/mod_log_config.html">Enhanced, Configurable
-Logging</a></b><br>
-The optional <code>mod_log_config</code> included with earlier
+<LI><STRONG><A HREF="mod/mod_log_config.html">Enhanced, Configurable
+Logging</A></STRONG><BR>
+The optional <CODE>mod_log_config</CODE> included with earlier
versions of Apache is now standard, and has been enhanced to allow
logging of much more detail about the transaction, and can be used to
-open <a href="multilogs.html">more than one log file</a> at once
+open <A HREF="multilogs.html">more than one log file</A> at once
(each of which can have a different log format). If you have Apache
write any logs to a directory which is writable by anyone other than
the user that starts the server, see the <A HREF="misc/security_tips.html">
@@ -108,10 +108,10 @@
of your server at risk.
-<li><b><a href="mod/mod_usertrack.html">User Tracking (Cookies)
-Revisions</a></b><br>
-The <code>mod_cookies</code> included with previous versions of Apache
-has been renamed <code>mod_usertrack</code>, to more accurately
+<LI><STRONG><A HREF="mod/mod_usertrack.html">User Tracking (Cookies)
+Revisions</A></STRONG><BR>
+The <CODE>mod_cookies</CODE> included with previous versions of Apache
+has been renamed <CODE>mod_usertrack</CODE>, to more accurately
reflect its function (some people inadvertently thought it enabled
cookie support in Apache, which is not true - Apache supports the use
of cookies directly). It is also now possible to disable the
@@ -119,81 +119,81 @@
the cookie module is compiled in. Also, an expiry time can be set
on the cookies.
-<li><b><a href="mod/core.html#virtualhost"><VirtualHost> Enhancements</a></b><br>
+<LI><STRONG><A HREF="mod/core.html#virtualhost"><VirtualHost> Enhancements</A></STRONG><BR>
The <VirtualHost> directive can now take more than one IP
address or hostname. This lets a single vhost handles requests
for multiple IPs or hostnames. Also the special section
<VirtualHost _default_> can be used to handle requests normally
left for the main server configuration.
-<li><b><a href="mod/mod_cgi.html#cgi_debug">CGI Debugging Environment</a></b><br>
-<code>ScriptLog</code> allows you to now set up a log that records
+<LI><STRONG><A HREF="mod/mod_cgi.html#cgi_debug">CGI Debugging Environment</A></STRONG><BR>
+<CODE>ScriptLog</CODE> allows you to now set up a log that records
all input and output to failed CGI scripts. This includes environment
variables, input headers, POST data, output, and more. This makes CGI
scripts much easier to debug.
-<li><b><a href="mod/core.html#rlimit">Resource Limits for CGI Scripts</a></b><br>
+<LI><STRONG><A HREF="mod/core.html#rlimit">Resource Limits for CGI Scripts</A></STRONG><BR>
New directives allow the limiting of resources used by CGI scripts
(e.g. max CPU time). This is helpful in preventing 'runaway' CGI
processes.
-<li><b><a href="mod/mod_alias.html">Redirect Directive Can Return Alternate Status</a></b><br>
+<LI><STRONG><A HREF="mod/mod_alias.html">Redirect Directive Can Return Alternate Status</A></STRONG><BR>
The Redirect directive can return permanent or temporary redirects,
"Gone" or "See Other" HTTP status. For NCSA-compatibility,
RedirectTemp and RedirectPermanent are also implemented.
-<li><b><a href="install.html">Simplified Compilation</a></b><br>
+<LI><STRONG><A HREF="install.html">Simplified Compilation</A></STRONG><BR>
The process of configuring Apache for compilation has been
simplified.
-<li><b><a href="mod/core.html#options">Add or Remove Options</a></b><br>
- The <code>Options</code> directive can now add or remove options from
+<LI><STRONG><A HREF="mod/core.html#options">Add or Remove Options</A></STRONG><BR>
+ The <CODE>Options</CODE> directive can now add or remove options from
those currently in force, rather than always replacing them.
-<li><b><a href="invoking.html#help">Command-line Help</a></b><br>
-The <code>-h</code> command-line option now lists all the available
+<LI><STRONG><A HREF="invoking.html#help">Command-line Help</A></STRONG><BR>
+The <CODE>-h</CODE> command-line option now lists all the available
directives.
-<li><b><a href="mod/mod_headers.html">Optional Headers Module to Set or Remove HTTP Headers</a></b><br>
-The optional <code>mod_headers</code> module can be used to set custom
+<LI><STRONG><A HREF="mod/mod_headers.html">Optional Headers Module to Set or Remove HTTP Headers</A></STRONG><BR>
+The optional <CODE>mod_headers</CODE> module can be used to set custom
headers in the HTTP response. It can append to existing headers,
replace them, or remove headers from the response.
-<li><b><a href="mod/core.html#ifmodule">Conditional Config Directives</a></b><br>
-A new <code><IfModule></code> section allows directives to be
+<LI><STRONG><A HREF="mod/core.html#ifmodule">Conditional Config Directives</A></STRONG><BR>
+A new <CODE><IfModule></CODE> section allows directives to be
enabled only if a given module is loaded into the server.
-<li><b><a href="mod/core.html#satisfy">NCSA Satisfy authentication
-directive now implemented</a></b><br>
-<code>Satisfy</code> allows for more flexible access control
+<LI><STRONG><A HREF="mod/core.html#satisfy">NCSA Satisfy authentication
+directive now implemented</A></STRONG><BR>
+<CODE>Satisfy</CODE> allows for more flexible access control
configurations.
-<li><b>Better NCSA Compatibility</b><br>
+<LI><STRONG>Better NCSA Compatibility</STRONG><BR>
Apache directives are now more compatible with NCSA 1.5 to make
moving between servers easier. In particular, Apache now implements the
-<a href="mod/core.html#satisfy"><code>Satisfy</code></a>,
-<a href="mod/core.html#maxkeepaliverequests">MaxKeepAliveRequests</A>,
-<a href="mod/mod_alias.html#redirectperm">RedirectPermanent</A> and
-<a href="mod/mod_alias.html#redirecttemp">RedirectTemp</A>,
+<A HREF="mod/core.html#satisfy"><CODE>Satisfy</CODE></A>,
+<A HREF="mod/core.html#maxkeepaliverequests">MaxKeepAliveRequests</A>,
+<A HREF="mod/mod_alias.html#redirectperm">RedirectPermanent</A> and
+<A HREF="mod/mod_alias.html#redirecttemp">RedirectTemp</A>,
directives, and the following directives are now syntax-compatible with
NCSA:
-<a href="mod/mod_auth.html#authuserfile">AuthUserFile</A>,
-<a href="mod/mod_auth.html#authgroupfile">AuthGroupFile</A>,
-<a href="mod/mod_digest.html#authdigestfile">AuthDigestFile</A>,
-<a href="mod/core.html#keepalive">KeepAlive</A> and
-<a href="mod/core.html#keepalivetimeout">KeepAliveTimeout</A>.
+<A HREF="mod/mod_auth.html#authuserfile">AuthUserFile</A>,
+<A HREF="mod/mod_auth.html#authgroupfile">AuthGroupFile</A>,
+<A HREF="mod/mod_digest.html#authdigestfile">AuthDigestFile</A>,
+<A HREF="mod/core.html#keepalive">KeepAlive</A> and
+<A HREF="mod/core.html#keepalivetimeout">KeepAliveTimeout</A>.
-<li><b><a href="mod/mod_proxy.html">Optional proxy module</a></b><br>
+<LI><STRONG><A HREF="mod/mod_proxy.html">Optional proxy module</A></STRONG><BR>
An improved FTP, HTTP, and CONNECT mode SSL proxy is included with
Apache 1.2. Some of the changes visible to users:
- <dl><dl>
- <dt>- Improved FTP proxy supporting PASV mode
- <dt>- ProxyBlock directive for excluding sites to proxy
- <dt>- NoCache * directive for disabling proxy caching
- <dt>- Numerous bug fixes
- </dl></dl>
+ <DL><DL>
+ <DT>- Improved FTP proxy supporting PASV mode
+ <DT>- ProxyBlock directive for excluding sites to proxy
+ <DT>- NoCache * directive for disabling proxy caching
+ <DT>- Numerous bug fixes
+ </DL></DL>
-</ul>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.38 +125 -125 apachen/htdocs/manual/new_features_1_3.html
Index: new_features_1_3.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/new_features_1_3.html,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- new_features_1_3.html 1997/12/29 20:41:46 1.37
+++ new_features_1_3.html 1998/01/26 16:53:36 1.38
@@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>New features with Apache 1.3</title>
-</head>
+<HTML><HEAD>
+<TITLE>New features with Apache 1.3</TITLE>
+</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
@@ -12,25 +12,25 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Overview of new features</h1>
+<h1 ALIGN="CENTER">Overview of new features</H1>
<h2>New Features with Apache 1.3</h2>
-<p>New features with this release, as extensions of the Apache
+<P>New features with this release, as extensions of the Apache
functionality. Because the core code has changed so
significantly, there are certain liberties that earlier versions of
Apache (and the NCSA daemon) took that recent Apache versions are
pickier about - please check the
-<a href="misc/compat_notes.html">compatibility notes</a> if you have any
-problems.</p>
-<p>If you're upgrading from Apache 1.2, you may wish to read
-the <a href="upgrading_to_1_3.html">upgrade notes</a>.</p>
-<hr>
-
-<p>In addition to a number of bug fixes and internal performance
-enhancements, <a href="http://www.apache.org/dist/">Apache
-1.3</a> has the following specific new user features:</p>
+<A HREF="misc/compat_notes.html">compatibility notes</A> if you have any
+problems.</P>
+<P>If you're upgrading from Apache 1.2, you may wish to read
+the <A HREF="upgrading_to_1_3.html">upgrade notes</A>.</P>
+<HR>
+
+<P>In addition to a number of bug fixes and internal performance
+enhancements, <A HREF="http://www.apache.org/dist/">Apache
+1.3</A> has the following specific new user features:</P>
-<ul>
+<UL>
<LI><A
HREF="mod/mod_speling.html"
><STRONG>Optional «Spelling Correction» module added to distribution</STRONG></A>
@@ -158,7 +158,7 @@
the script. This allows CGI script to provide partial status reports
during long processing operations.
</LI>
-<li><STRONG><a href="windows.html">Support for Windows NT/95</a></STRONG><br>
+<LI><STRONG><A HREF="windows.html">Support for Windows NT/95</A></STRONG><BR>
Apache now supports the Windows NT and Windows 95 operating systems,
as well as the Unix systems supported in previous releases. Although the
Windows version of Apache may not be perform as well as on the Unix
@@ -166,33 +166,33 @@
Windows gives Apache the ability to run on a large number of web
servers it was not previously able to.
-<li><STRONG><a href="mod/mod_alias.html">Regular Expression support for
-<SAMP>Alias</SAMP> and <SAMP>Redirect</SAMP></a></STRONG>
-<br>
-New <a href="mod/mod_alias.html#aliasmatch"><SAMP>AliasMatch</SAMP></a>,
-<a href="mod/mod_alias.html#scriptaliasmatch"
-><SAMP>ScriptAliasMatch</SAMP></a>, and
-<a href="mod/mod_alias.html#redirectmatch"><SAMP>RedirectMatch</SAMP></a>
+<LI><STRONG><A HREF="mod/mod_alias.html">Regular Expression support for
+<SAMP>Alias</SAMP> and <SAMP>Redirect</SAMP></A></STRONG>
+<BR>
+New <A HREF="mod/mod_alias.html#aliasmatch"><SAMP>AliasMatch</SAMP></A>,
+<A HREF="mod/mod_alias.html#scriptaliasmatch"
+><SAMP>ScriptAliasMatch</SAMP></A>, and
+<A HREF="mod/mod_alias.html#redirectmatch"><SAMP>RedirectMatch</SAMP></A>
directives allow for the use of regular expression matching.
Additionally, new
-<a href="mod/core.html#directorymatch"><SAMP><DirectoryMatch></SAMP></a>,
-<a href="mod/core.html#locationmatch"><SAMP><LocationMatch></SAMP></a>,
+<A HREF="mod/core.html#directorymatch"><SAMP><DirectoryMatch></SAMP></A>,
+<A HREF="mod/core.html#locationmatch"><SAMP><LocationMatch></SAMP></A>,
and
-<a href="mod/core.html#filesmatch"><SAMP><FilesMatch></SAMP></a>
+<A HREF="mod/core.html#filesmatch"><SAMP><FilesMatch></SAMP></A>
sections provide a new syntax for regular expression sectioning.
-<li><strong><a href="mod/mod_mime_magic.html">New "Magic" MIME-typing
- module</a></strong><br>
- A new module, the optional <code>mod_mime_magic</code>, has been
+<LI><STRONG><A HREF="mod/mod_mime_magic.html">New "Magic" MIME-typing
+ module</A></STRONG><BR>
+ A new module, the optional <CODE>mod_mime_magic</CODE>, has been
added. It uses "magic numbers" and other hints from a file's contents
to figure out what the contents are. It then uses this information to
set the file's media type, if it cannot be determined by the file's
extension.
-<li><strong>Directory indexing modules split</strong><br>
- The <code>mod_dir</code> module has been split in two, with
- <a href="mod/mod_dir.html">mod_dir</a> handling directory index
- files, and <a href="mod/mod_autoindex.html">mod_autoindex</a>
+<LI><STRONG>Directory indexing modules split</STRONG><BR>
+ The <CODE>mod_dir</CODE> module has been split in two, with
+ <A HREF="mod/mod_dir.html">mod_dir</A> handling directory index
+ files, and <A HREF="mod/mod_autoindex.html">mod_autoindex</A>
creating directory listings. Thus allowing folks to remove
the indexing function from critical servers.
@@ -215,98 +215,98 @@
pre-sized <SAMP>IMG</SAMP> tags are used. This can substantially
speed up the display of large directory listings.
-<li><strong><a href="mod/core.html#accessfilename"><SAMP>AccessFileName</SAMP>
-Enhancement</a></strong><br>
+<LI><STRONG><A HREF="mod/core.html#accessfilename"><SAMP>AccessFileName</SAMP>
+Enhancement</A></STRONG><BR>
The <SAMP>AccessFileName</SAMP> directive can now take more than one
filename. This lets sites serving pages from network file systems and
more than one Apache web server, configure access based on the server
through which shared pages are being served.
-<li><strong><SAMP>HostNameLookups</SAMP> now defaults to "Off"</strong><br>
- The <a
- href="mod/core.html#hostnamelookups"><SAMP>HostNameLookups</SAMP></a>
+<LI><STRONG><SAMP>HostNameLookups</SAMP> now defaults to "Off"</STRONG><BR>
+ The <A
+ HREF="mod/core.html#hostnamelookups"><SAMP>HostNameLookups</SAMP></A>
directive now defaults to "Off". This means that, unless explicitly
turned on, the server will not resolve IP addresses into names. This
was done to spare the Internet from unnecessary DNS traffic.
-<li><strong>Double-Reverse DNS enforced</strong><br>
+<LI><STRONG>Double-Reverse DNS enforced</STRONG><BR>
The
- <a href="mod/core.html#hostnamelookups"><SAMP>HostnameLookups</SAMP></a>
+ <A HREF="mod/core.html#hostnamelookups"><SAMP>HostnameLookups</SAMP></A>
directive
now supports double-reverse DNS. (Known as <EM>PARANOID</EM> in the
terminology of tcp_wrappers.) An IP address passes a double-reverse
DNS test if the forward map of the reverse map includes the original
IP. Regardless of the HostnameLookups setting,
- <a href="mod/mod_access.html">mod_access</a> access lists using DNS
+ <A HREF="mod/mod_access.html">mod_access</A> access lists using DNS
names <STRONG>require</STRONG> all names to pass a double-reverse DNS test.
(Prior versions of Apache required a compile-time switch to enable
double-reverse DNS.)
-<li><strong>CIDR and Netmask access control</strong><br>
- <a href="mod/mod_access.html">mod_access</a> directives now support
+<LI><STRONG>CIDR and Netmask access control</STRONG><BR>
+ <A HREF="mod/mod_access.html">mod_access</A> directives now support
CIDR (Classless Inter-Domain Routing) style prefixes, and netmasks for
greater control over IP access lists.
-<li><strong><a href="mod/mod_proxy.html#noproxy"><SAMP>NoProxy</SAMP></a>
-and <a href="mod/mod_proxy.html#proxydomain"><SAMP>ProxyDomain</SAMP></a>
+<LI><STRONG><A HREF="mod/mod_proxy.html#noproxy"><SAMP>NoProxy</SAMP></A>
+and <A HREF="mod/mod_proxy.html#proxydomain"><SAMP>ProxyDomain</SAMP></A>
directives added to proxy, useful for intranets.</STRONG>
-<li><strong><a href="mod/mod_info.html#addmoduleinfo"
-><SAMP>AddModuleInfo</SAMP></a>
-directive added to <a href="mod/mod_info.html">mod_info</a></strong><br>
+<LI><STRONG><A HREF="mod/mod_info.html#addmoduleinfo"
+><SAMP>AddModuleInfo</SAMP></A>
+directive added to <A HREF="mod/mod_info.html">mod_info</A></STRONG><BR>
Allows additional information to be listed along with a specified module.
-<li><strong>Performance Improvements</strong>
- <ul>
- <li>IP-based virtual hosts are looked up via hash table,
+<LI><STRONG>Performance Improvements</STRONG>
+ <UL>
+ <LI>IP-based virtual hosts are looked up via hash table,
giving a performance boost on servers with large numbers of vhosts.
- <li><Directory> parsing of requests has been vastly improved, giving
+ <LI><Directory> parsing of requests has been vastly improved, giving
speedups on configs with a lot of sections.
- <li>The critical path for static requests has fewer system calls. This
+ <LI>The critical path for static requests has fewer system calls. This
generally helps all requests. (45 syscalls for a static request
in 1.2 versus 22 in 1.3 in a well tuned configuration).
- <li><a href="mod/mod_proxy.html#receivebuffersize"
- ><SAMP>ReceiveBufferSize</SAMP></a>
+ <LI><A HREF="mod/mod_proxy.html#receivebuffersize"
+ ><SAMP>ReceiveBufferSize</SAMP></A>
directive gives <CODE>mod_proxy</CODE>'s outgoing connections
larger network buffers, for increased throughput.
- <li>The low level I/O routines use <code>writev</code> (where available)
+ <LI>The low level I/O routines use <CODE>writev</CODE> (where available)
to issue multiple writes with a single system call. They also avoid
copying memory into buffers as much as possible. The result is
less CPU time spent on transferring large files.
- <li>Static requests are served using
- <code>mmap</code>, which means bytes are only copied from the
+ <LI>Static requests are served using
+ <CODE>mmap</CODE>, which means bytes are only copied from the
disk buffer to the network buffer directly by the kernel. The
program never copies bytes around, which reduces CPU time.
(Only where available/tested.)
- <li>When presented with a load spike, the server quickly adapts by
+ <LI>When presented with a load spike, the server quickly adapts by
spawning children at faster rates.
- <li>The code which dispatches modules was optimized to avoid repeatedly
+ <LI>The code which dispatches modules was optimized to avoid repeatedly
skipping over modules that don't implement certain phases of the
API. (This skipping showed up as 5% of the cpu time on profiles of
a server with the default module mix.)
- <li>Revamp of the Unix scoreboard management code so that less time is
+ <LI>Revamp of the Unix scoreboard management code so that less time is
spent counting children in various states. Previously a scan was
performed for each hit, now it is performed only once per second.
This should be noticeable on servers running with hundreds of
children and high loads.
- <li>New serialization choices improve performance on Linux, Solaris,
+ <LI>New serialization choices improve performance on Linux, Solaris,
and IRIX.
- <li><code><a href="mod/mod_log_config.html">mod_log_config</a></code>
+ <LI><CODE><A HREF="mod/mod_log_config.html">mod_log_config</A></CODE>
can be compile-time configured to buffer writes.
- </ul>
+ </UL>
- <p>See <a href="misc/perf-tuning.html">the new performance
- documentation</a> for more information.
+ <P>See <A HREF="misc/perf-tuning.html">the new performance
+ documentation</A> for more information.
-<li><strong>Unique Identifiers</strong><br>
- <a href="mod/mod_unique_id.html">mod_unique_id</a> can be included
+<LI><STRONG>Unique Identifiers</STRONG><BR>
+ <A HREF="mod/mod_unique_id.html">mod_unique_id</A> can be included
to generate a unique identifier that distinguishes a hit from every
other hit. ("Unique" has some restrictions on it.) The identifier
- is available in the environment variable <code>UNIQUE_ID</code>.
+ is available in the environment variable <CODE>UNIQUE_ID</CODE>.
-<li><strong>Reliable Piped Logs</strong><br>
+<LI><STRONG>Reliable Piped Logs</STRONG><BR>
On almost all Unix architectures Apache now implements "reliable"
- piped logs in <a href="mod/mod_log_config.html">mod_log_config</a>.
+ piped logs in <A HREF="mod/mod_log_config.html">mod_log_config</A>.
Where reliable means that if the logging child dies for whatever
reason, Apache will recover and respawn it without having to restart
the entire server. Furthermore if the logging child becomes "stuck"
@@ -315,11 +315,11 @@
real-time splitting of multiple vhosts into separate logs, and
asynchronous DNS resolving on the fly.
-<li><strong>ServerRoot relative auth filenames</strong><br>
+<LI><STRONG>ServerRoot relative auth filenames</STRONG><BR>
Auth filenames for the various authentication modules are now treated
as relative to the ServerRoot if they are not full paths.
-<li><strong><SAMP>Include</SAMP> directive</strong><br>
+<LI><STRONG><SAMP>Include</SAMP> directive</STRONG><BR>
The
<A
HREF="mod/core.html#include"
@@ -327,10 +327,10 @@
directive includes other config files immediately at that
point in parsing.
-<li><strong>Absence of any <SAMP>TransferLog</SAMP> disables logging</strong>
- <br>
- If no <a href="mod/mod_log_config.html#transferlog"
- ><SAMP>TransferLog</SAMP></a>
+<LI><STRONG>Absence of any <SAMP>TransferLog</SAMP> disables logging</STRONG>
+ <BR>
+ If no <A HREF="mod/mod_log_config.html#transferlog"
+ ><SAMP>TransferLog</SAMP></A>
directive is given then no log is written. This supports co-existence
with other logging modules.
<LI><STRONG>Ability to name logging formats</STRONG>
@@ -349,120 +349,120 @@
directives, rather than having to spell out the complete log format
string each time.
</LI>
-<li><strong>mod_cern_meta configurable per-directory</strong><br>
- <a href="mod/mod_cern_meta.html">mod_cern_meta</a> is now configurable
+<LI><STRONG>mod_cern_meta configurable per-directory</STRONG><BR>
+ <A HREF="mod/mod_cern_meta.html">mod_cern_meta</A> is now configurable
on a per-directory basis.
-<li><strong>Detaching from stdin/out/err</strong><br>
+<LI><STRONG>Detaching from stdin/out/err</STRONG><BR>
On boot Apache will now detach from stdin, stdout, and stderr. It
does not detach from stderr until it has successfully read the config
files. So you will see errors in the config file. This should make
it easier to start Apache via rsh or crontab.
-<li><strong>Improved HTTP/1.1-style Virtual Hosts</strong><br>
+<LI><STRONG>Improved HTTP/1.1-style Virtual Hosts</STRONG><BR>
The new
- <a href="mod/core.html#namevirtualhost"><SAMP>NameVirtualHost</SAMP></a>
+ <A HREF="mod/core.html#namevirtualhost"><SAMP>NameVirtualHost</SAMP></A>
directive is used to list IP address:port
pairs on which HTTP/1.1-style virtual hosting occurs. This is
- vhosting based on the <code>Host:</code> header from the client.
+ vhosting based on the <CODE>Host:</CODE> header from the client.
Previously this address was implicitly the same as the "main address"
of the machine, and this caused no end of problems for users, and
was not powerful enough.
- Please see the <a href="vhosts/index.html">Apache Virtual Host
- documentation</a> for further details on configuration.
+ Please see the <A HREF="vhosts/index.html">Apache Virtual Host
+ documentation</A> for further details on configuration.
-<li><strong>API Additions</strong><br>
+<LI><STRONG>API Additions</STRONG><BR>
For all those module writers and code hackers:
- <ul>
- <li><strong><code>child_init</code> function for module API</strong><br>
+ <UL>
+ <LI><STRONG><CODE>child_init</CODE> function for module API</STRONG><BR>
A new phase for Apache's API is called once per "heavy-weight process,"
before any requests are handled. This allows the module to set up
anything that need to be done once per processes. For example,
connections to databases.
- <li><strong><code>child_exit</code> function for module API</strong><br>
+ <LI><STRONG><CODE>child_exit</CODE> function for module API</STRONG><BR>
A new phase called once per "heavy-weight process," when it is
terminating. Note that it can't be called in some fatal cases (such
- as segfaults and kill -9). The <code>child_init</code> and
- <code>child_exit</code> functions are passed a pool whose lifetime is
+ as segfaults and kill -9). The <CODE>child_init</CODE> and
+ <CODE>child_exit</CODE> functions are passed a pool whose lifetime is
the same as the lifetime of the child (modulo completely fatal
events in which apache has no hope of recovering). In contrast,
- the module <code>init</code> function is passed a pool whose lifetime
+ the module <CODE>init</CODE> function is passed a pool whose lifetime
ends when the parent exits or restarts.
- <li><strong><code>child_terminate</code></strong><br>
+ <LI><STRONG><CODE>child_terminate</CODE></STRONG><BR>
Used in the child to indicate the child should exit after finishing
the current request.
- <li><strong><code>register_other_child</code></strong><br>
- See <code>http_main.h</code>. This is used in the parent to register
+ <LI><STRONG><CODE>register_other_child</CODE></STRONG><BR>
+ See <CODE>http_main.h</CODE>. This is used in the parent to register
a child for monitoring. The parent will report status to a supplied
callback function. This allows modules to create their own children
which are monitored along with the httpd children.
- <li><strong><code>piped_log</code></strong><br>
- See <code>http_log.h</code>. This API provides the common code for
+ <LI><STRONG><CODE>piped_log</CODE></STRONG><BR>
+ See <CODE>http_log.h</CODE>. This API provides the common code for
implementing piped logs. In particular it implements a reliable piped
log on architectures supporting it (<EM>i.e.</EM>, Unix at the moment).
- <li><strong>MD5 functions renamed <code>ap_*</code></strong><br>
+ <LI><STRONG>MD5 functions renamed <CODE>ap_*</CODE></STRONG><BR>
MD5 functions renamed to avoid conflicts with other libraries.
- <li><strong>scoreboard format changed</strong><br>
+ <LI><STRONG>scoreboard format changed</STRONG><BR>
The scoreboard format is quite different. It is considered a
"private" interface in general, so it's only mentioned here as an FYI.
- <li><strong><code>set_last_modified</code> split into three</strong><br>
- The old function <code>set_last_modified</code> performed multiple
- jobs including the setting of the <code>Last-Modified</code> header, the
- <code>ETag</code> header, and processing conditional requests (such as
+ <LI><STRONG><CODE>set_last_modified</CODE> split into three</STRONG><BR>
+ The old function <CODE>set_last_modified</CODE> performed multiple
+ jobs including the setting of the <CODE>Last-Modified</CODE> header, the
+ <CODE>ETag</CODE> header, and processing conditional requests (such as
IMS). These functions have been split into three functions:
- <code>set_last_modified</code>, <code>set_etag</code>, and
- <code>meets_conditions</code>. The field <code>mtime</code> has been
- added to <code>request_rec</code> to facilitate
- <code>meets_conditions</code>.
+ <CODE>set_last_modified</CODE>, <CODE>set_etag</CODE>, and
+ <CODE>meets_conditions</CODE>. The field <CODE>mtime</CODE> has been
+ added to <CODE>request_rec</CODE> to facilitate
+ <CODE>meets_conditions</CODE>.
- <li><strong>New error logging function: <code>aplog_error</code></strong><br>
+ <LI><STRONG>New error logging function: <CODE>aplog_error</CODE></STRONG><BR>
All old logging functions are deprecated, we are in the process of
- replacing them with a single function called <code>aplog_error</code>.
+ replacing them with a single function called <CODE>aplog_error</CODE>.
This is still a work in progress.
- <li><strong><code>set_file_slot</code> for config parsing</strong><br>
- The <code>set_file_slot</code> routine provides a standard routine that
+ <LI><STRONG><CODE>set_file_slot</CODE> for config parsing</STRONG><BR>
+ The <CODE>set_file_slot</CODE> routine provides a standard routine that
prepends ServerRoot to non-absolute paths.
- <li><strong><code>post_read_request</code> module API</strong><br>
+ <LI><STRONG><CODE>post_read_request</CODE> module API</STRONG><BR>
This request phase occurs immediately after reading the request (headers),
and immediately after creating an internal redirect. It is most useful
for setting environment variables to affect future phases.
- <li><strong><code>psocket</code>, and <code>popendir</code></strong><br>
- The <code>psocket</code> and <code>pclosesocket</code> functions allow
+ <LI><STRONG><CODE>psocket</CODE>, and <CODE>popendir</CODE></STRONG><BR>
+ The <CODE>psocket</CODE> and <CODE>pclosesocket</CODE> functions allow
for race-condition free socket creation with resource tracking.
- Similarly <code>popendir</code> and <code>pclosedir</code> protect
+ Similarly <CODE>popendir</CODE> and <CODE>pclosedir</CODE> protect
directory reading.
- <li><strong><code>is_initial_req</code></strong><br>
+ <LI><STRONG><CODE>is_initial_req</CODE></STRONG><BR>
Test if the request is the initial request (<EM>i.e.</EM>, the one
coming from the client).
- <li><strong><code>kill_only_once</code></strong><br>
- An option to <code>spawn_child</code> functions which prevents Apache
+ <LI><STRONG><CODE>kill_only_once</CODE></STRONG><BR>
+ An option to <CODE>spawn_child</CODE> functions which prevents Apache
from aggressively trying to kill off the child.
- <li><strong><code>alloc debugging code</code></strong><br>
- Defining <code>ALLOC_DEBUG</code> provides a rudimentary memory
+ <LI><STRONG><CODE>alloc debugging code</CODE></STRONG><BR>
+ Defining <CODE>ALLOC_DEBUG</CODE> provides a rudimentary memory
debugger which can be used on live servers with low impact --
it sets all allocated and freed memory bytes to 0xa5. Defining
- <code>ALLOC_USE_MALLOC</code> will cause the alloc code to use
- <code>malloc()</code> and <code>free()</code> for each object. This
+ <CODE>ALLOC_USE_MALLOC</CODE> will cause the alloc code to use
+ <CODE>malloc()</CODE> and <CODE>free()</CODE> for each object. This
is far more expensive and should only be used for testing with tools
- such as Electric Fence and Purify. See <code>main/alloc.c</code>
+ such as Electric Fence and Purify. See <CODE>main/alloc.c</CODE>
for more details.
- </ul>
+ </UL>
<LI><STRONG>Year-2000 Improvements</STRONG>
<BR>
@@ -491,7 +491,7 @@
separate subdirectory and library so they can be used by other
applications than just the server.
</LI>
-</ul>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.11 +1 -1 apachen/htdocs/manual/process-model.html
Index: process-model.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/process-model.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- process-model.html 1997/07/06 17:18:56 1.10
+++ process-model.html 1998/01/26 16:53:37 1.11
@@ -63,6 +63,6 @@
</OL>
<!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
1.4 +61 -61 apachen/htdocs/manual/sections.html
Index: sections.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/sections.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- sections.html 1997/12/29 20:41:47 1.3
+++ sections.html 1998/01/26 16:53:37 1.4
@@ -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
@@ -12,12 +12,12 @@
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><Directory></code></a>, <a
-href="mod/core.html#location"><code><Location></code></a> and <a
-href="mod/core.html#files"><code><Files></code></a> can contain
+The sections <A
+HREF="mod/core.html#directory"><CODE><Directory></CODE></A>, <A
+HREF="mod/core.html#location"><CODE><Location></CODE></A> and <A
+HREF="mod/core.html#files"><CODE><Files></CODE></A> can contain
directives which only apply to specified directories, URLs or files
respectively. Also htaccess files can be used inside a directory to
apply directives to that directory. This document explains how these
@@ -28,112 +28,112 @@
<h2>Directives allowed in the sections</h2>
Everything that is syntactically allowed in
-<code><Directory></code> is also allowed in
-<code><Location></code> (except a sub-<code><Files></code>
+<CODE><Directory></CODE> is also allowed in
+<CODE><Location></CODE> (except a sub-<CODE><Files></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><Location></code>. The same for
-<code><Files></code> -- syntactically everything is fine, but
+<CODE><Location></CODE>. The same for
+<CODE><Files></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><Directory></code> (except regular expressions) and
+ <CODE><Directory></CODE> (except regular expressions) and
.htaccess done simultaneously (with .htaccess overriding
- <code><Directory></code>)
+ <CODE><Directory></CODE>)
-</li>
+</LI>
-<li>
- <code><DirectoryMatch></code>, and
- <code><Directory></code> with regular expressions
+<LI>
+ <CODE><DirectoryMatch></CODE>, and
+ <CODE><Directory></CODE> with regular expressions
-</li>
+</LI>
- <li><code><Files></code> and <code><FilesMatch></code> done simultaneously
- </li>
+ <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done simultaneously
+ </LI>
- <li><code><Location></code> and <code><LocationMatch></code> done simultaneously
- </li>
+ <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done simultaneously
+ </LI>
-</ol>
+</OL>
-Apart from <code><Directory></code>, each group is processed in
+Apart from <CODE><Directory></CODE>, each group is processed in
the order that they appear in the configuration
-files. <code><Directory></code> (group 1 above) is processed in
+files. <CODE><Directory></CODE> (group 1 above) is processed in
the order shortest directory component to longest. If multiple
-<code><Directory></code> sections apply to the same directory
+<CODE><Directory></CODE> sections apply to the same directory
they they are processed in the configuration file order. The
configuration files are read in the order httpd.conf, srm.conf and
-access.conf. Configurations included via the <code>Include</code>
+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><VirtualHost></code> sections are applied
-<i>after</i> the corresponding sections outside the virtual host
+Sections inside <CODE><VirtualHost></CODE> sections are applied
+<EM>after</EM> the corresponding sections outside the virtual host
definition. This allows virtual hosts to override the main server
configuration. (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><Directory></code> and/or
- <code><Files></code>.
-</li>
+ then you must use <CODE><Directory></CODE> and/or
+ <CODE><Files></CODE>.
+</LI>
-<li>
+<LI>
If you are attempting to match objects at the URL level then you
- must use <code><Location></code>
-</li>
-</ul>
+ must use <CODE><Location></CODE>
+</LI>
+</UL>
But a notable exception is:
-<ul>
-<li>
- proxy control is done via <code><Directory></code>. This is
+<UL>
+<LI>
+ proxy control is done via <CODE><Directory></CODE>. This is
a legacy mistake because the proxy existed prior to
- <code><Location></code>. A future version of the config
+ <CODE><Location></CODE>. A future version of the config
language should probably switch this to
- <code><Location></code>.
-</li>
-</ul>
+ <CODE><Location></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><Location></code>/<code><LocationMatch></code>
+ <CODE><Location></CODE>/<CODE><LocationMatch></CODE>
sequence performed just before the name translation phase (where
- <code>Aliases</code> and <code>DocumentRoots</code> are used to
+ <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>
1.7 +48 -48 apachen/htdocs/manual/sourcereorg.html
Index: sourcereorg.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/sourcereorg.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- sourcereorg.html 1997/12/29 20:41:47 1.6
+++ sourcereorg.html 1998/01/26 16:53:38 1.7
@@ -13,7 +13,7 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Source Re-organisation</h1>
+<h1 ALIGN="CENTER">Source Re-organisation</H1>
As of 1.3, the Apache source directories have been re-organised. This
re-organisation is designed to simplify the directory structure,
@@ -24,42 +24,42 @@
<h2>Summary of Changes</h2>
The source directory changes are:
-<ul>
- <li>The non-module source files have moved from <CODE>src</CODE> into
+<UL>
+ <LI>The non-module source files have moved from <CODE>src</CODE> into
<CODE>src/main</CODE>
- </li>
- <li>The module source files previously in <CODE>src</CODE> have moved
+ </LI>
+ <LI>The module source files previously in <CODE>src</CODE> have moved
to <CODE>src/modules/standard</CODE>
- </li>
- <li>The <CODE>support</CODE> directory is now in <CODE>src/support</CODE>
- </li>
-</ul>
+ </LI>
+ <LI>The <CODE>support</CODE> directory is now in <CODE>src/support</CODE>
+ </LI>
+</UL>
In addition, the following enhancements have been made:
-<ul>
- <li>OS abstractions can be added in the <CODE>src/os</CODE> directory.
+<UL>
+ <LI>OS abstractions can be added in the <CODE>src/os</CODE> directory.
Currently this contains information for unix, OS/2 and Windows 32
platforms.
- </li>
- <li><CODE>Configuration</CODE> syntax has been simplified for adding new
+ </LI>
+ <LI><CODE>Configuration</CODE> syntax has been simplified for adding new
modules. Users no longer need to enter the module's structure name.
In addition, new modules can be located anywhere on the
file system, or typically in new or existing directories under
<CODE>src/modules</CODE>.
- </li>
- <li>Module authors can give simpler instructions for adding their modules
+ </LI>
+ <LI>Module authors can give simpler instructions for adding their modules
to Apache compilation. They can also now provide compile time information
required by <CODE>Configure</CODE>, such as additional libraries
required.
- </li>
- <li>Module authors can distribute pre-compiled (.a or .o) versions of their
+ </LI>
+ <LI>Module authors can distribute pre-compiled (.a or .o) versions of their
modules if required, along with a "module definition file" which
contains the information required by <CODE>Configure</CODE>.
- </li>
- <li>All the sub-directories (main, modules/* and os/*) are built as
+ </LI>
+ <LI>All the sub-directories (main, modules/* and os/*) are built as
libraries.
-</ul>
+</UL>
<h2>Adding Modules</h2>
@@ -89,17 +89,17 @@
file, say mod_foo.c, then the recommended way to add the module to
Apache is as follows:
-<ul>
- <li>Put <CODE>mod_foo.c</CODE> into the directory
+<UL>
+ <LI>Put <CODE>mod_foo.c</CODE> into the directory
<CODE>src/modules/extra</CODE>
- </li>
- <li>Go to the <CODE>src</CODE> directory and add the following line
- to <CODE>Configuration</CODE><br>
+ </LI>
+ <LI>Go to the <CODE>src</CODE> directory and add the following line
+ to <CODE>Configuration</CODE><BR>
<CODE>AddModule modules/extra/mod_foo.o</CODE>
- </li>
- <li>Run <CODE>./Configure</CODE></li>
- <li>Run <CODE>make</CODE></li>
-</ul>
+ </LI>
+ <LI>Run <CODE>./Configure</CODE></LI>
+ <LI>Run <CODE>make</CODE></LI>
+</UL>
<h2>New Facilities for Module Authors</h2>
@@ -114,26 +114,26 @@
From Apache 1.3 onwards, module authors can make use of these new features:
-<ul>
- <li>Simplified <CODE>Configuration</CODE> command AddModule which only
+<UL>
+ <LI>Simplified <CODE>Configuration</CODE> command AddModule which only
requires a path to the module source or object file
- </li>
- <li>If the module requires compile time options (such as extra
+ </LI>
+ <LI>If the module requires compile time options (such as extra
libraries) these can be specified in the module file source
or an external "module definition file".
- </li>
- <li>If a module is distributed as binary (.o or .a) then an external
+ </LI>
+ <LI>If a module is distributed as binary (.o or .a) then an external
"module definition file" can also be distributed which gives
the information Configure needs to add the module, such as extra
libraries and the module's structure name.
- <li>Modules can be installed anywhere on the file system, although a directory
+ <LI>Modules can be installed anywhere on the file system, although a directory
under <CODE>src/modules</CODE> is recommended.
- </li>
- <li>If the module is in its own directory, Apache can automatically
+ </LI>
+ <LI>If the module is in its own directory, Apache can automatically
create a Makefile to build the module given a file containing
the module's dependencies.
- </li>
-</ul>
+ </LI>
+</UL>
The rest of this document shows how to package modules for Apache 1.3
and later and what to tell end-users of the module.
@@ -145,10 +145,10 @@
should consist of two files, in a suitable directory name. For
example:
-<ul>
- <li>mod_demo/mod_demo.c
- <li>mod_demo/Makefile.tmpl
-</ul>
+<UL>
+ <LI>mod_demo/mod_demo.c
+ <LI>mod_demo/Makefile.tmpl
+</UL>
(Of course end-user instructions, README's, etc can also be supplied
in the archive). The end user should be told to extract this archive
@@ -157,9 +157,9 @@
<CODE>src/modules/mod_demo</CODE>. Then they need to add the following
line to the <CODE>Configuration</CODE> file:
-<pre>
+<PRE>
AddModule modules/mod_demo/mod_demo.o
-</pre>
+</PRE>
then run <CODE>Configure</CODE> and <CODE>make</CODE> as normal.
@@ -182,8 +182,8 @@
If the module also comes with header files, these can be added to the
archive. If the module consists of multiple source files it can be
built into a library file using a supplied makefile. In this case,
-distribute the makefile as <CODE>mod_demo/Makefile</CODE> and <b>do
-not</b> include a <CODE>mod_demo/Makefile.tmpl</CODE>. If
+distribute the makefile as <CODE>mod_demo/Makefile</CODE> and <STRONG>do
+not</STRONG> include a <CODE>mod_demo/Makefile.tmpl</CODE>. If
<CODE>Configure</CODE> sees a <CODE>Makefile.tmpl</CODE> it assumes it
is safe to overwrite any existing <CODE>Makefile</CODE>.
1.10 +42 -42 apachen/htdocs/manual/stopping.html
Index: stopping.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/stopping.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- stopping.html 1997/10/25 22:35:08 1.9
+++ stopping.html 1998/01/26 16:53:38 1.10
@@ -13,34 +13,34 @@
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 @@
<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 @@
<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 @@
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 @@
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
1.15 +12 -12 apachen/htdocs/manual/suexec.html
Index: suexec.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/suexec.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- suexec.html 1997/10/25 22:35:09 1.14
+++ suexec.html 1998/01/26 16:53:39 1.15
@@ -268,11 +268,11 @@
<P ALIGN="LEFT">
<STRONG>EDITING THE SUEXEC HEADER FILE</STRONG><BR>
- From the top-level of the Apache source tree, type:
-<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 @@
<STRONG>COMPILING THE SUEXEC WRAPPER</STRONG><BR>
You now need to compile the suEXEC wrapper. At the shell command prompt,
type: <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 @@
<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 @@
<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 @@
<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><VirtualHost></STRONG>. If only one or
neither of these directives are specified for a
<STRONG><VirtualHost></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 @@
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 @@
<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>
1.6 +11 -11 apachen/htdocs/manual/unixware.html
Index: unixware.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/unixware.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- unixware.html 1997/06/04 11:07:52 1.5
+++ unixware.html 1998/01/26 16:53:39 1.6
@@ -23,16 +23,16 @@
<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 @@
<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 <JRD@cc.usu.edu> and Rich Vaughn
-<rvaughn@aad.com> for additional info for UnixWare builds.<p>
+<rvaughn@aad.com> for additional info for UnixWare builds.<P>
<!--#include virtual="footer.html" -->
</BODY>
1.9 +58 -58 apachen/htdocs/manual/upgrading_to_1_3.html
Index: upgrading_to_1_3.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/upgrading_to_1_3.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- upgrading_to_1_3.html 1998/01/23 00:36:29 1.8
+++ upgrading_to_1_3.html 1998/01/26 16:53:40 1.9
@@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html><head>
-<title>Upgrading to 1.3 from 1.2</title>
-</head>
+<HTML><HEAD>
+<TITLE>Upgrading to 1.3 from 1.2</TITLE>
+</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
@@ -12,57 +12,57 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Upgrading to 1.3 from 1.2</h1>
+<h1 ALIGN="CENTER">Upgrading to 1.3 from 1.2</H1>
-<p>In order to assist folks upgrading we are now going to maintain a
+<P>In order to assist folks upgrading we are now going to maintain a
document describing information critical to existing Apache users. Note
that it only lists differences between recent major releases, so
for example, folks using Apache 1.1 or earlier will have to figure out
what changed up to Apache 1.2 before this document can be considered
-relevant. Old users could look at the <code>src/CHANGES</code> file
+relevant. Old users could look at the <CODE>src/CHANGES</CODE> file
which tracks code changes.
-<p>These are intended to be brief notes, and you should be able to find
-more information in either the <a href="new_features_1_3.html">New Features</a>
-document, or in the <code>src/CHANGES</code> file.
+<P>These are intended to be brief notes, and you should be able to find
+more information in either the <A HREF="new_features_1_3.html">New Features</A>
+document, or in the <CODE>src/CHANGES</CODE> file.
<h3>Compile-Time Configuration Changes</h3>
-<ul>
- <LI>The source code has been <a href="sourcereorg.html">reorganized</a>,
+<UL>
+ <LI>The source code has been <A HREF="sourcereorg.html">reorganized</A>,
which affects anyone with custom modules or modifications. But also,
- the <code>Module</code> directive has been changed to the
- <code>AddModule</code> directive.
+ the <CODE>Module</CODE> directive has been changed to the
+ <CODE>AddModule</CODE> directive.
- <LI>The <code>Configuration</code> variable <code>EXTRA_LFLAGS</code> has
- been renamed <code>EXTRA_LDFLAGS</code>.
+ <LI>The <CODE>Configuration</CODE> variable <CODE>EXTRA_LFLAGS</CODE> has
+ been renamed <CODE>EXTRA_LDFLAGS</CODE>.
- <LI>The <code>-DMAXIMUM_DNS</code> definition has been obsoleted by
- changes to <code>mod_access</code> enforcing double-reverse DNS lookups
+ <LI>The <CODE>-DMAXIMUM_DNS</CODE> definition has been obsoleted by
+ changes to <CODE>mod_access</CODE> enforcing double-reverse DNS lookups
when necessary.
- <LI><code>mod_dir</code> has been split into two pieces
- <code><a href="mod/mod_autoindex.html">mod_autoindex</a></code>, and
- <code><a href="mod/mod_dir.html">mod_dir</a></code>.
+ <LI><CODE>mod_dir</CODE> has been split into two pieces
+ <CODE><A HREF="mod/mod_autoindex.html">mod_autoindex</A></CODE>, and
+ <CODE><A HREF="mod/mod_dir.html">mod_dir</A></CODE>.
- <LI><a href="mod/mod_browser.html"><code>mod_browser</code></a> has been
- replaced by <a href="mod/mod_setenvif.html"><code>mod_setenvif</code></a>.
+ <LI><A HREF="mod/mod_browser.html"><CODE>mod_browser</CODE></A> has been
+ replaced by <A HREF="mod/mod_setenvif.html"><CODE>mod_setenvif</CODE></A>.
<LI>IRIX systems with untrusted users who can write CGIs which execute
- as the same uid as httpd should consider using <code>suexec</code>,
- or adding <code>-DUSE_FCNTL_SERIALIZED_ACCEPT</code> to
- <code>EXTRA_CFLAGS</code>. This is slower, more information is available
- on the <a href="misc/perf-tuning.html#serialize">performance tuning
- page</a>. There is a mild denial of service attack possible with the
+ as the same uid as httpd should consider using <CODE>suexec</CODE>,
+ or adding <CODE>-DUSE_FCNTL_SERIALIZED_ACCEPT</CODE> to
+ <CODE>EXTRA_CFLAGS</CODE>. This is slower, more information is available
+ on the <A HREF="misc/perf-tuning.html#serialize">performance tuning
+ page</A>. There is a mild denial of service attack possible with the
default config, but the default config is an order of magnitude faster.
- <li><code>mod_auth_msql</code> has been removed from the distribution.
+ <LI><CODE>mod_auth_msql</CODE> has been removed from the distribution.
-</ul>
+</UL>
<h3>Run-Time Configuration Changes</h3>
-<ul>
+<UL>
<LI><STRONG>The default Apache ServerRoot directory changed</STRONG>
from the NCSA-compatible <SAMP>/usr/local/etc/httpd/</SAMP> to
<SAMP>/usr/local/apache/</SAMP>. This change covers only the default
@@ -70,60 +70,60 @@
using the <EM>-d ServerRoot</EM> and <EM>-f httpd.conf</EM> switches
when starting apache.
- <li>Folks using HTTP/1.1-style virtual hosting will need to list the
+ <LI>Folks using HTTP/1.1-style virtual hosting will need to list the
ip:port pairs that are supposed to have HTTP/1.1-style virtual hosting
- via the <a href="mod/core.html#namevirtualhost"><code>
- NameVirtualHost</code></a> directive. Previously this support was
+ via the <A HREF="mod/core.html#namevirtualhost"><CODE>
+ NameVirtualHost</CODE></A> directive. Previously this support was
given implicitly on the "main server address". Now it has to be
explicitly listed so as to avoid many problems that users had.
- Please see the <a href="vhosts/index.html">Apache Virtual Host
- documentation</a> for further details on configuration.
+ Please see the <A HREF="vhosts/index.html">Apache Virtual Host
+ documentation</A> for further details on configuration.
- <li>The precedence of virtual hosts has been reversed (applies mainly to
+ <LI>The precedence of virtual hosts has been reversed (applies mainly to
vhosts using HTTP/1.1 Host: headers, and the
- <a href="mod/core.html#serverpath">ServerPath</a> directive). Now
+ <A HREF="mod/core.html#serverpath">ServerPath</A> directive). Now
the earlier vhosts in the file have precedence over the later vhosts.
- <li><code>HostnameLookups</code> defaults to Off.
+ <LI><CODE>HostnameLookups</CODE> defaults to Off.
- <li>The undocumented
- <a href="mod/mod_access.html"><code>mod_access</code></a>
+ <LI>The undocumented
+ <A HREF="mod/mod_access.html"><CODE>mod_access</CODE></A>
syntax "allow user-agents" was removed. The replacement is the
more general "allow from env".
- <li>When using wildcards in pathnames (such as * and ?) they no longer
+ <LI>When using wildcards in pathnames (such as * and ?) they no longer
match / (slash). That is, they more closely behave how a UNIX shell
- behaves. This affects <code><Directory></code> directives,
+ behaves. This affects <CODE><Directory></CODE> directives,
for example.
- <li>If no <code>TransferLog</code> directive is given then nothing will
+ <LI>If no <CODE>TransferLog</CODE> directive is given then nothing will
be logged.
- (Previously it would default to <code>logs/access_log</code>.)
+ (Previously it would default to <CODE>logs/access_log</CODE>.)
- <li>Apache now has <a href="mod/core.html#loglevel">configurable error
- logging levels</a>, and the default eliminates some messages that
+ <LI>Apache now has <A HREF="mod/core.html#loglevel">configurable error
+ logging levels</A>, and the default eliminates some messages that
earlier versions always generated.
- <li>When booting, Apache will now detach itself from stdin, stdout,
+ <LI>When booting, Apache will now detach itself from stdin, stdout,
and stderr. stderr will not be detached until after the config
files have been read so you will be able to see initial error
messages. After that all errors are logged in the error_log.
This makes it more convenient to start Apache via rsh, ssh,
or crontabs.
-</ul>
+</UL>
<h3>Misc Changes</h3>
-<ul>
- <li><code>ServerType inetd</code> has been deprecated. It still exists,
+<UL>
+ <LI><CODE>ServerType inetd</CODE> has been deprecated. It still exists,
but bugs are unlikely to be fixed.
- <li><code>httpd_monitor</code> has been deprecated. The replacement is
- to use <code>mod_status</code> and make a request to a URL such as
- <code>http://myhost/server-status?refresh=10</code>.
+ <LI><CODE>httpd_monitor</CODE> has been deprecated. The replacement is
+ to use <CODE>mod_status</CODE> and make a request to a URL such as
+ <CODE>http://myhost/server-status?refresh=10</CODE>.
- <li>
+ <LI>
Apache now provides an effectively unbuffered connection for
CGI scripts. This means that data will be sent to the client
as soon as the CGI pauses or stops output; previously, Apache would
@@ -134,17 +134,17 @@
in a language that by default does buffering (e.g. perl) this
shouldn't have a detrimental effect on performance.
- <p>"nph-" CGIs, which formerly provided a direct socket to the client
+ <P>"nph-" CGIs, which formerly provided a direct socket to the client
without any server post-processing, were not fully compatible with
HTTP/1.1 or SSL support. As such they would have had to implement
the transport details, such as encryption or chunking, in order
to work properly in certain situations. Now, the only difference
between nph and non-nph scripts is "non-parsed headers".
- <li>
- <code>dbmmanage</code> has been overhauled.
+ <LI>
+ <CODE>dbmmanage</CODE> has been overhauled.
-</ul>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.9 +131 -131 apachen/htdocs/manual/windows.html
Index: windows.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/windows.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- windows.html 1998/01/20 18:32:55 1.8
+++ windows.html 1998/01/26 16:53:40 1.9
@@ -16,215 +16,215 @@
<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>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
+<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>
+
+<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>
-
-<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>
+ <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>
-<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>
1.11 +315 -315 apachen/htdocs/manual/misc/API.html
Index: API.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/API.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- API.html 1997/07/06 17:19:04 1.10
+++ API.html 1998/01/26 16:53:47 1.11
@@ -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"
@@ -11,16 +11,16 @@
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 @@
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>
+<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>
+<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 -> 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 -> 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 @@
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 @@
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 @@
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><Directory></code> sections), for private data it has
+directory (via <CODE>.htaccess</CODE> files or
+<CODE><Directory></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 @@
};
-</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 @@
pfclose (r->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->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->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->prev</code> and <code>r->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->prev</CODE> and <CODE>r->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 @@
<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 @@
foo = (foo *)palloc (r->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 @@
<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->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->pool, r->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 @@
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 @@
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 -> 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><Directory></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><Directory /></code>).<p>
+<EM>merged</EM> with the applicable information from the server's own
+config files (either from the <CODE><Directory></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><Directory /></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><Directory></code> section, which includes one of the MIME
-module's commands, it needs to create a <code>mime_dir_config</code>
+<CODE><Directory></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 @@
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 @@
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 @@
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->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 @@
"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 @@
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 @@
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->server;
@@ -999,6 +999,6 @@
new->fake = f; new->real = url;
return NULL;
}
-</pre>
+</PRE>
<!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
1.104 +3 -3 apachen/htdocs/manual/misc/FAQ.html
Index: FAQ.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/FAQ.html,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -r1.103 -r1.104
--- FAQ.html 1998/01/26 07:09:13 1.103
+++ FAQ.html 1998/01/26 16:53:48 1.104
@@ -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
@@ -1957,7 +1957,7 @@
</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
@@ -1967,7 +1967,7 @@
<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
1.8 +21 -21 apachen/htdocs/manual/misc/client_block_api.html
Index: client_block_api.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/client_block_api.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- client_block_api.html 1997/07/06 17:19:05 1.7
+++ client_block_api.html 1998/01/26 16:53:49 1.8
@@ -13,73 +13,73 @@
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>
1.18 +15 -15 apachen/htdocs/manual/misc/compat_notes.html
Index: compat_notes.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/compat_notes.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- compat_notes.html 1997/11/08 23:27:59 1.17
+++ compat_notes.html 1998/01/26 16:53:49 1.18
@@ -21,8 +21,8 @@
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 @@
<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 @@
<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 @@
<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 @@
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 @@
<LI>Apache's <CODE><VirtualHost></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
1.7 +50 -50 apachen/htdocs/manual/misc/descriptors.html
Index: descriptors.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/descriptors.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- descriptors.html 1997/07/22 22:39:31 1.6
+++ descriptors.html 1998/01/26 16:53:49 1.7
@@ -15,11 +15,11 @@
<!--#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 @@
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 @@
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 <= soft limit <= hard limit <= 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 @@
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 @@
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>.
+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
+<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" -->
1.14 +1 -1 apachen/htdocs/manual/misc/fin_wait_2.html
Index: fin_wait_2.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/fin_wait_2.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- fin_wait_2.html 1998/01/26 06:58:31 1.13
+++ fin_wait_2.html 1998/01/26 16:53:50 1.14
@@ -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
1.5 +29 -29 apachen/htdocs/manual/misc/howto.html
Index: howto.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/howto.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- howto.html 1998/01/26 07:12:58 1.4
+++ howto.html 1998/01/26 16:53:50 1.5
@@ -18,49 +18,49 @@
<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 @@
<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 @@
<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 @@
<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
1.9 +1 -1 apachen/htdocs/manual/misc/index.html
Index: index.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/index.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- index.html 1997/11/06 02:55:07 1.8
+++ index.html 1998/01/26 16:53:51 1.9
@@ -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
1.41 +46 -46 apachen/htdocs/manual/misc/known_bugs.html
Index: known_bugs.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/known_bugs.html,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- known_bugs.html 1997/12/04 22:22:47 1.40
+++ known_bugs.html 1998/01/26 16:53:51 1.41
@@ -44,24 +44,24 @@
(Neither do servers operating with the -X command line switch for
debugging.)
This will be corrected in a later beta. A workaround for now is
- to edit <code>src/main/httpd.h</code> and remove the definition
- of <code>OPTIMIZE_TIMEOUTS</code> near the bottom.
-<LI><b>Win32 only:</b> Building from source may fail because the buildmark.obj
+ to edit <CODE>src/main/httpd.h</CODE> and remove the definition
+ of <CODE>OPTIMIZE_TIMEOUTS</CODE> near the bottom.
+<LI><STRONG>Win32 only:</STRONG> Building from source may fail because the buildmark.obj
file does not exist. Edit <CODE>Makefile.nt</CODE> and replace the
line <CODE>del CoreR\buildmark.obj</CODE> with <CODE>-del
CoreR\buildmark.obj</CODE> (and similarly for <CODE>del
CoreD\buildmark.obj</CODE>). See
<A HREF="http://bugs.apache.org/index/full/1473">PR#1473</A>.
-<LI><b>Solaris 2.6</b> users may have troubles compiling the server with
+<LI><STRONG>Solaris 2.6</STRONG> users may have troubles compiling the server with
gcc. As is frequently the case with gcc compilation troubles, this
is the result of an improperly built gcc. The gcc for solaris 2.6
- found at <a href="http://www.sunfreeware.com/">www.sunfreeware.com</a>
+ found at <A HREF="http://www.sunfreeware.com/">www.sunfreeware.com</A>
was built with a beta version of solaris 2.6. The release version
of solaris 2.6 changed a few header files enough that the beta-built
gcc won't work with it. There are two workarounds mentioned in
- <a href="http://bugs.apache.org/index/full/1336">PR#1336</a>.
- <b>This is not an Apache bug, and no code will be changed to deal with
- it.</b>
+ <A HREF="http://bugs.apache.org/index/full/1336">PR#1336</A>.
+ <STRONG>This is not an Apache bug, and no code will be changed to deal with
+ it.</STRONG>
</OL>
<H2>Apache 1.3b2 Bugs</H2>
@@ -94,35 +94,35 @@
<H2>Apache 1.3a1 Bugs</H2>
<OL>
- <LI>The <code><a href="../mod/core.html#listen">Listen</a></code>
+ <LI>The <CODE><A HREF="../mod/core.html#listen">Listen</A></CODE>
directive does not work when running under Windows.
- <LI>For some reason, <a href="../mod/mod_isapi.html">mod_isapi</a>
+ <LI>For some reason, <A HREF="../mod/mod_isapi.html">mod_isapi</A>
does not work (with Windows) when compiled using the
- <code>Release</code> setting; it will crash the server whenever you
+ <CODE>Release</CODE> setting; it will crash the server whenever you
access an ISA DLL. It works fine when the server is compiled with
- <code>Debug</code>.
+ <CODE>Debug</CODE>.
</OL>
<H2>Apache 1.2 Bugs</H2>
<H3>Bugs still present in 1.2.4</H3>
<OL>
- <LI><a name="listenbug">On some architectures</A>
+ <LI><A name="listenbug">On some architectures</A>
if your configuration uses multiple
- <a href="../mod/core.html#listen">Listen</a> directives then it is possible
+ <A HREF="../mod/core.html#listen">Listen</A> directives then it is possible
that the server will starve one of the sockets while serving hits on
another. The work-around is to add
- <code>-DUSE_FLOCK_SERIALIZED_ACCEPT</code> to the
- <code>EXTRA_CFLAGS</code> line in your Configuration and rebuild.
+ <CODE>-DUSE_FLOCK_SERIALIZED_ACCEPT</CODE> to the
+ <CODE>EXTRA_CFLAGS</CODE> line in your Configuration and rebuild.
(If you encounter problems with that, you can also try
- <code>-DUSE_FCNTL_SERIALIZED_ACCEPT</code>.)
+ <CODE>-DUSE_FCNTL_SERIALIZED_ACCEPT</CODE>.)
This affects any architecture that doesn't use one of the
- <code>USE_xxxxx_SERIALIZED_ACCEPT</code> definitions, see the
- source file <code>conf.h</code> for your architecture.
+ <CODE>USE_xxxxx_SERIALIZED_ACCEPT</CODE> definitions, see the
+ source file <CODE>conf.h</CODE> for your architecture.
This is being tracked as
- <a href="http://www.apache.org/bugdb.cgi/full/467">PR#467</a>.
+ <A HREF="http://www.apache.org/bugdb.cgi/full/467">PR#467</A>.
<P>To resolve this problem, we are adding one of the above settings
to the default settings for platforms as we discover which is
- appropriate for them. <b>New as of 1.3b3:</b> the server will
+ appropriate for them. <STRONG>New as of 1.3b3:</STRONG> the server will
issue a warning when your architecture/config are subject to
this bug. The fixes and such are described in the PORTING
file. We are closing out this bug.
@@ -169,7 +169,7 @@
<LI>The message "<CODE>created shared memory segment #730499</CODE>"
in error_log is not an error and should be ignored. See
- <a href="http://www.apache.org/bugdb.cgi/full/696">PR#696</A>.
+ <A HREF="http://www.apache.org/bugdb.cgi/full/696">PR#696</A>.
</LI><P>
</OL>
@@ -177,41 +177,41 @@
<OL>
<LI>
On Solaris 2.x the server will stop running after receiving a
- SIGHUP. Four workarounds exist (choose one):<p>
- <ul>
- <li>Recommended: upgrade to 1.2.4.
- <li>If you are running Apache 1.2.1, retrieve
- <a href="http://www.apache.org/dist/patches/apply_to_1.2.1/solaris_hup.patch">this patch</a>.
- <code>cd</code> to your <code>apache_1.2.1</code> directory, and
- type <code>patch -s -p1 < /path/to/patchfile</code>. Then rebuild
- Apache.<p>
- <li>Use SIGUSR1 instead of SIGHUP, see <a href="../stopping.html">
- Stopping and Restarting Apache</a> for more details.<p>
- <li>Add <code>-DNO_SLACK</code> to
- <code>EXTRA_CFLAGS</code> in
- your <code>Configuration</code> file, re-run <code>Configure</code>
+ SIGHUP. Four workarounds exist (choose one):<P>
+ <UL>
+ <LI>Recommended: upgrade to 1.2.4.
+ <LI>If you are running Apache 1.2.1, retrieve
+ <A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/solaris_hup.patch">this patch</A>.
+ <CODE>cd</CODE> to your <CODE>apache_1.2.1</CODE> directory, and
+ type <CODE>patch -s -p1 < /path/to/patchfile</CODE>. Then rebuild
+ Apache.<P>
+ <LI>Use SIGUSR1 instead of SIGHUP, see <A HREF="../stopping.html">
+ Stopping and Restarting Apache</A> for more details.<P>
+ <LI>Add <CODE>-DNO_SLACK</CODE> to
+ <CODE>EXTRA_CFLAGS</CODE> in
+ your <CODE>Configuration</CODE> file, re-run <CODE>Configure</CODE>
and rebuild your server. This disables the
- <a href="descriptors.html">descriptor slack workaround</a>
- </ul><P>
+ <A HREF="descriptors.html">descriptor slack workaround</A>
+ </UL><P>
This problem was tracked as
- <a href="http://www.apache.org/bugdb.cgi/full/832">PR#832</a>.
- </li><P>
+ <A HREF="http://www.apache.org/bugdb.cgi/full/832">PR#832</A>.
+ </LI><P>
<LI>(Exists in 1.2.0 and in 1.2.1 after either of the
- <code>NO_SLACK</code> or patch provided by the previous bug are applied.)
+ <CODE>NO_SLACK</CODE> or patch provided by the previous bug are applied.)
Solaris 2.5.1 (and probably other versions of Solaris) appear to have
a race condition completely unrelated to all the others. It is possible
during a SIGHUP that the server will fail to start because it will not
be able to re-open its sockets. To our knowledge this has only shown
up during testing when we pummel the server with as many SIGHUP requests
per second as we can. This appears unrelated to the similar sounding bug
- described in <a href="http://www.apache.org/bugdb.cgi/full/832">PR#832</a>.
+ described in <A HREF="http://www.apache.org/bugdb.cgi/full/832">PR#832</A>.
</OL>
<P>
<H3>Fixed in 1.2.1</H3>
<OL>
- <LI><a href="descriptors.html"><B>Workaround added</B></a>
+ <LI><A HREF="descriptors.html"><STRONG>Workaround added</STRONG></A>
There appears to be a problem on BSDI 2.1 with large numbers of
virtual hosts. This appears similar to a file-descriptor limit
but BSDI should not have this problem. This will be tracked as
@@ -219,14 +219,14 @@
See also the <A HREF="FAQ.html#fdlim">Apache FAQ</A>.
</LI><P>
- <LI><a href="descriptors.html"><b>Workaround added.</b></a>
+ <LI><A HREF="descriptors.html"><STRONG>Workaround added.</STRONG></A>
Solaris 2 has problems with large numbers of virtual hosts. This is
because of an operating system limit of 256 file pointers, not due
to Apache. See also the <A HREF="FAQ.html#fdlim">Apache FAQ</A>.
</LI><P>
<LI>
- <a name="cnegbug">Apache's</A> <A HREF="../content-negotiation.html">Content
+ <A name="cnegbug">Apache's</A> <A HREF="../content-negotiation.html">Content
Negotiation</A> should pick the smallest variant if there
are several that are equally acceptable. A bug in 1.2 means it no
longer does this unless all the variants have character sets.
@@ -234,12 +234,12 @@
fixes this problem. It also fixes the problem which makes Apache
pick the last equally acceptable variant instead of the first.
This will be tracked as
- <a href="http://www.apache.org/bugdb.cgi/full/94">PR#94</a>.
+ <A HREF="http://www.apache.org/bugdb.cgi/full/94">PR#94</A>.
</LI><P>
<LI><P>Compilation fails on SCO3 when using gcc instead of cc, complaining
with "<CODE>gcc: noinline: No such file or directory</CODE>". Fix
- is given in <a href="http://www.apache.org/bugdb.cgi/full/695">PR#695</A>.
+ is given in <A HREF="http://www.apache.org/bugdb.cgi/full/695">PR#695</A>.
</LI>
</OL>
1.7 +86 -86 apachen/htdocs/manual/misc/known_client_problems.html
Index: known_client_problems.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/known_client_problems.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- known_client_problems.html 1998/01/22 21:09:42 1.6
+++ known_client_problems.html 1998/01/26 16:53:52 1.7
@@ -15,119 +15,119 @@
<!--#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 @@
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 @@
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>.
+<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>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>
+<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>
1.7 +2 -2 apachen/htdocs/manual/misc/nopgp.html
Index: nopgp.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/nopgp.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- nopgp.html 1997/07/06 17:19:06 1.6
+++ nopgp.html 1998/01/26 16:53:52 1.7
@@ -19,7 +19,7 @@
any copies of NCSA httpd prior to 1.4.1 from our web site. They
were mandated by the NSA to inform us that redistribution of pre-1.4.1
code violated the same laws that make distributing Phill Zimmerman's
-PGP package to other countries illegal. There was <B>no</B>
+PGP package to other countries illegal. There was <STRONG>no</STRONG>
encryption in NCSA's httpd, only hooks to publicly available libraries
of PEM code. By the NSA's rules, even hooks to this type of
application is illegal.
@@ -81,7 +81,7 @@
ICLU - Your Rights in Cyberspace</A>
</UL>
- <a href="http://www.behlendorf.com/~brian/">Brian</a>, <a href="mailto:brian@hyperreal.org">brian@hyperreal.org</a>
+ <A HREF="http://www.behlendorf.com/~brian/">Brian</A>, <A HREF="mailto:brian@hyperreal.org">brian@hyperreal.org</A>
<!--#include virtual="footer.html" -->
</BODY>
1.9 +59 -59 apachen/htdocs/manual/misc/perf-bsd44.html
Index: perf-bsd44.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/perf-bsd44.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- perf-bsd44.html 1997/07/06 17:19:06 1.8
+++ perf-bsd44.html 1998/01/26 16:53:53 1.9
@@ -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
@@ -17,28 +17,28 @@
</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 <agifford@InfoWest.COM>"
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 @@
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 <chuck@telebase.com>
-<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 @@
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 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 @@
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 @@
* 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 @@
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 @@
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 @@
# 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" <mi@ALDAN.ziplink.net> 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>
1.6 +2 -2 apachen/htdocs/manual/misc/perf-dec.html
Index: perf-dec.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/perf-dec.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- perf-dec.html 1997/07/06 17:19:07 1.5
+++ perf-dec.html 1998/01/26 16:53:53 1.6
@@ -32,10 +32,10 @@
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
1.3 +6 -6 apachen/htdocs/manual/misc/perf-hp.html
Index: perf-hp.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/perf-hp.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- perf-hp.html 1997/12/29 20:41:49 1.2
+++ perf-hp.html 1998/01/26 16:53:55 1.3
@@ -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 @@
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 @@
<A HREF="./"><IMG SRC="../images/index.gif" ALT="Index"></A>
<A HREF="../"><IMG SRC="../images/home.gif" ALT="Home"></A>
-</body></html>
+</BODY></HTML>
1.6 +251 -251 apachen/htdocs/manual/misc/perf-tuning.html
Index: perf-tuning.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/perf-tuning.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- perf-tuning.html 1998/01/23 00:36:32 1.5
+++ perf-tuning.html 1998/01/26 16:53:55 1.6
@@ -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 @@
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 @@
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 @@
<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><Location /server-status></code> section. In this
+<P>Note that it's possible to scope the directives, such as within
+a <CODE><Location /server-status></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
<Files ~ "\.(html|cgi)$>
HostnameLookups on
</Files>
-</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
<Directory />
Options SymLinksIfOwnerMatch
</Directory>
-</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
<Directory />
Options FollowSymLinks
@@ -117,72 +117,72 @@
<Directory /www/htdocs>
Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>
-</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
<Directory />
AllowOverride all
</Directory>
-</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 @@
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 @@
}
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 @@
}
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).
-
-<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).
+<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_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 @@
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 @@
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 @@
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 @@
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 @@
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>
<Directory />
AllowOverride none
Options FollowSymLinks
</Directory>
-</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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
can continue to support the pre-forking model, and also support various
threaded models.
-</body>
-</html>
+</BODY>
+</HTML>
1.18 +13 -13 apachen/htdocs/manual/misc/perf.html
Index: perf.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/perf.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- perf.html 1998/01/26 07:02:32 1.17
+++ perf.html 1998/01/26 16:53:56 1.18
@@ -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></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 @@
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 @@
<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,
-<http://www.sun.com/sun-on-net/performance.html></a>
+<http://www.sun.com/sun-on-net/performance.html></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 @@
<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>
1.13 +31 -31 apachen/htdocs/manual/misc/security_tips.html
Index: security_tips.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/misc/security_tips.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- security_tips.html 1997/12/14 00:57:44 1.12
+++ security_tips.html 1998/01/26 16:53:56 1.13
@@ -15,51 +15,51 @@
<!--#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 @@
<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 @@
<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 @@
<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>
-<Directory /> <br>
-AllowOverride None <br>
-Options None <br>
-allow from all <br>
-</Directory> <br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+<Directory /> <BR>
+AllowOverride None <BR>
+Options None <BR>
+allow from all <BR>
+</Directory> <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 @@
<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" -->
1.92 +864 -864 apachen/htdocs/manual/mod/core.html
Index: core.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/core.html,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -r1.91 -r1.92
--- core.html 1998/01/23 00:36:34 1.91
+++ core.html 1998/01/26 16:54:02 1.92
@@ -14,144 +14,144 @@
>
<!--#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"><Directory></A>
-<li><A HREF="#directorymatch"><DirectoryMatch></A>
-<li><A HREF="#documentroot">DocumentRoot</A>
-<li><A HREF="#errordocument">ErrorDocument</A>
-<li><A HREF="#errorlog">ErrorLog</A>
-<li><A HREF="#files"><Files></A>
-<li><A HREF="#filesmatch"><FilesMatch></A>
-<li><A HREF="#group">Group</A>
-<li><A HREF="#hostnamelookups">HostNameLookups</A>
-<li><A HREF="#identitycheck">IdentityCheck</A>
-<li><A HREF="#ifmodule"><IfModule></A>
-<li><A HREF="#include">Include</A>
-<li><A HREF="#keepalive">KeepAlive</A>
-<li><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
-<li><A HREF="#limit"><Limit></A>
-<li><A HREF="#listen">Listen</A>
-<li><A HREF="#listenbacklog">ListenBacklog</A>
-<li><A HREF="#location"><Location></A>
-<li><A HREF="#locationmatch"><LocationMatch></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"><VirtualHost></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"><Directory></A>
+<LI><A HREF="#directorymatch"><DirectoryMatch></A>
+<LI><A HREF="#documentroot">DocumentRoot</A>
+<LI><A HREF="#errordocument">ErrorDocument</A>
+<LI><A HREF="#errorlog">ErrorLog</A>
+<LI><A HREF="#files"><Files></A>
+<LI><A HREF="#filesmatch"><FilesMatch></A>
+<LI><A HREF="#group">Group</A>
+<LI><A HREF="#hostnamelookups">HostNameLookups</A>
+<LI><A HREF="#identitycheck">IdentityCheck</A>
+<LI><A HREF="#ifmodule"><IfModule></A>
+<LI><A HREF="#include">Include</A>
+<LI><A HREF="#keepalive">KeepAlive</A>
+<LI><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
+<LI><A HREF="#limit"><Limit></A>
+<LI><A HREF="#listen">Listen</A>
+<LI><A HREF="#listenbacklog">ListenBacklog</A>
+<LI><A HREF="#location"><Location></A>
+<LI><A HREF="#locationmatch"><LocationMatch></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"><VirtualHost></A>
+</UL>
+<HR>
<h2><A name="accessconfig">AccessConfig directive</A></h2>
<!--%plaintext <?INDEX {\tt AccessConfig} directive> -->
-<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"><Directory></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 <?INDEX {\tt AccessFileName} directive> -->
-<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>
-<Directory /><br>
-AllowOverride None<br>
-</Directory></code></blockquote><p><hr>
+<BLOCKQUOTE><CODE>
+<Directory /><BR>
+AllowOverride None<BR>
+</Directory></CODE></BLOCKQUOTE><P><HR>
<h2><A name="addmodule">AddModule directive</A></h2>
<!--%plaintext <?INDEX {\tt AddModule} directive> -->
-<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 <?INDEX {\tt AllowOverride} directive> -->
-<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 <?INDEX {\tt AuthConfig} override> -->
Allow use of the authorization directives
(<A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>,
@@ -160,8 +160,8 @@
<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 <?INDEX {\tt FileInfo} override> -->
Allow use of the directives controlling document types
(<A HREF="mod_mime.html#addencoding">AddEncoding</A>,
@@ -170,8 +170,8 @@
<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 <?INDEX {\tt Indexes} override> -->
Allow use of the directives controlling directory indexing
(<A HREF="mod_autoindex.html#adddescription">AddDescription</A>,
@@ -185,24 +185,24 @@
<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 <?INDEX {\tt Limit} override> -->
Allow use of the directives controlling host access (allow, deny and order).
-<dt>Options
-<dd>
+<DT>Options
+<DD>
<!--%plaintext <?INDEX {\tt Options} override> -->
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 <?INDEX {\tt AuthName} directive> -->
-<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 @@
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 <?INDEX {\tt AuthType} directive> -->
-<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 <?INDEX {\tt Basic} authentication scheme> -->
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 <?INDEX {\tt BindAddress} directive> -->
-<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® 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"><VirtualHost></A></code> sections.
+multiple independent servers, instead of using <CODE><A
+HREF="#virtualhost"><VirtualHost></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 <?INDEX {\tt ClearModuleList} directive> -->
-<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 <?INDEX {\tt ContentDigest} directive> -->
-<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>
+<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
+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 @@
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 <?INDEX {\tt CoreDumpDirectory} directive> -->
-<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 <?INDEX {\tt DefaultType} directive> -->
-<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"><Directory> directive</A></h2>
<!--%plaintext <?INDEX {\tt Directory} section directive> -->
-<strong>Syntax:</strong> <Directory <em>directory</em>> ... </Directory> <br>
-<strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Core. <p>
+<STRONG>Syntax:</STRONG> <Directory <EM>directory</EM>> ... </Directory> <BR>
+<STRONG>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Core. <P>
<Directory> and </Directory> 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>
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
-</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>
<Directory ~ "^/www/.*/[0-9]{3}">
-</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>
-<Directory /><br>
-AllowOverride None<br>
-</Directory><br><br>
-<Directory /home/*><br>
-AllowOverride FileInfo<br>
-</Directory></code></blockquote>
-for access to the document <code>/home/web/dir/doc.html</code> the
+<BLOCKQUOTE><CODE>
+<Directory /><BR>
+AllowOverride None<BR>
+</Directory><BR><BR>
+<Directory /home/*><BR>
+AllowOverride FileInfo<BR>
+</Directory></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 @@
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>
-<Directory ~ abc$><br>
-... directives here ...<br>
-</Directory><br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+<Directory ~ abc$><BR>
+... directives here ...<BR>
+</Directory><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 <Directory>s and <code>.htaccess</code> files have
+all normal <Directory>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 @@
The directory sections typically occur in the access.conf file, but they
may appear in any configuration file. <Directory> directives cannot
nest, and cannot appear in a <A HREF="#limit"><Limit></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"><DirectoryMatch></A></h2>
-<strong>Syntax:</strong> <DirectoryMatch <em>regex</em>> ... </DirectoryMatch> <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> <DirectoryMatch <EM>regex</EM>> ... </DirectoryMatch> <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><DirectoryMatch> and </DirectoryMatch> are used to enclose a group of
+<P><DirectoryMatch> and </DirectoryMatch> 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"><Directory></a>. However, it takes as an
-argument a regular expression. For example:</p>
+of that directory, the same as <A
+HREF="#directory"><Directory></A>. However, it takes as an
+argument a regular expression. For example:</P>
-<pre>
+<PRE>
<DirectoryMatch "^/www/.*/[0-9]{3}">
-</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"><Directory></a> for a description of how
+<P><STRONG>See Also:</STRONG>
+<A HREF="#directory"><Directory></A> for a description of how
regular expressions are mixed in with normal <Directory>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 <?INDEX {\tt DocumentRoot} directive> -->
-<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 <?INDEX {\tt ErrorDocument} directive> -->
-<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 @@
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 @@
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 <?INDEX {\tt ErrorLog} directive> -->
-<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"><Files> directive</A></h2>
-<strong>Syntax:</strong> <Files <em>filename</em>>
-... </Files><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 <Files> directive provides for access control by
-filename. It is comparable to the <a
-href="#directory"><Directory></a> directive and
-<a href="#location"><Location></a> directives. It
+<STRONG>Syntax:</STRONG> <Files <EM>filename</EM>>
+... </Files><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 <Files> directive provides for access control by
+filename. It is comparable to the <A
+HREF="#directory"><Directory></A> directive and
+<A HREF="#location"><Location></A> directives. It
should be matched with a </Files> directive. Directives that
apply to the filename given should be listed
-within. <code><Files></code> sections are processed in the
+within. <CODE><Files></CODE> sections are processed in the
order they appear in the configuration file, after the
-<Directory> sections and <code>.htaccess</code> files are
-read, but before <Location> sections.</p>
+<Directory> sections and <CODE>.htaccess</CODE> files are
+read, but before <Location> 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>
<Files ~ "\.(gif|jpe?g|png)$">
-</pre>
+</PRE>
would match most common Internet graphics formats. In Apache 1.3 and
-later, <a href="#filesmatch"><FilesMatch></a> is preferred,
+later, <A HREF="#filesmatch"><FilesMatch></A> is preferred,
however.
-<p>Note that unlike <a
-href="#directory"><code><Directory></code></a> and <a
-href="#location"><code><Location></code></a> sections,
-<code><Files></code> sections can be used inside .htaccess
+<P>Note that unlike <A
+HREF="#directory"><CODE><Directory></CODE></A> and <A
+HREF="#location"><CODE><Location></CODE></A> sections,
+<CODE><Files></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"><FilesMatch></A></h2>
-<strong>Syntax:</strong> <FilesMatch <em>regex</em>>
-... </Files><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 <FilesMatch> directive provides for access control by
-filename, just as the <a href="#files"><Files></a> directive
-does. However, it accepts a regular expression. For example:</p>
+<STRONG>Syntax:</STRONG> <FilesMatch <EM>regex</EM>>
+... </Files><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 <FilesMatch> directive provides for access control by
+filename, just as the <A HREF="#files"><Files></A> directive
+does. However, it accepts a regular expression. For example:</P>
-<pre>
+<PRE>
<FilesMatch "\.(gif|jpe?g|png)$">
-</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 <?INDEX {\tt Group} directive> -->
-<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 <VirtualHost> requires a
properly configured <A HREF="../suexec.html">suEXEC wrapper</A>.
When used inside a <VirtualHost> 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 <?INDEX {\tt HostNameLookups} directive> -->
-<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 <?INDEX {\tt IdentityCheck} directive> -->
-<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"><IfModule> directive</A></H2>
-<b>Syntax:</b> <IfModule [!]<i>module-name</i>> <i>...</i>
-</IfModule><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> <IfModule [!]<EM>module-name</EM>> <EM>...</EM>
+</IfModule><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 <IfModule <i>test</i>>...</IfModule>
+The <IfModule <EM>test</EM>>...</IfModule>
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 <IfModule> section directive
+The <EM>test</EM> in the <IfModule> 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><IfModule> sections are nest-able, which can be used to implement
+<P><IfModule> 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>
-
-<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>
+<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>
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"><Limit> directive</A></h2>
<!--%plaintext <?INDEX {\tt Limit} section directive> -->
-<strong>Syntax:</strong>
- <Limit <em>method method</em> ... > ... </Limit><br>
-<strong>Context:</strong> any<br>
-<strong>Status:</strong> core<p>
+<STRONG>Syntax:</STRONG>
+ <Limit <EM>method method</EM> ... > ... </Limit><BR>
+<STRONG>Context:</STRONG> any<BR>
+<STRONG>Status:</STRONG> core<P>
<Limit> and </Limit> 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 <Limit> or
<A HREF="#directory"><Directory></A> may be used; the majority will be
unaffected by the <Limit>. Example:
-<blockquote><code>
-<Limit GET POST><br>
-require valid-user<br>
-</Limit></code></blockquote>
+<BLOCKQUOTE><CODE>
+<Limit GET POST><BR>
+require valid-user<BR>
+</Limit></CODE></BLOCKQUOTE>
If an access control directive appears outside a <Limit>
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
-<Limit> directive at all.</STRONG> <p><hr>
+<Limit> 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>
+<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
+<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"><Location> directive</a></h2>
+<h2><A name="location"><Location> directive</A></h2>
-<strong>Syntax:</strong> <Location <em>URL</em>>
-... </Location><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 <Location> directive provides for access control by
-URL. It is comparable to the <a
-href="#directory"><Directory></a> directive, and
+<STRONG>Syntax:</STRONG> <Location <EM>URL</EM>>
+... </Location><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 <Location> directive provides for access control by
+URL. It is comparable to the <A
+HREF="#directory"><Directory></A> directive, and
should be matched with a </Location> directive. Directives that
apply to the URL given should be listed
-within. <code><Location></code> sections are processed in the
+within. <CODE><Location></CODE> sections are processed in the
order they appear in the configuration file, after the
-<Directory> sections and <code>.htaccess</code> files are
-read.</p>
+<Directory> 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>
<Location ~ "/(extra|special)/data">
-</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"><LocationMatch></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>would match URLs that contained the substring "/extra/data" or
+"/special/data". However, in Apache 1.3 and above, use of <A
+HREF="#locationmatch"><LocationMatch></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
from browsers at foo.com, you might use:
-<pre>
+<PRE>
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>
-</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"><LocationMatch></a></h2>
+<h2><A name="locationmatch"><LocationMatch></A></h2>
-<strong>Syntax:</strong> <LocationMatch <em>regex</em>>
-... </LocationMatch><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 <LocationMatch> directive provides for access control by
-URL, in an identical manner to <a
-href="#location"><Location></a>. However, it takes a regular
-expression as an argument instead of a simple string. For example:</p>
+<STRONG>Syntax:</STRONG> <LocationMatch <EM>regex</EM>>
+... </LocationMatch><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 <LocationMatch> directive provides for access control by
+URL, in an identical manner to <A
+HREF="#location"><Location></A>. However, it takes a regular
+expression as an argument instead of a simple string. For example:</P>
-<pre>
+<PRE>
<LocationMatch "/(extra|special)/data">
-</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 <?INDEX {\tt MaxClients} directive> -->
-<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 <?INDEX {\tt MaxRequestsPerChild} directive> -->
-<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 <?INDEX {\tt MaxSpareServers} directive> -->
-<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 <?INDEX {\tt MinSpareServers} directive> -->
-<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 <?INDEX {\tt NameVirtualHost} directive> -->
-<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 <?INDEX {\tt Options} directive> -->
-<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 <?INDEX {\tt ExecCGI} option> -->
Execution of CGI scripts is permitted.
-<dt>FollowSymLinks
-<dd>
+<DT>FollowSymLinks
+<DD>
<!--%plaintext <?INDEX {\tt FollowSymLinks} option> -->
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><Directory></code>
+<STRONG>Note</STRONG>: even though the server follows the symlink it does <EM>not</EM>
+change the pathname used to match against <CODE><Directory></CODE>
sections.
-<dt>Includes
-<dd>
+<DT>Includes
+<DD>
<!--%plaintext <?INDEX {\tt Includes} option> -->
Server-side includes are permitted.
-<dt>IncludesNOEXEC
-<dd>
+<DT>IncludesNOEXEC
+<DD>
<!--%plaintext <?INDEX {\tt IncludesNOEXEC} option> -->
Server-side includes are permitted, but the #exec command and
#include of CGI scripts are disabled.
-<dt>Indexes
-<dd>
+<DT>Indexes
+<DD>
<!--%plaintext <?INDEX {\tt Indexes} option> -->
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 <?INDEX {\tt MultiViews} option> -->
<A HREF="../content-negotiation.html">Content negotiated</A> MultiViews are
allowed.
-<dt>SymLinksIfOwnerMatch
-<dd>
+<DT>SymLinksIfOwnerMatch
+<DD>
<!--%plaintext <?INDEX {\tt SymLinksIfOwnerMatch} option> -->
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 @@
For example, without any + and - symbols:
-<blockquote><code>
-<Directory /web/docs> <br>
-Options Indexes FollowSymLinks<br>
-</Directory><br>
-<Directory /web/docs/spec> <br>
-Options Includes<br>
+<BLOCKQUOTE><CODE>
+<Directory /web/docs> <BR>
+Options Indexes FollowSymLinks<BR>
+</Directory><BR>
+<Directory /web/docs/spec> <BR>
+Options Includes<BR>
</Directory>
-</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>
-<Directory /web/docs> <br>
-Options Indexes FollowSymLinks<br>
-</Directory><br>
-<Directory /web/docs/spec> <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>
+<Directory /web/docs> <BR>
+Options Indexes FollowSymLinks<BR>
+</Directory><BR>
+<Directory /web/docs/spec> <BR>
+Options +Includes -Indexes<BR>
</Directory>
-</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 <?INDEX {\tt PidFile} directive> -->
-<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 <?INDEX {\tt Port} directive> -->
-<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"><VirtualHost></a> section)
+(i.e. outside any <A HREF="#virtualhost"><VirtualHost></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 <?INDEX {\tt require} directive> -->
-<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"><Limit></A>
+</UL>
+<P>
+If <CODE>require</CODE> appears in a <A HREF="#limit"><Limit></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>
-<Limit GET POST><br>
-require group admin<br>
+<BLOCKQUOTE><CODE>
+AuthType Basic<BR>
+AuthName somedomain<BR>
+AuthUserFile /web/users<BR>
+AuthGroupFile /web/groups<BR>
+<Limit GET POST><BR>
+require group admin<BR>
</Limit>
-</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 <?INDEX {\tt ResourceConfig} directive> -->
-<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"><Directory></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 <?INDEX {\tt RLimitCPU} directive> -->
-<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 <?INDEX {\tt RLimitMEM} directive> -->
-<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 <?INDEX {\tt RLimitNPROC} directive> -->
-<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 <?INDEX {\tt Satisfy} directive> -->
-<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 <?INDEX {\tt ScoreBoardFile} directive> -->
-<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 @@
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 <?INDEX {\tt SendBufferSize} directive> -->
-<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 <?INDEX {\tt ServerAdmin} directive> -->
-<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 <?INDEX {\tt ServerName} directive> -->
-<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 <?INDEX {\tt ServerRoot} directive> -->
-<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>
-
-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>
+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>
-<hr>
+<HR>
<h2><A name="servertype">ServerType directive</A></h2>
<!--%plaintext <?INDEX {\tt ServerType} directive> -->
-<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 @@
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 <?INDEX {\tt StartServers} directive> -->
-<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 <?INDEX {\tt TimeOut} directive> -->
-<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 @@
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 <?INDEX {\tt User} directive> -->
-<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 <VirtualHost> requires a
properly configured <A HREF="../suexec.html">suEXEC wrapper</A>.
When used inside a <VirtualHost> 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"><VirtualHost> directive</A></h2>
<!--%plaintext <?INDEX {\tt VirtualHost} section directive> -->
-<strong>Syntax:</strong> <VirtualHost <em>addr</em>[:<em>port</em>] ...> ...
-</VirtualHost> <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> <VirtualHost <EM>addr</EM>[:<EM>port</EM>] ...> ...
+</VirtualHost> <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>
<VirtualHost> and </VirtualHost> 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 <VirtualHost>
-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>
-<VirtualHost 10.1.2.3> <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>
+<VirtualHost 10.1.2.3> <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>
</VirtualHost>
-</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 <VirtualHost> does
-<strong>not</strong> affect what addresses Apache listens on. You may
+<P><STRONG>NOTE</STRONG>: The use of <VirtualHost> 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>.
+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
+<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>
1.36 +173 -173 apachen/htdocs/manual/mod/directives.html
Index: directives.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/directives.html,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- directives.html 1997/12/16 22:27:01 1.35
+++ directives.html 1998/01/26 16:54:02 1.36
@@ -23,179 +23,179 @@
>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"><Directory></A>
-<li><A HREF="core.html#directorymatch"><DirectoryMatch></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"><Files></A>
-<li><A HREF="core.html#filesmatch"><FilesMatch></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"><IfModule></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"><Limit></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"><Location></A>
-<li><A HREF="core.html#locationmatch"><LocationMatch></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"><VirtualHost></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"><Directory></A>
+<LI><A HREF="core.html#directorymatch"><DirectoryMatch></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"><Files></A>
+<LI><A HREF="core.html#filesmatch"><FilesMatch></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"><IfModule></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"><Limit></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"><Location></A>
+<LI><A HREF="core.html#locationmatch"><LocationMatch></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"><VirtualHost></A>
+<LI><A HREF="mod_include.html#xbithack">XBitHack</A>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.23 +85 -85 apachen/htdocs/manual/mod/index.html
Index: index.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/index.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- index.html 1998/01/23 16:13:56 1.22
+++ index.html 1998/01/26 16:54:03 1.23
@@ -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 @@
>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>
1.13 +110 -110 apachen/htdocs/manual/mod/mod_access.html
Index: mod_access.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_access.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- mod_access.html 1997/12/14 01:15:43 1.12
+++ mod_access.html 1998/01/26 16:54:03 1.13
@@ -14,76 +14,76 @@
>
<!--#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 <?INDEX {\tt allow} directive> -->
-<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:
+<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
+<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 @@
<P>
Example:
</P>
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
BrowserMatch ^KnockKnock/2.0 let_me_in
<Directory /docroot>
order deny,allow
deny from all
allow from env=let_me_in
</Directory>
-</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 <?INDEX {\tt deny} directive> -->
-<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:
+<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
+<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 @@
<P>
Example:
</P>
-<blockquote><pre>
+<BLOCKQUOTE><PRE>
BrowserMatch ^BadRobot/0.9 go_away
<Directory /docroot>
order allow,deny
allow from all
deny from env=go_away
</Directory>
-</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 <?INDEX {\tt order} directive> -->
-<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 "short-circuiting".</b>
+<STRONG>Note that in all cases every <CODE>allow</CODE> and <CODE>deny</CODE>
+statement is evaluated, there is no "short-circuiting".</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.
1.6 +33 -33 apachen/htdocs/manual/mod/mod_actions.html
Index: mod_actions.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_actions.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- mod_actions.html 1997/07/06 17:19:15 1.5
+++ mod_actions.html 1998/01/26 16:54:04 1.6
@@ -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 @@
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 <ISINDEX>-style searching
Script PUT /~bob/put.cgi
-</pre>
+</PRE>
<!--#include virtual="footer.html" -->
</BODY>
1.16 +107 -107 apachen/htdocs/manual/mod/mod_alias.html
Index: mod_alias.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_alias.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- mod_alias.html 1997/12/29 20:41:51 1.15
+++ mod_alias.html 1998/01/26 16:54:04 1.16
@@ -14,243 +14,243 @@
>
<!--#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 <?INDEX {\tt Alias} directive> -->
-<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 <?INDEX {\tt Redirect} directive> -->
-<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 <Directory> 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
"temporary" (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 <?INDEX {\tt Redirect} directive> -->
-<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 <?INDEX {\tt Redirect} directive> -->
-<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 <?INDEX {\tt ScriptAlias} directive> -->
-<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>
1.5 +27 -27 apachen/htdocs/manual/mod/mod_asis.html
Index: mod_asis.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_asis.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- mod_asis.html 1997/12/01 14:41:14 1.4
+++ mod_asis.html 1998/01/26 16:54:05 1.5
@@ -14,11 +14,11 @@
>
<!--#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 <?INDEX {\tt httpd/send-as-is} mime type> -->
@@ -31,36 +31,36 @@
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>
-<HTML> <br>
-<HEAD> <br>
-<TITLE>Lame excuses'R'us</TITLE> <br>
-</HEAD> <br>
-<BODY> <br>
-<H1>Fred's exceptionally wonderful page has moved to <br>
-<A HREF="http://xyz.abc.com/foo/bar.html">Joe's</A> site. <br>
-</H1> <br>
-</BODY> <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>
+<HTML> <BR>
+<HEAD> <BR>
+<TITLE>Lame excuses'R'us</TITLE> <BR>
+</HEAD> <BR>
+<BODY> <BR>
+<H1>Fred's exceptionally wonderful page has moved to <BR>
+<A HREF="http://xyz.abc.com/foo/bar.html">Joe's</A> site. <BR>
+</H1> <BR>
+</BODY> <BR>
</HTML>
-</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" -->
1.11 +55 -55 apachen/htdocs/manual/mod/mod_auth.html
Index: mod_auth.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_auth.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- mod_auth.html 1998/01/23 16:13:56 1.10
+++ mod_auth.html 1998/01/26 16:54:05 1.11
@@ -14,136 +14,136 @@
>
<!--#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 <?INDEX {\tt AuthGroupFile} directive> -->
-<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 <?INDEX {\tt AuthUserFile} directive> -->
-<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 <?INDEX {\tt AuthAuthoritative} directive> -->
-<strong>Syntax:</strong> AuthAuthoritative < <strong> on</strong>(default) | off > <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 < <STRONG> on</STRONG>(default) | off > <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>
1.16 +136 -136 apachen/htdocs/manual/mod/mod_auth_anon.html
Index: mod_auth_anon.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_auth_anon.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- mod_auth_anon.html 1998/01/23 16:13:57 1.15
+++ mod_auth_anon.html 1998/01/26 16:54:06 1.16
@@ -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 @@
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>
+<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>
+<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>
+<HR>
<h2><A name="anonymous">Anonymous directive</A></h2>
<!--%plaintext <?INDEX {\tt Anonymous} directive> -->
-<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 <?INDEX {\tt Anonymous_MustGiveEmail} directive> -->
-<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 @@
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>
-<Files *><br>
-order deny,allow <br>
-allow from all <br>
-<p>
-require valid-user <br>
-</Files><br>
-</code></blockquote>
+<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>
+<Files *><BR>
+order deny,allow <BR>
+allow from all <BR>
+<P>
+require valid-user <BR>
+</Files><BR>
+</CODE></BLOCKQUOTE>
-<hr>
-<h2><a name="CompileTimeOptions">Compile Time Options</a></h2>
+<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
-<<a href="mailto:Dirk.vanGulik@jrc.it"><code>Dirk.vanGulik@jrc.it</code></a>>.
+<A HREF="http://ewse.ceo.org">European Wide Service Exchange</A> by
+<<A HREF="mailto:Dirk.vanGulik@jrc.it"><CODE>Dirk.vanGulik@jrc.it</CODE></A>>.
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><himba@cs.utwente.nl></code></a>.
-<p>
+documentation, courtesy of Nick Himba, <A HREF="mailto:himba@cs.utwente.nl">
+<CODE><himba@cs.utwente.nl></CODE></A>.
+<P>
-<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
+<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
that you always quote the version you use when filing a bug report.
-<p>
+<P>
<!--#include virtual="footer.html" -->
-</body>
-</html>
+</BODY>
+</HTML>
1.10 +57 -57 apachen/htdocs/manual/mod/mod_auth_db.html
Index: mod_auth_db.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_auth_db.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- mod_auth_db.html 1997/06/04 16:14:16 1.9
+++ mod_auth_db.html 1998/01/26 16:54:06 1.10
@@ -13,92 +13,92 @@
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 <?INDEX {\tt AuthDBGroupFile} directive> -->
-<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 <?INDEX {\tt AuthDBUserFile} directive> -->
-<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 @@
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 <?INDEX {\tt AuthDBAuthoritative} directive> -->
-<strong>Syntax:</strong> AuthDBAuthoritative < <strong> on</strong>(default) | off > <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 < <STRONG> on</STRONG>(default) | off > <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>
1.12 +57 -57 apachen/htdocs/manual/mod/mod_auth_dbm.html
Index: mod_auth_dbm.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_auth_dbm.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- mod_auth_dbm.html 1997/07/06 17:19:16 1.11
+++ mod_auth_dbm.html 1998/01/26 16:54:07 1.12
@@ -14,91 +14,91 @@
>
<!--#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 <?INDEX {\tt AuthDbmGroupFile} directive> -->
-<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 <?INDEX {\tt AuthDBMUserFile} directive> -->
-<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 @@
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 <?INDEX {\tt AuthDBMAuthoritative} directive> -->
-<strong>Syntax:</strong> AuthDBMAuthoritative < <strong> on</strong>(default) | off > <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 < <STRONG> on</STRONG>(default) | off > <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 @@
.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>
1.15 +185 -185 apachen/htdocs/manual/mod/mod_autoindex.html
Index: mod_autoindex.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_autoindex.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- mod_autoindex.html 1997/11/09 05:49:23 1.14
+++ mod_autoindex.html 1998/01/26 16:54:07 1.15
@@ -15,24 +15,24 @@
<!--#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 @@
<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 <?INDEX {\tt AddAlt} directive> -->
-<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>"</code>). This alternate text is displayed if the client is
+to describe. <EM>String</EM> is enclosed in double quotes
+(<CODE>"</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 <?INDEX {\tt AddAltByEncoding} directive> -->
-<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>"</code>). This alternate text is displayed if the client is
+<EM>String</EM> is enclosed in double quotes
+(<CODE>"</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 <?INDEX {\tt AddAltByType} directive> -->
-<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>"</code>). This alternate text is displayed if the client is
+<EM>String</EM> is enclosed in double quotes
+(<CODE>"</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 <?INDEX {\tt AddDescription} directive> -->
-<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>"</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>"</CODE>). Example:
+<BLOCKQUOTE><CODE>AddDescription "The planet Mars" /web/pics/mars.gif
+</CODE></BLOCKQUOTE><P><HR>
<A name="addicon"><h2>AddIcon</h2></A>
<!--%plaintext <?INDEX {\tt AddIcon} directive> -->
-<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>
+<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
+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 <?INDEX {\tt AddIconByEncoding} directive> -->
-<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 <?INDEX {\tt AddIconByType} directive> -->
-<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>
+<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
+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 <?INDEX {\tt DefaultIcon} directive> -->
-<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 <?INDEX {\tt FancyIndexing} directive> -->
-<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 FancyIndexing</SAMP> in preference
to the standalone <SAMP>FancyIndexing</SAMP> directive.</STRONG>
</BLOCKQUOTE>
-<hr>
+<HR>
<A name="headername"><h2>HeaderName</h2></A>
<!--%plaintext <?INDEX {\tt HeaderName} directive> -->
-<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 <?INDEX {\tt IndexIgnore} directive> -->
-<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 <?INDEX {\tt IndexOptions} directive> -->
-<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 <?INDEX {\tt FancyIndexing} index option> -->
+<EM>Option</EM> can be one of
+<DL>
+<DT>FancyIndexing
+<DD><!--%plaintext <?INDEX {\tt FancyIndexing} index option> -->
This turns on fancy indexing of directories.
<BLOCKQUOTE>
<STRONG>Note that the <SAMP>FancyIndexing</SAMP> and
@@ -303,8 +303,8 @@
should use <SAMP>IndexOptions 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 <?INDEX {\tt IconHeight} index option> -->
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 @@
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 <?INDEX {\tt IconsAreLinks} index option> -->
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 <?INDEX {\tt IconWidth} index option> -->
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 @@
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 <?INDEX {\tt ScanHTMLTitles} index option> -->
+<DT>ScanHTMLTitles
+<DD><!--%plaintext <?INDEX {\tt ScanHTMLTitles} index option> -->
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 @@
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 <?INDEX {\tt SuppressDescription} index option> -->
This will suppress the file description in fancy indexing listings.
-<dt>SuppressHTMLPreamble
-<dd>
+<DT>SuppressHTMLPreamble
+<DD>
<!--%plaintext <?INDEX {\tt SuppressHTMLPreamble} index option> -->
If the directory actually contains a file specified by the
<A
@@ -359,50 +359,50 @@
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 <?INDEX {\tt SuppressLastModified} index option> -->
This will suppress the display of the last modification date, in fancy
indexing listings.
-<dt>SuppressSize
-<dd>
+<DT>SuppressSize
+<DD>
<!--%plaintext <?INDEX {\tt SuppressSize} index option> -->
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>
-<Directory /web/docs> <br>
-IndexOptions FancyIndexing <br>
-</Directory><br>
-<Directory /web/docs/spec> <br>
-IndexOptions ScanHTMLTitles <br>
+<BLOCKQUOTE><CODE>
+<Directory /web/docs> <BR>
+IndexOptions FancyIndexing <BR>
+</Directory><BR>
+<Directory /web/docs/spec> <BR>
+IndexOptions ScanHTMLTitles <BR>
</Directory>
-</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 <?INDEX {\tt ReadmeName} directive> -->
-<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" -->
1.12 +35 -35 apachen/htdocs/manual/mod/mod_browser.html
Index: mod_browser.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_browser.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- mod_browser.html 1997/09/11 13:59:30 1.11
+++ mod_browser.html 1998/01/26 16:54:08 1.12
@@ -15,74 +15,74 @@
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Module mod_browser</H1>
-This module is contained in the <code>mod_browser.c</code> file, and
+This module is contained in the <CODE>mod_browser.c</CODE> file, and
is compiled in by default. It provides for setting environment
variables based on the browser. This module is part of Apache 1.2.*
-only. From Apache 1.3 onwards <code><a
-href="mod_setenvif.html">mod_setenvif</a></code> provides the functionality
+only. From Apache 1.3 onwards <CODE><A
+HREF="mod_setenvif.html">mod_setenvif</A></CODE> provides the functionality
of this module.
<h2>Summary</h2>
-<p>This module allows you to set environment variables based on the name of
-the browser accessing your document, based on the <code>User-Agent</code>
+<P>This module allows you to set environment variables based on the name of
+the browser accessing your document, based on the <CODE>User-Agent</CODE>
header field. This is especially useful when combined with a conditional
-HTML language such as <a href="mod_include.html">XSSI</a> or PHP, and
-can provide for simple browser-based negotiation of HTML features.</p>
+HTML language such as <A HREF="mod_include.html">XSSI</A> or PHP, and
+can provide for simple browser-based negotiation of HTML features.</P>
<h2>Directives</h2>
-<ul>
-<li><A HREF="#browsermatch">BrowserMatch</A>
-<li><A HREF="#browsermatchnocase">BrowserMatchNoCase</A>
-</ul>
+<UL>
+<LI><A HREF="#browsermatch">BrowserMatch</A>
+<LI><A HREF="#browsermatchnocase">BrowserMatchNoCase</A>
+</UL>
-<hr>
+<HR>
<h2><A name="browsermatch">BrowserMatch</A></h2>
-<strong>Syntax:</strong> BrowserMatch <em>regex attr1 attr2...</em><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> base<br>
-<strong>Module:</strong> mod_browser<br>
-<strong>Compatibility:</strong> Apache 1.2 and above<p>
+<STRONG>Syntax:</STRONG> BrowserMatch <EM>regex attr1 attr2...</EM><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> base<BR>
+<STRONG>Module:</STRONG> mod_browser<BR>
+<STRONG>Compatibility:</STRONG> Apache 1.2 and above<P>
The BrowserMatch directive defines environment variables based on the
User-Agent
header. The first argument should be a POSIX.2 extended regular
expression (similar to an egrep-style regex). The rest of the arguments
give names of variables to set. These take the form of either
-"<code>varname</code>", "<code>!varname</code>" or
-"<code>varname=value</code>". In the first form, the value will be set
+"<CODE>varname</CODE>", "<CODE>!varname</CODE>" or
+"<CODE>varname=value</CODE>". In the first form, the value will be set
to "1". The second will remove the given variable if already defined,
-and the third will set the variable to the value given by <code>value</code>. If a User-Agent
+and the third will set the variable to the value given by <CODE>value</CODE>. If a User-Agent
string matches more than one entry, they will
be merged. Entries are processed in the order they appear, and later
entries can override earlier ones.
-<p>For example:</p>
-<pre>
+<P>For example:</P>
+<PRE>
BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
BrowserMatch MSIE !javascript
-</pre>
+</PRE>
-<p><h2><A name="browsermatchnocase">BrowserMatchNoCase</A></h2>
-<strong>Syntax:</strong> BrowserMatchNoCase <em>regex attr1 attr2...</em><br>
-<strong>Context:</strong> server config<br>
-<strong>Status:</strong> base<br>
-<strong>Module:</strong> mod_browser<br>
-<strong>Compatibility:</strong> Apache 1.2 and above
+<P><h2><A name="browsermatchnocase">BrowserMatchNoCase</A></h2>
+<STRONG>Syntax:</STRONG> BrowserMatchNoCase <EM>regex attr1 attr2...</EM><BR>
+<STRONG>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> base<BR>
+<STRONG>Module:</STRONG> mod_browser<BR>
+<STRONG>Compatibility:</STRONG> Apache 1.2 and above
-<p>The <code>BrowserMatchNoCase</code> directive is semantically identical to
- the <a href="#browsermatch"><code>BrowserMatch</code></a>
+<P>The <CODE>BrowserMatchNoCase</CODE> directive is semantically identical to
+ the <A HREF="#browsermatch"><CODE>BrowserMatch</CODE></A>
directive. However, it provides for case-insensitive matching. For
- example:</p>
-<pre>
+ example:</P>
+<PRE>
BrowserMatchNoCase mac platform=macintosh
BrowserMatchNoCase win platform=windows
-</pre>
+</PRE>
-<p>
+<P>
<!--#include virtual="footer.html" -->
</BODY>
1.9 +39 -39 apachen/htdocs/manual/mod/mod_cern_meta.html
Index: mod_cern_meta.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_cern_meta.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- mod_cern_meta.html 1997/08/23 18:42:07 1.8
+++ mod_cern_meta.html 1998/01/26 16:54:08 1.9
@@ -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 @@
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>
1.12 +61 -61 apachen/htdocs/manual/mod/mod_cgi.html
Index: mod_cgi.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_cgi.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- mod_cgi.html 1997/08/03 10:17:10 1.11
+++ mod_cgi.html 1998/01/26 16:54:08 1.12
@@ -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
@@ -14,26 +14,26 @@
>
<!--#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 <?INDEX {\tt application/x-httpd-cgi} mime type> -->
<!--%plaintext <?INDEX CGI scripts> -->
<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 @@
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 @@
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 @@
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 @@
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
1.7 +11 -11 apachen/htdocs/manual/mod/mod_cookies.html
Index: mod_cookies.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_cookies.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_cookies.html 1997/11/12 01:50:04 1.6
+++ mod_cookies.html 1998/01/26 16:54:09 1.7
@@ -13,33 +13,33 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_cookies</h1>
+<H1 ALIGN="CENTER">Module mod_cookies</H1>
<STRONG><FONT COLOR="red">This module is obsolete. As of version
1.2 of Apache, it has been replaced with <A HREF="mod_usertrack.html">
mod_usertrack</A>. </FONT></STRONG>
-<P>This module is contained in the <code>mod_cookies.c</code> file, and
+<P>This module is contained in the <CODE>mod_cookies.c</CODE> file, and
is not compiled in by default. It provides for Netscape(TM) cookies.
There is no documentation available for this module.
-<menu>
-<li><A HREF="#cookielog">CookieLog</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#cookielog">CookieLog</A>
+</MENU>
+<HR>
<h2><A name="cookielog">CookieLog</A></h2>
<!--%plaintext <?INDEX {\tt CookieLog} directive> -->
-<strong>Syntax:</strong> CookieLog <em>filename</em><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Experimental<br>
-<strong>Module:</strong> mod_cookies<p>
+<STRONG>Syntax:</STRONG> CookieLog <EM>filename</EM><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Experimental<BR>
+<STRONG>Module:</STRONG> mod_cookies<P>
The CookieLog directive sets the filename for logging of cookies.
The filename is relative to the <A HREF="core.html#serverroot">ServerRoot</A>.
-<p>
+<P>
<!--#include virtual="footer.html" -->
</BODY>
1.7 +21 -21 apachen/htdocs/manual/mod/mod_digest.html
Index: mod_digest.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_digest.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_digest.html 1997/06/04 16:14:19 1.6
+++ mod_digest.html 1998/01/26 16:54:09 1.7
@@ -13,51 +13,51 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_digest</h1>
+<H1 ALIGN="CENTER">Module mod_digest</H1>
-This module is contained in the <code>mod_digest.c</code> file, and is
+This module is contained in the <CODE>mod_digest.c</CODE> file, and is
not compiled in by default. It is only available in Apache 1.1 and
later. It provides for user authentication using MD5 Digest
Authentication.
-<menu>
-<li><A HREF="#authdigestfile">AuthDigestFile</A>
-</menu>
-<hr>
+<MENU>
+<LI><A HREF="#authdigestfile">AuthDigestFile</A>
+</MENU>
+<HR>
<h2><A name="authdigestfile">AuthDigestFile</A></h2>
-<strong>Syntax:</strong> AuthDigestFile <em>filename</em><br>
-<Strong>Context:</strong> directory, .htaccess<br>
-<Strong>Override:</strong> AuthConfig<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_digest<p>
+<STRONG>Syntax:</STRONG> AuthDigestFile <EM>filename</EM><BR>
+<Strong>Context:</STRONG> directory, .htaccess<BR>
+<Strong>Override:</STRONG> AuthConfig<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_digest<P>
-<p>The AuthDigestFile directive sets the name of a textual file containing
+<P>The AuthDigestFile directive sets the name of a textual file containing
the list
of users and encoded passwords for digest authentication.
-<em>Filename</em>
-is the absolute path to the user file.</p>
-<p>The digest file uses a special format. Files in this format can be
+<EM>Filename</EM>
+is the absolute path to the user file.</P>
+<P>The digest file uses a special format. Files in this format can be
created using the "htdigest" utility found in the support/ subdirectory of
-the Apache distribution.</p>
+the Apache distribution.</P>
-<hr>
+<HR>
<h3>Using Digest Authentication</h3>
-<p>Using MD5 Digest authentication is very simple. Simply set up
+<P>Using MD5 Digest authentication is very simple. Simply set up
authentication normally. However, use "AuthType Digest" and
"AuthDigestFile" instead of the normal "AuthType Basic" and
-"AuthUserFile". Everything else should remain the same.</p>
+"AuthUserFile". Everything else should remain the same.</P>
-<p>MD5 authentication provides a more secure password system, but only
+<P>MD5 authentication provides a more secure password system, but only
works with supporting browsers. As of this writing (July 1996), the
majority of browsers do not support digest authentication. Therefore, we
do not recommend using this feature on a large Internet site. However, for
personal and intra-net use, where browser users can be controlled, it is
-ideal.</p>
+ideal.</P>
<!--#include virtual="footer.html" -->
</BODY>
1.10 +30 -30 apachen/htdocs/manual/mod/mod_dir.html
Index: mod_dir.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_dir.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- mod_dir.html 1997/07/08 19:50:41 1.9
+++ mod_dir.html 1998/01/26 16:54:10 1.10
@@ -15,47 +15,47 @@
<!--#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 <?INDEX {\tt DirectoryIndex} directive> -->
-<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 @@
<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>
1.5 +30 -30 apachen/htdocs/manual/mod/mod_dld.html
Index: mod_dld.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_dld.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- mod_dld.html 1997/06/04 16:14:19 1.4
+++ mod_dld.html 1998/01/26 16:54:10 1.5
@@ -13,9 +13,9 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_dld</h1>
+<H1 ALIGN="CENTER">Module mod_dld</H1>
-This module is contained in the <code>mod_dld.c</code> file, and is not
+This module is contained in the <CODE>mod_dld.c</CODE> file, and is not
compiled in by default. It provides for loading of executable code
and modules into the server at start-up time, using the GNU dld library.
@@ -26,52 +26,52 @@
first time only; for now, rereading the config files cannot affect the
state of loaded modules), using the GNU dynamic linking library, DLD.
It isn't compiled into the server by default, since not everyone has
-DLD, but it works when I try it. (Famous last words.) <p>
+DLD, but it works when I try it. (Famous last words.) <P>
-Note that for some reason, <code>LoadFile /lib/libc.a</code> seems to be
-required for just about everything.<p>
+Note that for some reason, <CODE>LoadFile /lib/libc.a</CODE> seems to be
+required for just about everything.<P>
Note: that DLD needs to read the symbol table out of the server binary
when starting up; these commands will fail if the server can't find
-its own binary when it starts up, or if that binary is stripped.<p>
+its own binary when it starts up, or if that binary is stripped.<P>
<h2>Directives</h2>
-<ul>
-<li><A HREF="#loadfile">LoadFile</A>
-<li><A HREF="#loadmodule">LoadModule</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#loadfile">LoadFile</A>
+<LI><A HREF="#loadmodule">LoadModule</A>
+</UL>
+<HR>
<h2><A name="loadfile">LoadFile</A></h2>
<!--%plaintext <?INDEX {\tt LoadFile} directive> -->
-<strong>Syntax:</strong> LoadFile <em>filename filename ...</em><br>
-<Strong>Context:</strong> server config<br>
-<strong>Status:</strong> Experimental<br>
-<strong>Module:</strong> mod_dld<p>
+<STRONG>Syntax:</STRONG> LoadFile <EM>filename filename ...</EM><BR>
+<Strong>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Experimental<BR>
+<STRONG>Module:</STRONG> mod_dld<P>
The LoadFile directive links in the named object files or libraries when
the server is started; this is used to load additional code which
-may be required for some module to work. <em>Filename</em> is relative
-to <A HREF="core.html#serverroot">ServerRoot</A>.<p><hr>
+may be required for some module to work. <EM>Filename</EM> is relative
+to <A HREF="core.html#serverroot">ServerRoot</A>.<P><HR>
<h2><A name="loadmodule">LoadModule</A></h2>
<!--%plaintext <?INDEX {\tt LoadModule} directive> -->
-<strong>Syntax:</strong> LoadModule <em>module filename</em><br>
-<Strong>Context:</strong> server config<br>
-<strong>Status:</strong> Experimental<br>
-<strong>Module:</strong> mod_dld<p>
-
-The LoadModule directive links in the object file or library <em>filename</em>
-and adds the module structure named <em>module</em> to the list of active
-modules. <em>Module</em> is the name of the external variable of type
-<code>module</code> in the file. Example:
-<blockquote><code>
-LoadModule ai_backcompat_module modules/mod_ai_backcompat.o<br>
+<STRONG>Syntax:</STRONG> LoadModule <EM>module filename</EM><BR>
+<Strong>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Experimental<BR>
+<STRONG>Module:</STRONG> mod_dld<P>
+
+The LoadModule directive links in the object file or library <EM>filename</EM>
+and adds the module structure named <EM>module</EM> to the list of active
+modules. <EM>Module</EM> is the name of the external variable of type
+<CODE>module</CODE> in the file. Example:
+<BLOCKQUOTE><CODE>
+LoadModule ai_backcompat_module modules/mod_ai_backcompat.o<BR>
LoadFile /lib/libc.a
-</code></blockquote>
-loads the module in the modules subdirectory of the ServerRoot.<p>
+</CODE></BLOCKQUOTE>
+loads the module in the modules subdirectory of the ServerRoot.<P>
<!--#include virtual="footer.html" -->
1.3 +58 -58 apachen/htdocs/manual/mod/mod_dll.html
Index: mod_dll.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_dll.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mod_dll.html 1997/07/26 20:44:01 1.2
+++ mod_dll.html 1998/01/26 16:54:11 1.3
@@ -13,107 +13,107 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_dll</h1>
+<H1 ALIGN="CENTER">Module mod_dll</H1>
-This module is contained in the <code>mod_dll.c</code> file, and is not
+This module is contained in the <CODE>mod_dll.c</CODE> file, and is not
compiled in by default for Windows. It provides for loading of executable code
and modules into the server at start-up time, when they are contained in
-Win32 DLLs.</p>
+Win32 DLLs.</P>
<h2>Summary</h2>
-<p>The DLL module
+<P>The DLL module
loads other modules into the server as it is configuring itself (the
first time only, rereading the config files cannot affect the
-state of loaded modules), when these modules are compiled into DLL files.</p>
+state of loaded modules), when these modules are compiled into DLL files.</P>
-<p>This module is included with Apache 1.3 and later, and is available
- only when using Microsoft Windows.</p>
+<P>This module is included with Apache 1.3 and later, and is available
+ only when using Microsoft Windows.</P>
-<h2><a name="creating">Creating DLL Modules</a></h2>
+<h2><A name="creating">Creating DLL Modules</A></h2>
-<p>The Apache module API is unchanged between the Unix and Windows
+<P>The Apache module API is unchanged between the Unix and Windows
versions. Many modules will run on Windows with no or little change
from Unix, although others rely on aspects of the Unix architecture
- which are not present in Windows, and will not work.</p>
+ which are not present in Windows, and will not work.</P>
-<p>When a module does work, it can be added to the server in one of two
+<P>When a module does work, it can be added to the server in one of two
ways. As with Unix, it can be compiled into the server. Because Apache
- for Windows does not have the <code>Configure</code> program of Apache
+ for Windows does not have the <CODE>Configure</CODE> program of Apache
for Unix, the module's source file must be added to the ApacheCore
project file, and its symbols must be added to the
- <code>nt\modules.c</code> file.</p>
+ <CODE>nt\modules.c</CODE> file.</P>
-<p>The second way is to compile the module as a DLL, a shared library
+<P>The second way is to compile the module as a DLL, a shared library
that can be loaded into the server at runtime, using the
- <code><a href="#loadmodule">LoadModule</a></code>
+ <CODE><A HREF="#loadmodule">LoadModule</A></CODE>
directive. These module DLLs can be distributed and run on any Apache
- for Windows installation, without recompilation of the server.</p>
+ for Windows installation, without recompilation of the server.</P>
-<p>To create a module DLL, a small change is necessary to the module's
+<P>To create a module DLL, a small change is necessary to the module's
source file: The module record must be exported from the DLL (which
will be created later; see below). To do this, add the
- <code>MODULE_VAR_EXPORT</code> (defined in the Apache header files) to
+ <CODE>MODULE_VAR_EXPORT</CODE> (defined in the Apache header files) to
your module's module record definition. For example, if your module
- has:</p>
-<pre>
+ has:</P>
+<PRE>
module foo_module;
-</pre>
-<p>Replace the above with:</p>
-<pre>
+</PRE>
+<P>Replace the above with:</P>
+<PRE>
module MODULE_VAR_EXPORT foo_module;
-</pre>
-<p>Note that this will only be activated on Windows, so the module can
+</PRE>
+<P>Note that this will only be activated on Windows, so the module can
continue to be used, unchanged, with Unix if needed. Also, if you are
- familiar with <code>.DEF</code> files, you can export the module
- record with that method instead.</p>
+ familiar with <CODE>.DEF</CODE> files, you can export the module
+ record with that method instead.</P>
-<p>Now, create a DLL containing your module. You will need to link this
+<P>Now, create a DLL containing your module. You will need to link this
against the ApacheCore.lib export library that is created when the
ApacheCore.dll shared library is compiled. You may also have to change
the compiler settings to ensure that the Apache header files are
- correctly located.</p>
+ correctly located.</P>
-<p>This should create a DLL version of your module. Now simply place it
- in the server root, and use the <code><a
- href="#loadmodule">LoadModule</a></code> directive to
- load it.</p>
+<P>This should create a DLL version of your module. Now simply place it
+ in the server root, and use the <CODE><A
+ HREF="#loadmodule">LoadModule</A></CODE> directive to
+ load it.</P>
<h2>Directives</h2>
-<ul>
-<li><A HREF="#loadfile">LoadFile</A>
-<li><A HREF="#loadmodule">LoadModule</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#loadfile">LoadFile</A>
+<LI><A HREF="#loadmodule">LoadModule</A>
+</UL>
+<HR>
<h2><A name="loadfile">LoadFile</A></h2>
-<strong>Syntax:</strong> LoadFile <em>filename filename ...</em><br>
-<Strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core (Windows)<br>
-<strong>Module:</strong> mod_dll<p>
+<STRONG>Syntax:</STRONG> LoadFile <EM>filename filename ...</EM><BR>
+<Strong>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core (Windows)<BR>
+<STRONG>Module:</STRONG> mod_dll<P>
The LoadFile directive links in the named object files or libraries when
the server is started; this is used to load additional code which
-may be required for some module to work. <em>Filename</em> is relative
-to <A HREF="core.html#serverroot">ServerRoot</A>.<p><hr>
+may be required for some module to work. <EM>Filename</EM> is relative
+to <A HREF="core.html#serverroot">ServerRoot</A>.<P><HR>
<h2><A name="loadmodule">LoadModule</A></h2>
-<strong>Syntax:</strong> LoadModule <em>module filename</em><br>
-<Strong>Context:</strong> server config<br>
-<strong>Status:</strong> Core (Windows)<br>
-<strong>Module:</strong> mod_dll<p>
-
-The LoadModule directive links in the object file or library <em>filename</em>
-and adds the module structure named <em>module</em> to the list of active
-modules. <em>Module</em> is the name of the external variable of type
-<code>module</code> in the file. Example:
-
-<blockquote><code>
-LoadModule status_module modules/ApacheModuleStatus.dll<br>
-</code></blockquote>
+<STRONG>Syntax:</STRONG> LoadModule <EM>module filename</EM><BR>
+<Strong>Context:</STRONG> server config<BR>
+<STRONG>Status:</STRONG> Core (Windows)<BR>
+<STRONG>Module:</STRONG> mod_dll<P>
+
+The LoadModule directive links in the object file or library <EM>filename</EM>
+and adds the module structure named <EM>module</EM> to the list of active
+modules. <EM>Module</EM> is the name of the external variable of type
+<CODE>module</CODE> in the file. Example:
+
+<BLOCKQUOTE><CODE>
+LoadModule status_module modules/ApacheModuleStatus.dll<BR>
+</CODE></BLOCKQUOTE>
loads the ApacheModuleStatus.dll module in the modules subdirectory of the
-ServerRoot.<p>
+ServerRoot.<P>
<!--#include virtual="footer.html" -->
1.8 +34 -34 apachen/htdocs/manual/mod/mod_env.html
Index: mod_env.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_env.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- mod_env.html 1997/07/06 17:19:16 1.7
+++ mod_env.html 1998/01/26 16:54:11 1.8
@@ -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 @@
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>
1.7 +1 -1 apachen/htdocs/manual/mod/mod_example.html
Index: mod_example.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_example.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_example.html 1997/12/29 20:41:51 1.6
+++ mod_example.html 1998/01/26 16:54:11 1.7
@@ -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
1.7 +9 -9 apachen/htdocs/manual/mod/mod_expires.html
Index: mod_expires.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_expires.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_expires.html 1997/11/11 21:58:15 1.6
+++ mod_expires.html 1998/01/26 16:54:12 1.7
@@ -59,11 +59,11 @@
<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>
@@ -100,11 +100,11 @@
<STRONG>Syntax:</STRONG> ExpiresByType <EM>mime-type <code>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>
@@ -170,11 +170,11 @@
<STRONG>Syntax:</STRONG> ExpiresDefault <EM><code>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>
1.6 +29 -29 apachen/htdocs/manual/mod/mod_headers.html
Index: mod_headers.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_headers.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- mod_headers.html 1997/08/01 12:05:05 1.5
+++ mod_headers.html 1998/01/26 16:54:12 1.6
@@ -13,53 +13,53 @@
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 @@
configuration. It is valid in the main server config and virtual host
sections, inside <Directory>, <Location> and <Files>
sections, and within .htaccess files.
-<p>
+<P>
The Header directives are processed in the following order:
-<ol>
-<li>main server
-<li>virtual host
-<li><Directory> sections and .htaccess
-<li><Location>
-<li><Files>
-</ol>
+<OL>
+<LI>main server
+<LI>virtual host
+<LI><Directory> sections and .htaccess
+<LI><Location>
+<LI><Files>
+</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
1.9 +162 -162 apachen/htdocs/manual/mod/mod_imap.html
Index: mod_imap.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_imap.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- mod_imap.html 1997/12/29 20:41:52 1.8
+++ mod_imap.html 1998/01/26 16:54:13 1.9
@@ -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
@@ -13,27 +13,27 @@
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 @@
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 <BASE> 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>
+<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>
+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 @@
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><BASE href="value"></code>. The
+<DL>
+<DT><CODE>base</CODE> Directive
+<DD>Has the effect of <CODE><BASE HREF="value"></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><a href="http://foo.com/">Menu text</a></code><br>
+ text for the link if a menu is generated:<BR>
+ <CODE><a HREF="http://foo.com/">Menu text</a></CODE><BR>
If no quoted text is present, the name of the link will be used
- as the text:<br>
- <code><a href="http://foo.com/">http://foo.com</a></code><br>
+ as the text:<BR>
+ <CODE><a HREF="http://foo.com/">http://foo.com</a></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. <hr> <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. <hr> <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>
-<A HREF="/maps/imagemap1.map"> <br>
-<IMG ISMAP SRC="/images/imagemap1.gif"> <br>
+<BLOCKQUOTE><CODE>
+<A HREF="/maps/imagemap1.map"> <BR>
+<IMG ISMAP SRC="/images/imagemap1.gif"> <BR>
</A>
-</code></blockquote><p>
+</CODE></BLOCKQUOTE><P>
<!--#include virtual="footer.html" -->
</BODY>
1.17 +121 -121 apachen/htdocs/manual/mod/mod_include.html
Index: mod_include.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_include.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- mod_include.html 1997/08/28 15:24:07 1.16
+++ mod_include.html 1998/01/26 16:54:13 1.17
@@ -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 @@
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>
-<!--#</code><em>element attribute=value attribute=value ...</em>
-<code> -->
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+<!--#</CODE><EM>element attribute=value attribute=value ...</EM>
+<CODE> -->
+</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>--></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 @@
CGI scripts. Otherwise CGI scripts are invoked as normal using the complete
URL given in the command, including any query string.
<!--%plaintext <?INDEX CGI scripts, {\tt include} element and> -->
-<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><!--#printenv --></code>
-<dd>Apache 1.2 and above.
+<DD>For example: <CODE><!--#printenv --></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>
+<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><!--#set var="category" value="help" --></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.
+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
+<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 @@
<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 <?INDEX {\tt XBitHack} directive> -->
-<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>
1.7 +9 -9 apachen/htdocs/manual/mod/mod_info.html
Index: mod_info.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_info.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_info.html 1997/09/11 13:27:51 1.6
+++ mod_info.html 1998/01/26 16:54:14 1.7
@@ -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 @@
<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>
<Location /server-info>
@@ -50,9 +50,9 @@
<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,
1.3 +22 -22 apachen/htdocs/manual/mod/mod_isapi.html
Index: mod_isapi.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_isapi.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mod_isapi.html 1997/12/29 20:41:52 1.2
+++ mod_isapi.html 1998/01/26 16:54:14 1.3
@@ -14,59 +14,59 @@
>
<!--#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>
-
-<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>
+</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>
<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>
1.6 +21 -21 apachen/htdocs/manual/mod/mod_log_agent.html
Index: mod_log_agent.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_log_agent.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- mod_log_agent.html 1997/06/04 16:14:21 1.5
+++ mod_log_agent.html 1998/01/26 16:54:15 1.6
@@ -13,47 +13,47 @@
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 <?INDEX {\tt AgentLog} directive> -->
-<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>
1.7 +47 -47 apachen/htdocs/manual/mod/mod_log_common.html
Index: mod_log_common.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_log_common.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_log_common.html 1997/06/04 16:14:22 1.6
+++ mod_log_common.html 1998/01/26 16:54:15 1.7
@@ -13,9 +13,9 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Module mod_log_common</h1>
+<H1 ALIGN="CENTER">Module mod_log_common</H1>
-This module is contained in the <code>mod_log_common.c</code> file,
+This module is contained in the <CODE>mod_log_common.c</CODE> file,
and is compiled in by default. It provides for logging of the requests
made to the server using the Common Logfile Format. This module has
been replaced by mod_log_config in Apache 1.2
@@ -23,73 +23,73 @@
<h2>Log file format</h2>
The log 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>"</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>"</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>
<h2>Directives</h2>
-<ul>
-<li><A HREF="#transferlog">TransferLog</A>
-</ul>
-<hr>
+<UL>
+<LI><A HREF="#transferlog">TransferLog</A>
+</UL>
+<HR>
<h2><A name="transferlog">TransferLog</A></h2>
<!--%plaintext <?INDEX {\tt TransferLog} directive> -->
-<strong>Syntax:</strong> TransferLog <em>file-pipe</em><br>
-<strong>Default:</strong> <code>TransferLog logs/transfer_log</code><br>
-<Strong>Context:</strong> server config, virtual host<br>
-<strong>Status:</strong> Base<br>
-<strong>Module:</strong> mod_log_common<p>
+<STRONG>Syntax:</STRONG> TransferLog <EM>file-pipe</EM><BR>
+<STRONG>Default:</STRONG> <CODE>TransferLog logs/transfer_log</CODE><BR>
+<Strong>Context:</STRONG> server config, virtual host<BR>
+<STRONG>Status:</STRONG> Base<BR>
+<STRONG>Module:</STRONG> mod_log_common<P>
The TransferLog directive sets the name of the file to which the server will
-log the incoming requests. <em>File-pipe</em> is one
+log the 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 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>
-<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
1.21 +91 -91 apachen/htdocs/manual/mod/mod_log_config.html
Index: mod_log_config.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_log_config.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- mod_log_config.html 1997/12/14 00:57:46 1.20
+++ mod_log_config.html 1998/01/26 16:54:15 1.21
@@ -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 @@
<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>"</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>"</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 @@
%...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 @@
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 @@
<h3>Use with Virtual Hosts</h3>
If a <VirtualHost> 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 @@
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 <?INDEX {\tt CookieLog} directive> -->
-<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 @@
<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 @@
<HR>
<h2><A name="logformat">LogFormat</A></h2>
<!--%plaintext <?INDEX {\tt LogFormat} directive> -->
-<strong>Syntax:</strong> LogFormat <em>format</em> [<EM>nickname</EM>]
-<br>
-<strong>Default:</strong> <code>LogFormat "%h %l %u %t \"%r\"
-%s %b"</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 "%h %l %u %t \"%r\"
+%s %b"</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 @@
it doesn't actually apply the format and make it the default.
</P>
-<hr>
+<HR>
<h2><A name="transferlog">TransferLog</A></h2>
<!--%plaintext <?INDEX {\tt TransferLog} directive> -->
-<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 @@
><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" -->
1.6 +31 -31 apachen/htdocs/manual/mod/mod_log_referer.html
Index: mod_log_referer.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_log_referer.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- mod_log_referer.html 1997/06/04 16:14:22 1.5
+++ mod_log_referer.html 1998/01/26 16:54:16 1.6
@@ -13,74 +13,74 @@
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>-></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>-></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 <?INDEX {\tt RefererIgnore} directive> -->
-<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 <?INDEX {\tt RefererLog} directive> -->
-<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>
1.16 +110 -110 apachen/htdocs/manual/mod/mod_mime.html
Index: mod_mime.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_mime.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- mod_mime.html 1997/08/26 16:49:51 1.15
+++ mod_mime.html 1998/01/26 16:54:16 1.16
@@ -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 @@
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 <?INDEX {\tt AddEncoding} directive> -->
-<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>
+encoding, and .Z files to be marked as encoded with x-compress.<P><HR>
-<h2><a name="addhandler">AddHandler</a></h2>
+<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>
+<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 <?INDEX {\tt AddLanguage} directive> -->
-<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 <?INDEX {\tt AddType} directive> -->
-<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><Directory></code> or <code><Location></code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE><Directory></CODE> or <CODE><Location></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>
-
-<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>
+</PRE>
+<P>Note that this will override any filename extensions that might
+media type.</P>
+
+<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>
-<p>When placed into an <code>.htaccess</code> file or a
-<code><Directory></code> or <code><Location></code> section,
+<P>When placed into an <CODE>.htaccess</CODE> file or a
+<CODE><Directory></CODE> or <CODE><Location></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>
<Location /status>
SetHandler server-status
</Location>
-</pre>
+</PRE>
<HR>
<h2><A name="typesconfig">TypesConfig</A></h2>
<!--%plaintext <?INDEX {\tt TypesConfig} directive> -->
-<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>
1.6 +63 -63 apachen/htdocs/manual/mod/mod_mime_magic.html
Index: mod_mime_magic.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_mime_magic.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- mod_mime_magic.html 1998/01/25 03:52:19 1.5
+++ mod_mime_magic.html 1998/01/26 16:54:17 1.6
@@ -15,85 +15,85 @@
<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>
- ">" indicates a dependency upon the previous non-">" 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>
+ ">" indicates a dependency upon the previous non-">" 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
>12 belong 1 audio/basic
@@ -104,13 +104,13 @@
>12 belong 6 audio/basic
>12 belong 7 audio/basic
>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 \<MakerFile application/x-frame
0 string \<MIFFile application/x-frame
@@ -124,23 +124,23 @@
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
@@ -152,14 +152,14 @@
...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>
@@ -170,7 +170,7 @@
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>
@@ -179,24 +179,24 @@
<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.
@@ -254,7 +254,7 @@
* - Command-line flags have been removed since they will never be used here.
*
*/
-</pre>
+</PRE>
</BODY>
</HTML>
1.8 +55 -55 apachen/htdocs/manual/mod/mod_negotiation.html
Index: mod_negotiation.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_negotiation.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- mod_negotiation.html 1997/07/06 17:19:17 1.7
+++ mod_negotiation.html 1998/01/26 16:54:17 1.8
@@ -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 @@
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 @@
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>
+<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
+<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 @@
<h2><A name="languagepriority">LanguagePriority</A></h2>
<!--%plaintext <?INDEX {\tt LanguagePriority} directive> -->
-<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>
1.31 +230 -230 apachen/htdocs/manual/mod/mod_proxy.html
Index: mod_proxy.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_proxy.html,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- mod_proxy.html 1997/12/16 22:07:33 1.30
+++ mod_proxy.html 1998/01/26 16:54:18 1.31
@@ -13,77 +13,77 @@
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>
+<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>
+<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><match> <remote-server></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><match> <remote-server></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. <match> is either the
name of a URL-scheme that the remote server supports, or a partial URL
@@ -91,19 +91,19 @@
server should be contacted for all requests. <remote-server> is a
partial URL for the remote server. Syntax:
-<pre>
+<PRE>
<remote-server> = <protocol>://<hostname>[:port]
-</pre>
+</PRE>
<protocol> 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 @@
<HR>
<A name="proxypass"><h2>ProxyPass</h2></A>
-<strong>Syntax:</strong> ProxyPass <em><path> <url></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><path> <url></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 @@
a local virtual path; <url> 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
<<SAMP>http://wibble.org/mirror/foo/bar</SAMP>> to be
internally converted into a proxy request to
@@ -138,52 +138,52 @@
<HR>
<A name="proxyblock"><h2>ProxyBlock</h2></A>
-<strong>Syntax:</strong> ProxyBlock <em><word/host/domain list></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><word/host/domain list></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><Domain></em></A>
- | <A HREF="#subnet"><em><SubNet></em></A>
- | <A HREF="#ipaddr"><em><IpAddr></em></A>
- | <A HREF="#hostname"><em><Hostname></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><Domain></EM></A>
+ | <A HREF="#subnet"><EM><SubNet></EM></A>
+ | <A HREF="#ipaddr"><EM><IpAddr></EM></A>
+ | <A HREF="#hostname"><EM><Hostname></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 @@
<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 @@
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 @@
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><Domain></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><Domain></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><directory></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><directory></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 @@
<HR>
<A name="cachesize"><h2>CacheSize</h2></A>
-<strong>Syntax:</strong> CacheSize <em><size></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><size></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 @@
<HR>
<A name="cachegcinterval"><h2>CacheGcInterval</h2></A>
-<strong>Syntax:</strong> CacheGcInterval <em><time></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><time></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 <time> hours, and delete files if the space
usage is greater than that set by CacheSize.
@@ -361,14 +361,14 @@
<HR>
<A name="cachemaxexpire"><h2>CacheMaxExpire</h2></A>
-<strong>Syntax:</strong> CacheMaxExpire <em><time></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><time></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 <time> hours without
checking the origin server. Thus documents can be at most <time>
@@ -378,37 +378,37 @@
<HR>
<A name="cachelastmodifiedfactor"><h2>CacheLastModifiedFactor</h2></A>
-<strong>Syntax:</strong> CacheLastModifiedFactor <em><factor></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><factor></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 * <factor>
-</pre>
+</PRE>
For example, if the document was last modified 10 hours ago, and
<factor> 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><levels></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><levels></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 @@
<HR>
<A name="cachedirlength"><h2>CacheDirLength</h2></A>
-<strong>Syntax:</strong> CacheDirLength <em><length></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><length></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><time></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><time></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 <time> 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><word/host/domain list></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><word/host/domain list></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 <Directory>
-control block using the following example:<p>
+control block using the following example:<P>
-<pre>
+<PRE>
<Directory proxy:*>
<Limit GET PUT POST DELETE CONNECT OPTIONS>
order deny,allow
@@ -506,68 +506,68 @@
allow from [machines you'd like to allow by IP address or name]
</Limit>
</Directory>
-</pre><p>
+</PRE><P>
A <Files> 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 @@
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>
1.19 +711 -711 apachen/htdocs/manual/mod/mod_rewrite.html
Index: mod_rewrite.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_rewrite.html,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- mod_rewrite.html 1997/11/01 03:58:32 1.18
+++ mod_rewrite.html 1998/01/26 16:54:18 1.19
@@ -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
@@ -17,303 +17,303 @@
>
<!--#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>
-
-<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>
+<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>
+
+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>
-
-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>.
+<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>.
-<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 (<STDIN>) {
@@ -321,86 +321,86 @@
# 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>
-
-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
+<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
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 @@
# 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 @@
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 @@
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 & request:</b><p>
+<STRONG>connection & 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>
+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>
+</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>
+API_VERSION<BR>
+THE_REQUEST<BR>
+REQUEST_URI<BR>
+REQUEST_FILENAME<BR>
+IS_SUBREQ<BR>
+</FONT>
+</TD>
+</TR>
+</TABLE>
-<p>
+<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><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>>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><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>>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 @@
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
+<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
+<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><!--#echo var="VAR"--></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><!--#echo var="VAR"--></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 @@
^/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>
+</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>
+<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 @@
^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" -->
1.4 +23 -23 apachen/htdocs/manual/mod/mod_speling.html
Index: mod_speling.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_speling.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- mod_speling.html 1997/12/29 20:41:53 1.3
+++ mod_speling.html 1998/01/26 16:54:19 1.4
@@ -14,11 +14,11 @@
<!--#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,
@@ -36,38 +36,38 @@
<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 <?INDEX {\tt CheckSpelling} directive> -->
- <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>
1.9 +31 -31 apachen/htdocs/manual/mod/mod_status.html
Index: mod_status.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_status.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- mod_status.html 1997/07/06 17:19:19 1.8
+++ mod_status.html 1998/01/26 16:54:19 1.9
@@ -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 @@
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 @@
<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>
<Location /server-status>
SetHandler server-status
@@ -57,11 +57,11 @@
deny from all
allow from .foo.com
</Location>
-</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 @@
<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>
1.2 +32 -32 apachen/htdocs/manual/mod/mod_unique_id.html
Index: mod_unique_id.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_unique_id.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- mod_unique_id.html 1997/10/24 09:34:21 1.1
+++ mod_unique_id.html 1998/01/26 16:54:20 1.2
@@ -13,19 +13,19 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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>
1.11 +20 -20 apachen/htdocs/manual/mod/mod_userdir.html
Index: mod_userdir.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_userdir.html,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- mod_userdir.html 1997/07/06 17:19:19 1.10
+++ mod_userdir.html 1998/01/26 16:54:20 1.11
@@ -13,33 +13,33 @@
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 <?INDEX {\tt UserDir} directive> -->
-<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 @@
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 -> ~bob/public_html/one/two.html
UserDir /usr/web -> /usr/web/bob/one/two.html
UserDir /home/*/www -> /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 -> http//www.foo.com/users/bob/one/two.html
UserDir http://www.foo.com/*/usr -> http://www.foo.com/bob/usr/one/two.html
UserDir http://www.foo.com/~*/ -> http://www.foo.com/~bob/one/two.html
-</pre>
+</PRE>
</P>
<BLOCKQUOTE>
<STRONG>
1.13 +32 -32 apachen/htdocs/manual/mod/mod_usertrack.html
Index: mod_usertrack.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/mod/mod_usertrack.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- mod_usertrack.html 1997/11/11 22:47:40 1.12
+++ mod_usertrack.html 1998/01/26 16:54:21 1.13
@@ -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 @@
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>
-
-<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>
+<UL>
+<LI><A HREF="#cookieexpires">CookieExpires</A>
+<LI><A HREF="#cookietracking">CookieTracking</A>
+</UL>
+
+<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>
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
1.3 +126 -126 apachen/htdocs/manual/vhosts/details.html
Index: details.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/details.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- details.html 1997/12/29 20:41:54 1.2
+++ details.html 1998/01/26 16:54:31 1.3
@@ -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
@@ -12,27 +12,27 @@
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><VirtualHost></CODE> sections.
There are virtual servers, called <EM>vhosts</EM>, which are defined by
<A HREF="../mod/core.html#virtualhost"><SAMP><VirtualHost></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 @@
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 @@
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 | <VirtualHost 111.22.33.44>
<VirtualHost 111.22.33.44> | # server A
@@ -107,58 +107,58 @@
... | NameVirtualHost 111.22.33.55
</VirtualHost> |
|
-</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>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> 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
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:
+<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>,
+<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 "lookup defaults" that define the default directory
+<LI>The "lookup defaults" 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 "defaults" or a
"base" on which to build each vhost.
@@ -168,33 +168,33 @@
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 @@
<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 @@
<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 @@
<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>, "ServerPath /abc" should appear after
"ServerPath /abc/def").
- <p>
+ <P>
-</ul>
+</UL>
<!--#include virtual="footer.html" -->
</BODY>
1.2 +131 -131 apachen/htdocs/manual/vhosts/details_1_2.html
Index: details_1_2.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/details_1_2.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- details_1_2.html 1997/11/11 23:47:18 1.1
+++ details_1_2.html 1998/01/26 16:54:32 1.2
@@ -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
@@ -12,20 +12,20 @@
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 "make it work" without understanding
-how, there's a <a href="#whatworks">What Works</a> section at the bottom.
+<P>If you just want to "make it work" 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 @@
><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 @@
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>
<VirtualHost A>
...
</VirtualHost>
@@ -103,53 +103,53 @@
<VirtualHost C>
...
</VirtualHost>
-</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 "lookup defaults" that define the default directory
+<LI>The "lookup defaults" 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 "defaults" or a
"base" on
@@ -159,134 +159,134 @@
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
"main IP address". 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 @@
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>, "ServerPath /abc" should appear after
"ServerPath /abcdef").
-<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>
1.3 +175 -175 apachen/htdocs/manual/vhosts/examples.html
Index: examples.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/examples.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- examples.html 1997/12/29 20:41:55 1.2
+++ examples.html 1998/01/26 16:54:32 1.3
@@ -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
@@ -12,45 +12,45 @@
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
@@ -61,20 +61,20 @@
ServerName www.otherdomain.tld
...
</VirtualHost>
- </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
@@ -90,28 +90,28 @@
ServerName www.otherdomain.tld
...
</VirtualHost>
- </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
@@ -133,28 +133,28 @@
allow from 111.22.33
</Directory>
</VirtualHost>
- </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
@@ -172,33 +172,33 @@
ServerName www.sub.domain.tld
...
</VirtualHost>
- </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
@@ -218,13 +218,13 @@
ServerAlias *.sub.domain.tld
...
</VirtualHost>
- </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>
@@ -232,18 +232,18 @@
<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
@@ -279,26 +279,26 @@
ServerName www.otherdomain2.tld
...
</VirtualHost>
- </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
@@ -309,56 +309,56 @@
DocumentRoot /www/domain2
...
</VirtualHost>
- </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>
...
<VirtualHost _default_:*>
DocumentRoot /www/default
...
</VirtualHost>
- </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>
...
<VirtualHost _default_:80>
DocumentRoot /www/default80
@@ -369,52 +369,52 @@
DocumentRoot /www/default
...
</VirtualHost>
- </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>
...
<VirtualHost _default_:80>
DocumentRoot /www/default
...
</VirtualHost>
- </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
@@ -434,31 +434,31 @@
ServerAlias *.sub.domain.tld
...
</VirtualHost>
- </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
@@ -487,25 +487,25 @@
RewriteRule ^(/sub2/.*) /www/subdomain$1
...
</VirtualHost>
- </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>
1.2 +22 -22 apachen/htdocs/manual/vhosts/fd-limits.html
Index: fd-limits.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/fd-limits.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- fd-limits.html 1997/11/11 23:47:19 1.1
+++ fd-limits.html 1998/01/26 16:54:33 1.2
@@ -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
@@ -13,40 +13,40 @@
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 @@
</P>
<!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
1.2 +74 -74 apachen/htdocs/manual/vhosts/host.html
Index: host.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/host.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- host.html 1997/11/12 13:37:53 1.1
+++ host.html 1998/01/26 16:54:33 1.2
@@ -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
@@ -12,115 +12,115 @@
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>
<VirtualHost www.apache.org>
ServerName www.apache.org
DocumentRoot /usr/web/apache
</VirtualHost>
-</pre>
+</PRE>
-<p>Of course, any additional directives can (and should) be placed
-into the <code><VirtualHost></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><VirtualHost></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
-<VirtualHost> entry.</p>
+<VirtualHost> 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 <VirtualHost> 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 @@
<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>
1.2 +5 -5 apachen/htdocs/manual/vhosts/index.html
Index: index.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html 1997/11/11 23:47:21 1.1
+++ index.html 1998/01/26 16:54:34 1.2
@@ -13,16 +13,16 @@
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
1.4 +26 -26 apachen/htdocs/manual/vhosts/ip-based.html
Index: ip-based.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/ip-based.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ip-based.html 1997/11/12 21:11:58 1.3
+++ ip-based.html 1998/01/26 16:54:34 1.4
@@ -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
@@ -13,16 +13,16 @@
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 @@
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 @@
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 @@
<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 @@
<A HREF="../mod/mod_log_config.html#customlog">CustomLog</A>
configuration directives to different values for each virtual host.
e.g.
-<pre>
+<PRE>
<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
@@ -101,14 +101,14 @@
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>
-</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 @@
</P>
<!--#include virtual="footer.html" -->
-</body>
-</html>
+</BODY>
+</HTML>
1.3 +61 -61 apachen/htdocs/manual/vhosts/name-based.html
Index: name-based.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/name-based.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- name-based.html 1997/11/12 21:11:59 1.2
+++ name-based.html 1998/01/26 16:54:34 1.3
@@ -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
@@ -12,98 +12,98 @@
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
<VirtualHost 111.22.33.44>
ServerName www.domain.tld
DocumentRoot /web/domain
</VirtualHost>
-</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><VirtualHost></code> section. To make this work,
+<P>Of course, any additional directives can (and should) be placed
+into the <CODE><VirtualHost></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 <VirtualHost> 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
<VirtualHost 111.22.33.44>
@@ -111,30 +111,30 @@
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>
-</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>
1.2 +131 -131 apachen/htdocs/manual/vhosts/vhosts-in-depth.html
Index: vhosts-in-depth.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/vhosts-in-depth.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- vhosts-in-depth.html 1997/11/12 13:37:54 1.1
+++ vhosts-in-depth.html 1998/01/26 16:54:35 1.2
@@ -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
@@ -12,20 +12,20 @@
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 "make it work" without understanding
-how, there's a <a href="#whatworks">What Works</a> section at the bottom.
+<P>If you just want to "make it work" 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 @@
><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 @@
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>
<VirtualHost A>
...
</VirtualHost>
@@ -103,53 +103,53 @@
<VirtualHost C>
...
</VirtualHost>
-</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 "lookup defaults" that define the default directory
+<LI>The "lookup defaults" 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 "defaults" or a
"base" on
@@ -159,134 +159,134 @@
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
"main IP address". 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 @@
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>, "ServerPath /abc" should appear after
"ServerPath /abcdef").
-<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>
1.3 +69 -69 apachen/htdocs/manual/vhosts/virtual-host.html
Index: virtual-host.html
===================================================================
RCS file: /export/home/cvs/apachen/htdocs/manual/vhosts/virtual-host.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- virtual-host.html 1997/12/16 22:28:39 1.2
+++ virtual-host.html 1998/01/26 16:54:35 1.3
@@ -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
@@ -13,71 +13,71 @@
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 @@
<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 @@
<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> configuration
directives to different values for each virtual host.
e.g.
-<blockquote><code>
-<VirtualHost www.smallco.com><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>
-</VirtualHost><br>
-<br>
-<VirtualHost www.baygroup.org><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>
-</VirtualHost><br>
-</code></blockquote>
+<BLOCKQUOTE><CODE>
+<VirtualHost www.smallco.com><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>
+</VirtualHost><BR>
+<BR>
+<VirtualHost www.baygroup.org><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>
+</VirtualHost><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 @@
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 @@
The latter will probably manifest itself in a later version of Apache.
<!--#include virtual="footer.html" -->
-</body></html>
+</BODY></HTML>
Re: cvs commit: apachen/htdocs/manual/vhosts details.html details_1_2.html examples.html fd-limits.html host.html index.html ip-based.html name-based.html vhosts-in-depth.html virtual-host.html
Posted by Marc Slemko <ma...@worldgate.com>.
-<h1 ALIGN="CENTER">Setting which addresses and ports Apache uses</h1>
+<h1 ALIGN="CENTER">Setting which addresses and ports Apache uses</H1>
missed some.