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>
to more than one address and/or port.
</UL>
-<h3><A name="bindaddress">BindAddress</A></h3>
+<H3><A name="bindaddress">BindAddress</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
is set with the <TT>Port</TT> directive. Only one BindAddress
should be used.
-<h3><A name="listen">Listen</A></h3>
+<H3><A name="listen">Listen</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
Listen 192.170.2.5:8000
</PRE>
-<h2>How this works with Virtual Hosts</h2>
+<H2>How this works with Virtual Hosts</H2>
BindAddress and Listen do not implement Virtual Hosts. They tell the
main server what addresses and ports to listen to. If no
<VirtualHost> is set for an address and port that the server is
not listening to, it cannot be accessed.
-<h2>See also</h2>
+<H2>See also</H2>
See also the documentation on
<A HREF="vhosts/index.html">Virtual Hosts</A>,
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>
to more than one address and/or port.
</UL>
-<h3><A name="bindaddress">BindAddress</A></h3>
+<H3><A name="bindaddress">BindAddress</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
is set with the <TT>Port</TT> directive. Only one BindAddress
should be used.
-<h3><A name="listen">Listen</A></h3>
+<H3><A name="listen">Listen</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
Listen 192.170.2.5:8000
</PRE>
-<h2>How this works with Virtual Hosts</h2>
+<H2>How this works with Virtual Hosts</H2>
BindAddress and Listen do not implement Virtual Hosts. They tell the
main server what addresses and ports to listen to. If no
<VirtualHost> is set for an address and port that the server is
not listening to, it cannot be accessed.
-<h2>See also</h2>
+<H2>See also</H2>
See also the documentation on
<A HREF="vhosts/index.html">Virtual Hosts</A>,
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>
-<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
Apache used to create PATH_INFO in the CGI environment was
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
environment variables by looking at the filename, not the URL. While
incorrect. In certain cases, this could even cause the server to
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
looking directly at the URL, and determining how much of the URL is
use of it "deserves" not to work. Apache 1.2b3 and later, however, do
provide <A HREF="#compat">a workaround.</A>
-<h2><A name="compat">Compatibility with Previous Servers</A></h2>
+<H2><A name="compat">Compatibility with Previous Servers</A></H2>
<P>It may be necessary for a script that was designed for earlier
versions of Apache or other servers to need the information that the
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>
-<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
Apache used to create PATH_INFO in the CGI environment was
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
environment variables by looking at the filename, not the URL. While
incorrect. In certain cases, this could even cause the server to
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
looking directly at the URL, and determining how much of the URL is
use of it "deserves" not to work. Apache 1.2b3 and later, however, do
provide <A HREF="#compat">a workaround.</A>
-<h2><A name="compat">Compatibility with Previous Servers</A></h2>
+<H2><A name="compat">Compatibility with Previous Servers</A></H2>
<P>It may be necessary for a script that was designed for earlier
versions of Apache or other servers to need the information that the
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Content Negotiation</H1>
+<H1 ALIGN="CENTER">Content Negotiation</H1>
<P>
Apache's support for content negotiation has been updated to meet the
<HR>
-<h2>About Content Negotiation</h2>
+<H2>About Content Negotiation</H2>
<P>
A resource may be available in several different representations. For
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>
+<H2>Negotiation in Apache</H2>
<P>
In order to negotiate a resource, the server needs to be given
filename pattern match, and chooses from among the results.
</UL>
-<h3>Using a type-map file</h3>
+<H3>Using a type-map file</H3>
<P>
A type map is a document which is associated with the handler
thresholds without checking the actual file.
</DL>
-<h3>Multiviews</h3>
+<H3>Multiviews</H3>
<P>
This is a per-directory option, meaning it can be set with an
quality rating, which generally causes one of the other views (if any)
to be retrieved.
-<h2>The Negotiation Algorithm</h2>
+<H2>The Negotiation Algorithm</H2>
After Apache has obtained a list of the variants for a given resource,
either from a type-map file or from the filenames in the directory, it
particular dimension to achieve a better result. The ways Apache can
fiddle quality factors is explained in more detail below.
-<h3>Dimensions of Negotiation</h3>
+<H3>Dimensions of Negotiation</H3>
<TABLE>
<TR><TH>Dimension
can indicate a charset as a parameter of the media type.
</TABLE>
-<h3>Apache Negotiation Algorithm</h3>
+<H3>Apache Negotiation Algorithm</H3>
<P>
Apache uses an algorithm to select the 'best' variant (if any) to
</OL>
-<h2><A name="better">Fiddling with Quality Values</A></h2>
+<H2><A name="better">Fiddling with Quality Values</A></H2>
<P>
Apache sometimes changes the quality values from what would be
be applied.
<P>
-<h3>Media Types and Wildcards</h3>
+<H3>Media Types and Wildcards</H3>
<P>
The Accept: request header indicates preferences for media types. It
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>
+<H3>Variants with no Language</H3>
<P>
If some of the variants for a particular resource have a language
or foo.fr.html will be returned. If the browser does not list
either en or fr as acceptable, foo.html will be returned instead.
-<h2>Note on hyperlinks and naming conventions</h2>
+<H2>Note on hyperlinks and naming conventions</H2>
<P>
If you are using language negotiation you can choose between
(e.g. <SAMP>foo.html.en</SAMP>).
-<h2>Note on Caching</h2>
+<H2>Note on Caching</H2>
<P>
When a cache stores a document, it associates it with the request URL.
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Content Negotiation</H1>
+<H1 ALIGN="CENTER">Content Negotiation</H1>
<P>
Apache's support for content negotiation has been updated to meet the
<HR>
-<h2>About Content Negotiation</h2>
+<H2>About Content Negotiation</H2>
<P>
A resource may be available in several different representations. For
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>
+<H2>Negotiation in Apache</H2>
<P>
In order to negotiate a resource, the server needs to be given
filename pattern match, and chooses from among the results.
</UL>
-<h3>Using a type-map file</h3>
+<H3>Using a type-map file</H3>
<P>
A type map is a document which is associated with the handler
thresholds without checking the actual file.
</DL>
-<h3>Multiviews</h3>
+<H3>Multiviews</H3>
<P>
This is a per-directory option, meaning it can be set with an
quality rating, which generally causes one of the other views (if any)
to be retrieved.
-<h2>The Negotiation Algorithm</h2>
+<H2>The Negotiation Algorithm</H2>
After Apache has obtained a list of the variants for a given resource,
either from a type-map file or from the filenames in the directory, it
particular dimension to achieve a better result. The ways Apache can
fiddle quality factors is explained in more detail below.
-<h3>Dimensions of Negotiation</h3>
+<H3>Dimensions of Negotiation</H3>
<TABLE>
<TR><TH>Dimension
can indicate a charset as a parameter of the media type.
</TABLE>
-<h3>Apache Negotiation Algorithm</h3>
+<H3>Apache Negotiation Algorithm</H3>
<P>
Apache uses an algorithm to select the 'best' variant (if any) to
</OL>
-<h2><A name="better">Fiddling with Quality Values</A></h2>
+<H2><A name="better">Fiddling with Quality Values</A></H2>
<P>
Apache sometimes changes the quality values from what would be
be applied.
<P>
-<h3>Media Types and Wildcards</h3>
+<H3>Media Types and Wildcards</H3>
<P>
The Accept: request header indicates preferences for media types. It
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>
+<H3>Variants with no Language</H3>
<P>
If some of the variants for a particular resource have a language
or foo.fr.html will be returned. If the browser does not list
either en or fr as acceptable, foo.html will be returned instead.
-<h2>Note on hyperlinks and naming conventions</h2>
+<H2>Note on hyperlinks and naming conventions</H2>
<P>
If you are using language negotiation you can choose between
(e.g. <SAMP>foo.html.en</SAMP>).
-<h2>Note on Caching</h2>
+<H2>Note on Caching</H2>
<P>
When a cache stores a document, it associates it with the request URL.
<P><HR><P>
-<h2>Custom error responses and redirects</H2>
+<H2>Custom error responses and redirects</H2>
<DL>
<P><HR><P>
-<h2>Custom error responses and redirects</H2>
+<H2>Custom error responses and redirects</H2>
<DL>
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
</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
<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
};
</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.
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>
-<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
which will be cleared when the server is finished handling the
</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
request from a client, and filling in the fields. However, there are
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>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
(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:
to be sent back).
</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
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,
discuss how other resources are tracked by the resource pool
machinery.
-<h3>Allocation of memory in pools</h3>
+<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
to avoid excessive storage allocation when listing directories with
thousands of files).
-<h3>Allocating initialized memory</h3>
+<H3>Allocating initialized memory</H3>
There are functions which allocate initialized memory, and are
frequently useful. The function <CODE>pcalloc</CODE> has the same
returns a pointer to 8 bytes worth of memory, initialized to
<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
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>
+<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>.
-<h3>Fine control --- creating and dealing with sub-pools, with a note
-on sub-requests</h3>
+<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
associated primitives may result in undesirably profligate resource
for a single main request that you should seriously consider the
<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
else similar problems come up, by tying those structures to the
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>,
which defines the file typing handler which emulates the NCSA server's
those modules, you can just not declare one, and leave the
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
</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
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: <EM>don't require
Apache to use DNS for any parsing of the configuration files</EM>.
denial and theft of service attacks (including users able to steal hits
from other users).
-<h3>A Simple Example</h3>
+<H3>A Simple Example</H3>
Consider this configuration snippet:
</VirtualHost>
</PRE></BLOCKQUOTE>
-<h3>Denial of Service</h3>
+<H3>Denial of Service</H3>
<P>There are (at least) two forms that denial of service can come in.
If you are running a version of Apache prior to version 1.2 then your
up incoming requests with the virtual host that will serve it. A rough
document describing this <A HREF="vhosts/details.html"> is available</A>.
-<h3>The "main server" Address</h3>
+<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
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>
has no pages to serve
</UL>
-<h3>Appendix: Future Directions</h3>
+<H3>Appendix: Future Directions</H3>
<P>The situation regarding DNS is highly undesirable. For Apache
1.2 we've attempted to make the server at least continue booting
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
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
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>
+<H2>What is a Handler</H2>
<P>A "handler" is an internal Apache representation of the action to be
performed when a file is called. Generally, files have implicit
<P>
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#addhandler">AddHandler</A>
<LI><A HREF="#sethandler">SetHandler</A>
<HR>
-<h2><A name="addhandler">AddHandler</A></h2>
+<H2><A name="addhandler">AddHandler</A></H2>
<A
HREF="directive-dict.html#Syntax"
<HR>
-<h2><A name="sethandler">SetHandler</A></h2>
+<H2><A name="sethandler">SetHandler</A></H2>
<A
HREF="directive-dict.html#Syntax"
<P><HR>
-<h2>Programmer's Note</h2>
+<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
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>
+<H2>What is a Handler</H2>
<P>A "handler" is an internal Apache representation of the action to be
performed when a file is called. Generally, files have implicit
<P>
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#addhandler">AddHandler</A>
<LI><A HREF="#sethandler">SetHandler</A>
<HR>
-<h2><A name="addhandler">AddHandler</A></h2>
+<H2><A name="addhandler">AddHandler</A></H2>
<A
HREF="directive-dict.html#Syntax"
<HR>
-<h2><A name="sethandler">SetHandler</A></h2>
+<H2><A name="sethandler">SetHandler</A></H2>
<A
HREF="directive-dict.html#Syntax"
<P><HR>
-<h2>Programmer's Note</h2>
+<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
HREF="#install">Installing Apache</A>. Otherwise read the next section
for how to compile the server.
-<h2>Compiling Apache</h2>
+<H2>Compiling Apache</H2>
Compiling Apache consists of three steps: Firstly select which Apache
<STRONG>modules</STRONG> you want to include into the server. Secondly create a
There are instructions on that page for linking these modules into the
core Apache code.
-<h2><A NAME="install">Installing Apache</A></h2>
+<H2><A NAME="install">Installing Apache</A></H2>
You will have a binary file called <CODE>httpd</CODE> in the
<CODE>src</CODE> directory. A binary distribution of Apache will
HREF="#install">Installing Apache</A>. Otherwise read the next section
for how to compile the server.
-<h2>Compiling Apache</h2>
+<H2>Compiling Apache</H2>
Compiling Apache consists of three steps: Firstly select which Apache
<STRONG>modules</STRONG> you want to include into the server. Secondly create a
There are instructions on that page for linking these modules into the
core Apache code.
-<h2><A NAME="install">Installing Apache</A></h2>
+<H2><A NAME="install">Installing Apache</A></H2>
You will have a binary file called <CODE>httpd</CODE> in the
<CODE>src</CODE> directory. A binary distribution of Apache will
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Starting Apache</H1>
+<H1 ALIGN="CENTER">Starting Apache</H1>
-<h2>Invoking Apache</h2>
+<H2>Invoking Apache</H2>
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
<A HREF="mod/core.html#servertype">ServerType</A> directive)
but this is not recommended.
-<h2>Command line options</h2>
+<H2>Command line options</H2>
The following options are recognized on the httpd command line:
<DL>
<DT><CODE>-d</CODE> <EM>serverroot</EM>
<DD>Print a list of the httpd options, and then exit.
</DL>
-<h2>Configuration files</h2>
+<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
is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> directive,
and is <CODE>conf/mime.types</CODE> by default.
-<h2>Log files</h2>
-<h3>security warning</h3>
+<H2>Log files</H2>
+<H3>security warning</H3>
Anyone who can write to the directory where Apache is writing a
log file can almost certainly gain access to the uid that the server is
started as, which is normally root. Do <EM>NOT</EM> give people write
access to the directory the logs are stored in without being aware of
the consequences; see the <A HREF="misc/security_tips.html">security tips</A>
document for details.
-<h3>pid file</h3>
+<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
<A HREF="mod/core.html#pidfile">PidFile</A> directive. The process-id is for
If the process dies (or is killed) abnormally, then it will be necessary to
kill the children httpd processes.
-<h3>Error log</h3>
+<H3>Error log</H3>
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>
+<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
<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Starting Apache</H1>
+<H1 ALIGN="CENTER">Starting Apache</H1>
-<h2>Invoking Apache</h2>
+<H2>Invoking Apache</H2>
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
<A HREF="mod/core.html#servertype">ServerType</A> directive)
but this is not recommended.
-<h2>Command line options</h2>
+<H2>Command line options</H2>
The following options are recognized on the httpd command line:
<DL>
<DT><CODE>-d</CODE> <EM>serverroot</EM>
<DD>Print a list of the httpd options, and then exit.
</DL>
-<h2>Configuration files</h2>
+<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
is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> directive,
and is <CODE>conf/mime.types</CODE> by default.
-<h2>Log files</h2>
-<h3>security warning</h3>
+<H2>Log files</H2>
+<H3>security warning</H3>
Anyone who can write to the directory where Apache is writing a
log file can almost certainly gain access to the uid that the server is
started as, which is normally root. Do <EM>NOT</EM> give people write
access to the directory the logs are stored in without being aware of
the consequences; see the <A HREF="misc/security_tips.html">security tips</A>
document for details.
-<h3>pid file</h3>
+<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
<A HREF="mod/core.html#pidfile">PidFile</A> directive. The process-id is for
If the process dies (or is killed) abnormally, then it will be necessary to
kill the children httpd processes.
-<h3>Error log</h3>
+<H3>Error log</H3>
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>
+<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
<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different
<!--#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>
<A
HREF="directive-dict.html#Syntax"
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
</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
<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
};
</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.
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>
-<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
which will be cleared when the server is finished handling the
</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
request from a client, and filling in the fields. However, there are
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>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
(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:
to be sent back).
</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
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,
discuss how other resources are tracked by the resource pool
machinery.
-<h3>Allocation of memory in pools</h3>
+<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
to avoid excessive storage allocation when listing directories with
thousands of files).
-<h3>Allocating initialized memory</h3>
+<H3>Allocating initialized memory</H3>
There are functions which allocate initialized memory, and are
frequently useful. The function <CODE>pcalloc</CODE> has the same
returns a pointer to 8 bytes worth of memory, initialized to
<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
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>
+<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>.
-<h3>Fine control --- creating and dealing with sub-pools, with a note
-on sub-requests</h3>
+<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
associated primitives may result in undesirably profligate resource
for a single main request that you should seriously consider the
<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
else similar problems come up, by tying those structures to the
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>,
which defines the file typing handler which emulates the NCSA server's
those modules, you can just not declare one, and leave the
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
</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
<HR>
-<h3>The New API Functions</h3>
+<H3>The New API Functions</H3>
<PRE>
int setup_client_block (request_rec *, int read_policy);
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<title>International Customized Server Error Messages</title>
-</head>
+<HTML>
+<HEAD>
+<TITLE>International Customized Server Error Messages</TITLE>
+</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
<LI>The <A HREF="../mod/mod_mime.html#addhandler">AddHandler</A> and
<A HREF="../mod/mod_mime.html#addtype">AddType</A> directives are useful
for automatically XSSI-expanding all files with a <SAMP>.shtml</SAMP>
- suffix to <em>text/html</em>.
+ suffix to <EM>text/html</EM>.
<LI>By using the <A HREF="../mod/mod_alias.html#alias">Alias</A> directive,
we keep the error document directory outside of the document tree
because it can be regarded more as a server part than part of
Note that we only define the basename of the document here
because the MultiViews option will select the best candidate
based on the language suffixes and the client's preferences.
- Any error situation with an error code <em>not</em> handled by a
+ Any error situation with an error code <EM>not</EM> handled by a
custom document will be dealt with by the server in the standard way
(i.e., a plain error message in english).
<LI>Finally, the <A HREF="../mod/core.html#allowoverride">AllowOverride</A>
optimization.
</OL>
The resulting <SAMP>httpd.conf</SAMP> configuration would the look
-similar to this: <small>(Note that you can defrine your own error
+similar to this: <SMALL>(Note that you can defrine your own error
messages using this method for only part of the document tree,
e.g., a /~user/ subtree. In this case, the configuration could as well
be put into the .htaccess file at the root of the subtree. In this case,
the <Directory> and </Directory> directives -but not
-the contained directives- must be omitted.)</small>
+the contained directives- must be omitted.)</SMALL>
<PRE>
LanguagePriority en fr de
Alias /errordocs /usr/local/apache/errordocs
would be bypassed.
<LI>For each language for which we have a translation (note that this need not
be the same set of languages for each error code - you can get by
- with a single language version until you actually <em>have</em>
+ with a single language version until you actually <EM>have</EM>
translated versions), a document
- <SAMP>errordocs/403.shtml.<em>lang</em></SAMP> is created and
+ <SAMP>errordocs/403.shtml.<EM>lang</EM></SAMP> is created and
filled with the error text in that language (<A HREF="#createdocs">see
below</A>).
<LI>One fallback document called <SAMP>errordocs/403.shtml</SAMP> is
information. The footer file exists once for each language translation,
plus a symlink for the default language.<P>
<STRONG>Example:</STRONG> for english, french and german versions (default english)<BR>
-<CODE>foot.shtml.en</CODE>,<br>
-<CODE>foot.shtml.fr</CODE>,<br>
-<CODE>foot.shtml.de</CODE>,<br>
+<CODE>foot.shtml.en</CODE>,<BR>
+<CODE>foot.shtml.fr</CODE>,<BR>
+<CODE>foot.shtml.de</CODE>,<BR>
<CODE>foot.shtml</CODE> symlink to <CODE>foot.shtml.en</CODE><P>
Both files are then simply included into the error document by using the
directives <CODE><!--#include virtual="head" --></CODE>
<H3>More welcome!</H3>
-If you have tips to contribute, send mail to <a
-href="mailto:Martin.Kraemer@Mch.SNI.De">Martin.Kraemer@Mch.SNI.De</a>
+If you have tips to contribute, send mail to <A
+HREF="mailto:Martin.Kraemer@Mch.SNI.De">Martin.Kraemer@Mch.SNI.De</A>
<HR>
<A HREF="./"><IMG SRC="../images/index.gif" ALT="Index"></A>
<A HREF="../"><IMG SRC="../images/home.gif" ALT="Home"></A>
-</body></html>
+</BODY></HTML>
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
+The second option is to set up a <CODE>ScriptAlias</CODE> pointing to
a <STRONG>cgi script</STRONG> which outputs a 301 or 302 status and the location
of the other server.</P>
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 <EM>keepalive</EM>
(persistent connections). In particular the Windows versions of
BrowserMatch "MSIE 4\.0b2;" nokeepalive
</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>
BrowserMatch "RealPlayer 4.0" force-response-1.0
</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
format but the responses must be in HTTP/1.0 format (in particular, it
<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)
have a problem if the trailing CRLF of the response header starts at
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 (")
around the boundary string. The MIME standard recommends that
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
portion of an object, not necessarily the entire object. There
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
duplicate names into one (separated by semicolon). Some browsers
headers returned by a CGI, Apache will explicitly avoid merging any
<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
GIF89A animations on each loop of the animation if the first
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
issue a POST without the request body. There is no
<P>Author: Dean Gaudet
-<h3>Introduction</h3>
+<H3>Introduction</H3>
<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
in fact it probably performs very poorly because NT performance requires
a different programming model.
-<h3>Hardware and Operating System Issues</h3>
+<H3>Hardware and Operating System Issues</H3>
<P>The single biggest hardware issue affecting webserver performance
is RAM. A webserver should never ever have to swap, swapping increases
kernels up through 1994 and even 1995. Good choices include
recent FreeBSD, and Linux.
-<h3>Run-Time Configuration Issues</h3>
+<H3>Run-Time Configuration Issues</H3>
-<h4>HostnameLookups</h4>
+<H4>HostnameLookups</H4>
<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
in some CGIs you could consider doing the
<CODE>gethostbyname</CODE> call in the specific CGIs that need it.
-<h4>FollowSymLinks and SymLinksIfOwnerMatch</h4>
+<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
set <CODE>FollowSymLinks</CODE> everywhere, and never set
<CODE>SymLinksIfOwnerMatch</CODE>.
-<h4>AllowOverride</h4>
+<H4>AllowOverride</H4>
<P>Wherever in your URL-space you allow overrides (typically
<CODE>.htaccess</CODE> files) Apache will attempt to open
FollowSymLinks</CODE>. For highest performance use
<CODE>AllowOverride None</CODE> everywhere in your filesystem.
-<h4>Negotiation</h4>
+<H4>Negotiation</H4>
<P>If at all possible, avoid content-negotiation if you're really
interested in every last ounce of performance. In practice the
where you list the most common choice first.
-<h4>Process Creation</h4>
+<H4>Process Creation</H4>
<P>Prior to Apache 1.3 the <CODE>MinSpareServers</CODE>,
<CODE>MaxSpareServers</CODE>, and <CODE>StartServers</CODE> settings
<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>
+<H3>Compile-Time Configuration Issues</H3>
-<h4>mod_status and Rule STATUS=yes</h4>
+<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
contains timing indications. For highest performance, set <CODE>Rule
STATUS=no</CODE>.
-<h4>accept Serialization - multiple sockets</h4>
+<H4>accept Serialization - multiple sockets</H4>
<P>This discusses a shortcoming in the Unix socket API.
Suppose your
<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>
+<H4>accept Serialization - single socket</H4>
<P>The above is fine and dandy for multiple socket servers, but what
about single socket servers? In theory they shouldn't experience
serialization you can define <CODE>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</CODE>
and then single-socket servers will not serialize at all.
-<h4>Lingering Close</h4>
+<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,
pipelined connections are faster</A>, so you
want to support them).
-<h4>Scoreboard File</h4>
+<H4>Scoreboard File</H4>
<P>Apache's parent and children communicate with each other through
something called the scoreboard. Ideally this should be implemented
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
(you probably don't if you're reading this and tuning your
This will save RAM that's allocated only for supporting dynamically
loaded modules.
-<h3>Appendix: Detailed Analysis of a Trace</h3>
+<H3>Appendix: Detailed Analysis of a Trace</H3>
Here is a system call trace of Apache 1.3 running on Linux. The run-time
configuration file is essentially the default plus:
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>
+<H3>Appendix: The Pre-Forking Model</H3>
<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>
and is used when the server must generate a URL that refers to itself
(for example when creating an external redirect to itself). This
behaviour is modified by
-<a href="#usecanonicalname">UseCanonicalName</a>.
+<A HREF="#usecanonicalname">UseCanonicalName</A>.
</UL>
In no event does a Port setting affect
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.
-(See also <
a href="#usecanonicalname">UseCanonicalName</a>.)<P>
+(See also <
A HREF="#usecanonicalname">UseCanonicalName</A>.)<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
<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>:<br>
-<A HREF="../dns-caveats.html">DNS Issues</A><br>
-<A HREF="#usecanonicalname">UseCanonicalName</A><br>
+<P><STRONG>See Also</STRONG>:<BR>
+<A HREF="../dns-caveats.html">DNS Issues</A><BR>
+<A HREF="#usecanonicalname">UseCanonicalName</A><BR>
</P>
<HR>
<A HREF="directive-dict.html#Compatibility" REL="Help">
<STRONG>Compatibility:</STRONG></A> UseCanonicalName is only available in Apache 1.3 and later<P>
-In many situations Apache has to construct a <i>self-referential</i>
+In many situations Apache has to construct a <EM>self-referential</EM>
URL. That is, a URL which refers back to the same server.
-With <code>UseCanonicalName on</code> (and in all versions prior to
-1.3) Apache will use the <a href="#servername">ServerName</a> and <a
-href="#port">Port</a> directives to construct a canonical name for the
+With <CODE>UseCanonicalName on</CODE> (and in all versions prior to
+1.3) Apache will use the <A HREF="#servername">ServerName</A> and <A
+HREF="#port">Port</A> directives to construct a canonical name for the
server. This name is used in all self-referential URLs, and for the
-values of <code>SERVER_NAME</code> and <code>SERVER_PORT</code> in CGIs.
+values of <CODE>SERVER_NAME</CODE> and <CODE>SERVER_PORT</CODE> in CGIs.
-<p>With <code>UseCanonicalName off</code> Apache will form
+<P>With <CODE>UseCanonicalName off</CODE> Apache will form
self-referential URLs using the hostname and port supplied
by the client if any are supplied (otherwise it will use the
canonical name). These values are the same that are used to
-implement <a href="../vhosts/name-based.html">name based virtual
-hosts</a>, and are available with the same clients. The CGI variables
-<code>SERVER_NAME</code> and <code>SERVER_PORT</code> will be constructed
+implement <A HREF="../vhosts/name-based.html">name based virtual
+hosts</A>, and are available with the same clients. The CGI variables
+<CODE>SERVER_NAME</CODE> and <CODE>SERVER_PORT</CODE> will be constructed
from the client supplied values as well.
-<p>An example where this may be useful is on an intranet server where
+<P>An example where this may be useful is on an intranet server where
you have users connecting to the machine using short names such as
-<code>www</code>. You'll notice that if the users type a shortname,
-and a URL which is a directory, such as <code>http://www/splat</code>,
-<i>without the trailing slash</i> then Apache will redirect them to
-<code>http://www.domain.com/splat/</code>. If you have authentication
+<CODE>www</CODE>. You'll notice that if the users type a shortname,
+and a URL which is a directory, such as <CODE>http://www/splat</CODE>,
+<EM>without the trailing slash</EM> then Apache will redirect them to
+<CODE>http://www.domain.com/splat/</CODE>. If you have authentication
enabled, this will cause the user to have to reauthenticate twice (once
-for <code>www</code> and once again for <code>www.domain.com</code>).
-But if <code>UseCanonicalName</code> is set off, then Apache will redirect
-to <code>http://www/splat/</code>.
+for <CODE>www</CODE> and once again for <CODE>www.domain.com</CODE>).
+But if <CODE>UseCanonicalName</CODE> is set off, then Apache will redirect
+to <CODE>http://www/splat/</CODE>.
-<p><b>Warning:</b> if CGIs make assumptions about the values of
-<code>SERVER_NAME</code> they may be broken by this option. The client
+<P><STRONG>Warning:</STRONG> if CGIs make assumptions about the values of
+<CODE>SERVER_NAME</CODE> they may be broken by this option. The client
is essentially free to give whatever value they want as a hostname.
-But if the CGI is only using <code>SERVER_NAME</code> to construct
+But if the CGI is only using <CODE>SERVER_NAME</CODE> to construct
self-referential URLs then it should be just fine.
-<p><strong>See also:</strong>
-<a href="#servername">ServerName</a>,
-<a href="#port">Port</a>
+<P><STRONG>See also:</STRONG>
+<A HREF="#servername">ServerName</A>,
+<A HREF="#port">Port</A>
-<p><hr>
+<P><HR>
<H2><A name="user">User directive</A></H2>
<!--%plaintext <?INDEX {\tt User} directive> -->
<HR>
-<h2><A name="allow">allow directive</A></h2>
+<H2><A name="allow">allow directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt allow} directive> -->
<A
</P>
<HR>
-<h2><A name="deny">deny directive</A></h2>
+<H2><A name="deny">deny directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt deny} directive> -->
<A
</P>
<HR>
-<h2><A name="order">order directive</A></h2>
+<H2><A name="order">order directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt order} directive> -->
<A
executing CGI scripts based on media type or request method. It is not
present in versions prior to Apache 1.1.
</P>
-<h2>Summary</h2>
+<H2>Summary</H2>
<P>
This module lets you run CGI scripts whenever a file of a certain type
is requested. This makes it much easier to execute scripts that
process files.
</P>
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#action">Action</A>
<LI><A HREF="#script">Script</A>
<HR>
-<h2><A name="action">Action directive</A></h2>
+<H2><A name="action">Action directive</A></H2>
<P>
<A
HREF="directive-dict.html#Syntax"
</P>
<HR>
-<h2><A name="script">Script directive</A></h2>
+<H2><A name="script">Script directive</A></H2>
<P>
<A
HREF="directive-dict.html#Syntax"
<HR>
-<h2><A name="alias">Alias directive</A></h2>
+<H2><A name="alias">Alias directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt Alias} directive> -->
<A
</P>
<HR>
-<h2><A name="aliasmatch">AliasMatch</A></h2>
+<H2><A name="aliasmatch">AliasMatch</A></H2>
<P>
<A
HREF="directive-dict.html#Syntax"
<HR>
-<h2><A name="redirect">Redirect directive</A></h2>
+<H2><A name="redirect">Redirect directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt Redirect} directive> -->
<A
</P>
<HR>
-<h2><A name="redirectmatch">RedirectMatch</A></h2>
+<H2><A name="redirectmatch">RedirectMatch</A></H2>
<P>
<A
HREF="directive-dict.html#Syntax"
<HR>
-<h2><A name="redirecttemp">RedirectTemp directive</A></h2>
+<H2><A name="redirecttemp">RedirectTemp directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt Redirect} directive> -->
<A
</P>
<HR>
-<h2><A name="redirectperm">RedirectPermanent directive</A></h2>
+<H2><A name="redirectperm">RedirectPermanent directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt Redirect} directive> -->
<A
</P>
<HR>
-<h2><A name="scriptalias">ScriptAlias directive</A></h2>
+<H2><A name="scriptalias">ScriptAlias directive</A></H2>
<P>
<!--%plaintext <?INDEX {\tt ScriptAlias} directive> -->
<A
<HR>
-<h2><A name="scriptaliasmatch">ScriptAliasMatch</A></h2>
+<H2><A name="scriptaliasmatch">ScriptAliasMatch</A></H2>
<P>
<A
HREF="directive-dict.html#Syntax"
this module.
<!--%plaintext <?INDEX {\tt httpd/send-as-is} mime type> -->
-<h2>Purpose</h2>
+<H2>Purpose</H2>
To allow file types to be defined such that Apache sends them without
adding HTTP headers.<P>
This can be used to send any kind of data from the server, including redirects
and other special HTTP responses, without requiring a cgi-script or an nph
script.
-<h2>Usage</h2>
+<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>
<HR>
-<A name="authgroupfile"><h2>AuthGroupFile</h2></A>
+<A name="authgroupfile"><H2>AuthGroupFile</H2></A>
<!--%plaintext <?INDEX {\tt AuthGroupFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="core.html#authtype">AuthType</A> and
<A HREF="#authuserfile">AuthUserFile</A>.<P><HR>
-<A name="authuserfile"><h2>AuthUserFile</h2></A>
+<A name="authuserfile"><H2>AuthUserFile</H2></A>
<!--%plaintext <?INDEX {\tt AuthUserFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="core.html#authtype">AuthType</A> and
<A HREF="#authgroupfile">AuthGroupFile</A>.<P>
<HR>
-<A name="authauthoritative"><h2>AuthAuthoritative</h2></A>
+<A name="authauthoritative"><H2>AuthAuthoritative</H2></A>
<!--%plaintext <?INDEX {\tt AuthAuthoritative} directive> -->
<A
HREF="directive-dict.html#Syntax"
is not compiled in by default. It is only available in Apache 1.1 and
later. It allows "anonymous" user access to authenticated areas.
-<h2>Summary</h2>
+<H2>Summary</H2>
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.
<A HREF="#Sourcecode">Sourcecode</A>
<P>
-<h2><A name="Directives">Directives</A></h2>
+<H2><A name="Directives">Directives</A></H2>
<UL>
<LI><A HREF="#anonymous">Anonymous</A>
<LI><A HREF="#Authoritative">Anonymous_Authoritative</A>
<HR>
-<h2><A name="anonymous">Anonymous directive</A></h2>
+<H2><A name="anonymous">Anonymous directive</A></H2>
<!--%plaintext <?INDEX {\tt Anonymous} directive> -->
<A
HREF="directive-dict.html#Syntax"
'I Don't Know'.
<HR>
-<h2><A name="Authoritative">Anonymous_Authoritative directive</A></h2>
+<H2><A name="Authoritative">Anonymous_Authoritative directive</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
in which the Authorization modules are queried.
<HR>
-<h2><A name="LogEmail">Anonymous_LogEmail directive</A></h2>
+<H2><A name="LogEmail">Anonymous_LogEmail directive</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
contains a sensible email address) is logged in the httpd-log file.
<HR>
-<h2><A name="MustGiveEmail">Anonymous_MustGiveEmail directive</A></h2>
+<H2><A name="MustGiveEmail">Anonymous_MustGiveEmail directive</A></H2>
<!--%plaintext <?INDEX {\tt Anonymous_MustGiveEmail} directive> -->
<A
HREF="directive-dict.html#Syntax"
address as the password. This prohibits blank passwords.
<HR>
-<h2><A name="NoUserID">Anonymous_NoUserID directive</A></h2>
+<H2><A name="NoUserID">Anonymous_NoUserID directive</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<h2><A name="VerifyEmail">Anonymous_VerifyEmail directive</A></h2>
+<H2><A name="VerifyEmail">Anonymous_VerifyEmail directive</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
valid email addresses (see the above <CODE>Auth_LogEmail</CODE>).
<HR>
-<h2><A name="Example">Example</A></h2>
+<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
<HR>
-<h2><A name="CompileTimeOptions">Compile Time Options</A></h2>
+<H2><A name="CompileTimeOptions">Compile Time Options</A></H2>
Currently there are no Compile options.
<HR>
-<h2><A name="RevisionHistory">Revision History</A></h2>
+<H2><A name="RevisionHistory">Revision History</A></H2>
This version: 23 Nov 1995, 24 Feb 1996, 16 May 1996.
<HR>
-<h2><A name="Person">Contact/person to blame</A></h2>
+<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
<HR>
-<h2><A NAME="Sourcecode">Sourcecode</A></h2>
+<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
<HR>
-<A name="authdbgroupfile"><h2>AuthDBGroupFile</h2></A>
+<A name="authdbgroupfile"><H2>AuthDBGroupFile</H2></A>
<!--%plaintext <?INDEX {\tt AuthDBGroupFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="core.html#authtype">AuthType</A> and
<A HREF="#authdbuserfile">AuthDBUserFile</A>.<P><HR>
-<A name="authdbuserfile"><h2>AuthDBUserFile</h2></A>
+<A name="authdbuserfile"><H2>AuthDBUserFile</H2></A>
<!--%plaintext <?INDEX {\tt AuthDBUserFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="core.html#authtype">AuthType</A> and
<A HREF="#authdbgroupfile">AuthDBGroupFile</A>.<P>
<HR>
-<A name="authdbauthoritative"><h2>AuthDBAuthoritative</h2></A>
+<A name="authdbauthoritative"><H2>AuthDBAuthoritative</H2></A>
<!--%plaintext <?INDEX {\tt AuthDBAuthoritative} directive> -->
<A
HREF="directive-dict.html#Syntax"
<HR>
-<A name="authdbmgroupfile"><h2>AuthDbmGroupFile</h2></A>
+<A name="authdbmgroupfile"><H2>AuthDbmGroupFile</H2></A>
<!--%plaintext <?INDEX {\tt AuthDbmGroupFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="core.html#authtype">AuthType</A> and
<A HREF="#authdbmuserfile">AuthDBMUserFile</A>.<P><HR>
-<A name="authdbmuserfile"><h2>AuthDBMUserFile</h2></A>
+<A name="authdbmuserfile"><H2>AuthDBMUserFile</H2></A>
<!--%plaintext <?INDEX {\tt AuthDBMUserFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="#authdbmgroupfile">AuthDBMGroupFile</A>.<P>
<HR>
-<A name="authdbmauthoritative"><h2>AuthDBMAuthoritative</h2></A>
+<A name="authdbmauthoritative"><H2>AuthDBMAuthoritative</H2></A>
<!--%plaintext <?INDEX {\tt AuthDBMAuthoritative} directive> -->
<A
HREF="directive-dict.html#Syntax"
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>
+<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>.
</P>
-<h2>Directives</h2>
+<H2>Directives</H2>
<MENU>
<LI><A HREF="#addalt">AddAlt</A>
</MENU>
<HR>
-<A name="addalt"><h2>AddAlt</h2></A>
+<A name="addalt"><H2>AddAlt</H2></A>
<!--%plaintext <?INDEX {\tt AddAlt} directive> -->
<A
HREF="directive-dict.html#Syntax"
image-incapable or has image loading disabled.
<HR>
-<A name="addaltbyencoding"><h2>AddAltByEncoding</h2></A>
+<A name="addaltbyencoding"><H2>AddAltByEncoding</H2></A>
<!--%plaintext <?INDEX {\tt AddAltByEncoding} directive> -->
<A
HREF="directive-dict.html#Syntax"
image-incapable or has image loading disabled.
<HR>
-<A name="addaltbytype"><h2>AddAltByType</h2></A>
+<A name="addaltbytype"><H2>AddAltByType</H2></A>
<!--%plaintext <?INDEX {\tt AddAltByType} directive> -->
<A
HREF="directive-dict.html#Syntax"
<HR>
-<A name="adddescription"><h2>AddDescription</h2></A>
+<A name="adddescription"><H2>AddDescription</H2></A>
<!--%plaintext <?INDEX {\tt AddDescription} directive> -->
<A
HREF="directive-dict.html#Syntax"
<BLOCKQUOTE><CODE>AddDescription "The planet Mars" /web/pics/mars.gif
</CODE></BLOCKQUOTE><P><HR>
-<A name="addicon"><h2>AddIcon</h2></A>
+<A name="addicon"><H2>AddIcon</H2></A>
<!--%plaintext <?INDEX {\tt AddIcon} directive> -->
<A
HREF="directive-dict.html#Syntax"
<A HREF="#addiconbytype">AddIconByType</A> should be used in preference to
AddIcon, when possible.<P><HR>
-<A name="addiconbyencoding"><h2>AddIconByEncoding</h2></A>
+<A name="addiconbyencoding"><H2>AddIconByEncoding</H2></A>
<!--%plaintext <?INDEX {\tt AddIconByEncoding} directive> -->
<A
HREF="directive-dict.html#Syntax"
AddIconByEncoding /icons/compress.xbm x-compress
</CODE></BLOCKQUOTE><P><HR>
-<A name="addiconbytype"><h2>AddIconByType</h2></A>
+<A name="addiconbytype"><H2>AddIconByType</H2></A>
<!--%plaintext <?INDEX {\tt AddIconByType} directive> -->
<A
HREF="directive-dict.html#Syntax"
AddIconByType (IMG,/icons/image.xbm) image/*
</CODE></BLOCKQUOTE><P><HR>
-<A name="defaulticon"><h2>DefaultIcon</h2></A>
+<A name="defaulticon"><H2>DefaultIcon</H2></A>
<!--%plaintext <?INDEX {\tt DefaultIcon} directive> -->
<A
HREF="directive-dict.html#Syntax"
DefaultIcon /icon/unknown.xbm
</CODE></BLOCKQUOTE><P><HR>
-<A name="fancyindexing"><h2>FancyIndexing</h2></A>
+<A name="fancyindexing"><H2>FancyIndexing</H2></A>
<!--%plaintext <?INDEX {\tt FancyIndexing} directive> -->
<A
HREF="directive-dict.html#Syntax"
</BLOCKQUOTE>
<HR>
-<A name="headername"><h2>HeaderName</h2></A>
+<A name="headername"><H2>HeaderName</H2></A>
<!--%plaintext <?INDEX {\tt HeaderName} directive> -->
<A
HREF="directive-dict.html#Syntax"
<P>See also <A HREF="#readmename">ReadmeName</A>.<P><HR>
-<A name="indexignore"><h2>IndexIgnore</h2></A>
+<A name="indexignore"><H2>IndexIgnore</H2></A>
<!--%plaintext <?INDEX {\tt IndexIgnore} directive> -->
<A
HREF="directive-dict.html#Syntax"
IndexIgnore README .htaccess *~
</CODE></BLOCKQUOTE><P><HR>
-<A name="indexoptions"><h2>IndexOptions</h2></A>
+<A name="indexoptions"><H2>IndexOptions</H2></A>
<!--%plaintext <?INDEX {\tt IndexOptions} directive> -->
<A
HREF="directive-dict.html#Syntax"
then only <CODE>ScanHTMLTitles</CODE> will be set for the /web/docs/spec
directory.<P><HR>
-<A name="readmename"><h2>ReadmeName</h2></A>
+<A name="readmename"><H2>ReadmeName</H2></A>
<!--%plaintext <?INDEX {\tt ReadmeName} directive> -->
<A
HREF="directive-dict.html#Syntax"
is not compiled in by default. It provides for CERN httpd metafile
semantics. It is only available in Apache 1.1 and later.
-<h2>Summary</h2>
+<H2>Summary</H2>
Emulate the CERN HTTPD Meta file semantics. Meta files are HTTP
headers that can be output in addition to the normal range of headers
<A HREF="http://www.w3.org/pub/WWW/Daemon/User/Config/General.html#MetaDir
">CERN metafile semantics</A> is available.
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#metafiles">MetaFiles</A>
<LI><A HREF="#metadir">MetaDir</A>
<HR>
-<h2><A name="metafiles">MetaFiles</A></h2>
+<H2><A name="metafiles">MetaFiles</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
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>
+<H2><A name="metadir">MetaDir</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
accessed. Set to "<CODE>.</CODE>" to look in the same directory as the
file.
-<h2><A name="metasuffix">MetaSuffix</A></h2>
+<H2><A name="metasuffix">MetaSuffix</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
>
<!--#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
is compiled in by default. It provides for execution of CGI scripts.
<!--%plaintext <?INDEX {\tt application/x-httpd-cgi} mime type> -->
<!--%plaintext <?INDEX CGI scripts> -->
-<h2>Summary</h2>
+<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)
will be treated as a CGI script, and run by the server, with its output
value of the <A HREF="core.html#documentroot">DocumentRoot</A>
configuration variable.
-<h2>CGI Environment variables</h2>
+<H2>CGI Environment variables</H2>
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:
<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
<HR>
-<h2>CGI Logfile Format</h2>
+<H2>CGI Logfile Format</H2>
When configured, the CGI error log logs any CGI which does not execute
properly. Each CGI script which fails to operate causes several lines
<HR>
-<h2>Directives</h2>
+<H2>Directives</H2>
-<h3><A name="scriptlog">ScriptLog</A></h3>
+<H3><A name="scriptlog">ScriptLog</A></H3>
<A
HREF="directive-dict.html#Syntax"
have security problems if used in a manner other than that for which
it was designed.</P>
-<h3><A name="scriptloglength">ScriptLogLength</A></h3>
+<H3><A name="scriptloglength">ScriptLogLength</A></H3>
<A
HREF="directive-dict.html#Syntax"
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>
<A
HREF="directive-dict.html#Syntax"
is compiled in by default. It provides for "trailing slash" redirects and
serving directory index files.
-<h2>Summary</h2>
+<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>.
slash, so <CODE>mod_dir</CODE> issues a redirect to
<SAMP>http://servername/foo/dirname/</SAMP>.
-<h2>Directives</h2>
+<H2>Directives</H2>
<MENU>
<LI><A HREF="#directoryindex">DirectoryIndex</A>
</MENU>
<HR>
-<A name="directoryindex"><h2>DirectoryIndex</h2></A>
+<A name="directoryindex"><H2>DirectoryIndex</H2></A>
<!--%plaintext <?INDEX {\tt DirectoryIndex} directive> -->
<A
HREF="directive-dict.html#Syntax"
passing environment variables to CGI/SSI scripts. Is is only available
in Apache 1.1 and later.
-<h2>Summary</h2>
+<H2>Summary</H2>
This module allows Apache's CGI and SSI environment to inherit
environment variables from the shell which invoked the httpd process.
useful to web-admins who wish to migrate from CERN to Apache without
rewriting all their scripts
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#passenv">PassEnv</A>
<LI><A HREF="#setenv">SetEnv</A>
<HR>
-<h2><A name="passenv">PassEnv</A></h2>
+<H2><A name="passenv">PassEnv</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<h2><A name="setenv">SetEnv</A></h2>
+<H2><A name="setenv">SetEnv</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<h2><A name="unsetenv">UnsetEnv</A></h2>
+<H2><A name="unsetenv">UnsetEnv</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
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
<HR>
-<h2>Directive</h2>
+<H2>Directive</H2>
<UL>
<LI><A HREF="#header">Header</A>
</UL>
<HR>
-<h2><A name="header">Header</A></h2>
+<H2><A name="header">Header</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
value contains spaces, it should be surrounded by double quotes.
For unset, no value should be given.
-<h3>Order of Processing</h3>
+<H3>Order of Processing</H3>
The Header directive can occur almost anywhere within the server
configuration. It is valid in the main server config and virtual host
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,
HREF="mod_mime.html#sethandler">SetHandler</A></CODE>) will be
processed by this module.
-<h2>Summary</h2>
+<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:
</UL>
<P>
-<h2>Configuration Directives</h2>
+<H2>Configuration Directives</H2>
<UL>
<LI><A HREF="#imapmenu">ImapMenu</A>
<LI><A HREF="#imapdefault">ImapDefault</A>
<P>
-<h3><A name="imapmenu">ImapMenu</A></h3>
+<H3><A name="imapmenu">ImapMenu</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<P>
-<h3><A name="imapdefault">ImapDefault</A></h3>
+<H3><A name="imapdefault">ImapDefault</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<P>
-<h3><A name="imapbase">ImapBase</A></h3>
+<H3><A name="imapbase">ImapBase</A></H3>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
<P>
-<h2>Imagemap File</h2>
+<H2>Imagemap File</H2>
The lines in the imagemap files can have one of several formats:
<BLOCKQUOTE>
<CODE>directive value [x,y ...]</CODE><BR>
used as the text of the link if a imagemap menu is generated. Lines
beginning with '#' are comments.
-<h3>Imagemap File Directives</h3>
+<H3>Imagemap File Directives</H3>
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.
-<h3>Values</h3>
+<H3>Values</H3>
The values for each of the directives can any of the following:
<DL>
<DT>a URL
<CODE>default</CODE>.
</DL>
-<h3>Coordinates</h3>
+<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
no coordinate had been selected.
</DL>
-<h3>Quoted Text</h3>
+<H3>Quoted Text</H3>
<DL>
<DT><CODE>"Menu Text"</CODE>
<DD>After the value or after the coordinates, the line optionally may
<HR>
-<h2>Example Mapfile</h2>
+<H2>Example Mapfile</H2>
<BLOCKQUOTE><CODE>
#Comments are printed in a 'formatted' or 'semiformatted' menu. <BR>
#And can contain html tags. <hr> <BR>
</CODE></BLOCKQUOTE>
<P>
-<h2>Referencing your mapfile</h2>
+<H2>Referencing your mapfile</H2>
<BLOCKQUOTE><CODE>
<A HREF="/maps/imagemap1.map"> <BR>
<IMG ISMAP SRC="/images/imagemap1.gif"> <BR>
<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>
+<H2>Basic Elements</H2>
The document is parsed as an HTML document, with special commands embedded
as SGML comments. A command has the syntax:
</DL>
-<h2>Include Variables</h2>
+<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
</PRE>
<HR>
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#xbithack">XBitHack</A>
</UL>
<HR>
-<h2><A name="xbithack">XBitHack</A></h2>
+<H2><A name="xbithack">XBitHack</A></H2>
<!--%plaintext <?INDEX {\tt XBitHack} directive> -->
<A
HREF="directive-dict.html#Syntax"
<P>
<HR>
-<h2>Using Server Side Includes for ErrorDocuments</h2>
+<H2>Using Server Side Includes for ErrorDocuments</H2>
There is <A HREF="../misc/custom_errordocs.html">a document</A> which
describes how to use the features of mod_include to offer internationalized
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
provides a comprehensive overview of the server configuration
running under Microsoft Windows. Any document with a handler of
<CODE>isapi-isa</CODE> will be processed by this module.
-<h2>Purpose</h2>
+<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
Extensions) to be used with Apache for Windows.
-<h2>Usage</h2>
+<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>
scripts. That is, <CODE>Options ExecCGI</CODE> must be active in the
directory that contains the ISA.</P>
-<h2>Notes</h2>
+<H2>Notes</H2>
<P>Apache's ISAPI implementation conforms to all of the ISAPI 2.0
specification, except for the "Microsoft-specific" extensions dealing
<HR>
-<h2><A name="agentlog">AgentLog</A></h2>
+<H2><A name="agentlog">AgentLog</A></H2>
<!--%plaintext <?INDEX {\tt AgentLog} directive> -->
<A
HREF="directive-dict.html#Syntax"
an optional module. It provides for logging of the requests made to
the server, using the Common Log Format or a user-specified format.
-<h2>Summary</h2>
+<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,
logged to multiple files.
<P>
-<h3>Compatibility notes</h3>
+<H3>Compatibility notes</H3>
<UL>
<LI>This module is based on mod_log_config distributed with
</UL>
-<h2>Log File Formats</h2>
+<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"
log files are used, each can have a different format). Custom formats
are set with <CODE>LogFormat</CODE> and <CODE>CustomLog</CODE>.
-<h3>Common Log Format</h3>
+<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:
any headers.
</DL>
-<h3><A NAME="formats">Custom Log Formats</A></h3>
+<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
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>.
-<h2>Using Multiple Log Files</h2>
+<H2>Using Multiple Log Files</H2>
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.
-<h3>Use with Virtual Hosts</h3>
+<H3>Use with Virtual Hosts</H3>
If a <VirtualHost> section does not contain any
<TT>TransferLog</TT> or <TT>CustomLog</TT> directives, the
See the examples below.
<P>
-<h2>Security Considerations</h2>
+<H2>Security Considerations</H2>
See the <A HREF="../misc/security_tips.html#security">security tips</A>
document for details on why your security could be compromised if the
directory where logfiles are stored is writable by anyone other than
the user that starts the server.
<P>
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#cookielog">CookieLog</A>
<HR>
-<h2><A name="cookielog">CookieLog</A></h2>
+<H2><A name="cookielog">CookieLog</A></H2>
<!--%plaintext <?INDEX {\tt CookieLog} directive> -->
<A
HREF="directive-dict.html#Syntax"
directive.
</P>
<HR>
-<h2><A name="logformat">LogFormat</A></h2>
+<H2><A name="logformat">LogFormat</A></H2>
<!--%plaintext <?INDEX {\tt LogFormat} directive> -->
<A
HREF="directive-dict.html#Syntax"
</P>
<HR>
-<h2><A name="transferlog">TransferLog</A></h2>
+<H2><A name="transferlog">TransferLog</A></H2>
<!--%plaintext <?INDEX {\tt TransferLog} directive> -->
<A
HREF="directive-dict.html#Syntax"
compiled in by default. It provides for logging of the documents which
reference documents on the server.
-<h2>Log file format</h2>
+<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>
local URL to the document being referred to.
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#refererignore">RefererIgnore</A>
<LI><A HREF="#refererlog">RefererLog</A>
<HR>
-<h2><A name="refererignore">RefererIgnore</A></h2>
+<H2><A name="refererignore">RefererIgnore</A></H2>
<!--%plaintext <?INDEX {\tt RefererIgnore} directive> -->
<A
HREF="directive-dict.html#Syntax"
<P><HR>
-<h2><A name="refererlog">RefererLog</A></h2>
+<H2><A name="refererlog">RefererLog</A></H2>
<!--%plaintext <?INDEX {\tt RefererLog} directive> -->
<A
HREF="directive-dict.html#Syntax"
compiled in by default. It provides for determining the types of files
from the filename.
-<h2>Summary</h2>
+<H2>Summary</H2>
This module is used to determine various bits of "meta information"
about documents. This information relates to the content of the
<P>
-<h2> Directives</h2>
+<H2> Directives</H2>
<UL>
<LI><A HREF="#addencoding">AddEncoding</A>
<LI><A HREF="#addhandler">AddHandler</A>
<HR>
-<h2><A name="addencoding">AddEncoding</A></h2>
+<H2><A name="addencoding">AddEncoding</A></H2>
<!--%plaintext <?INDEX {\tt AddEncoding} directive> -->
<A
HREF="directive-dict.html#Syntax"
This will cause files ending in .gz to be marked as encoded using the x-gzip
encoding, and .Z files to be marked as encoded with x-compress.<P><HR>
-<h2><A name="addhandler">AddHandler</A></h2>
+<H2><A name="addhandler">AddHandler</A></H2>
<A
HREF="directive-dict.html#Syntax"
program.</P>
<HR>
-<h2><A name="addlanguage">AddLanguage</A></h2>
+<H2><A name="addlanguage">AddLanguage</A></H2>
<!--%plaintext <?INDEX {\tt AddLanguage} directive> -->
<A
HREF="directive-dict.html#Syntax"
is more useful for content negotiation, where the server returns one
from several documents based on the client's language preference.<P><HR>
-<h2><A name="addtype">AddType</A></h2>
+<H2><A name="addtype">AddType</A></H2>
<!--%plaintext <?INDEX {\tt AddType} directive> -->
<A
HREF="directive-dict.html#Syntax"
Note that, unlike the NCSA httpd, this directive cannot be used to set the
type of particular files.<P><HR>
-<h2><A name="forcetype">ForceType</A></h2>
+<H2><A name="forcetype">ForceType</A></H2>
<A
HREF="directive-dict.html#Syntax"
<P>Note that this will override any filename extensions that might
media type.</P>
-<h2><A name="sethandler">SetHandler</A></h2>
+<H2><A name="sethandler">SetHandler</A></H2>
<A
HREF="directive-dict.html#Syntax"
</PRE>
<HR>
-<h2><A name="typesconfig">TypesConfig</A></h2>
+<H2><A name="typesconfig">TypesConfig</A></H2>
<!--%plaintext <?INDEX {\tt TypesConfig} directive> -->
<A
HREF="directive-dict.html#Syntax"
<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.
mod_mime_magic is intended as a "second line of defense" for cases
mod_mime cannot resolve.
- <h2>Summary</h2>
+ <H2>Summary</H2>
This module is derived from a free version of the <CODE>file(1)</CODE>
command for Unix,
0 string \037\213 application/octet-stream x-gzip
</PRE>
- <h3>Performance Issues</h3>
+ <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,
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>
+ <H2>Directives</H2>
<P>
<UL>
<LI><A HREF="#mimemagicfile">MimeMagicFile</A>
<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
and is compiled in by default. It provides for <A
HREF="../content-negotiation.html">content negotiation</A>.
-<h2>Summary</h2>
+<H2>Summary</H2>
Content negotiation, or more accurately content selection, is the
selection of the document that best matches the clients
capabilities, from one of several available documents.
filename pattern match, and choose from amongst the results.
</UL>
-<h3>Type maps</h3>
+<H3>Type maps</H3>
A type map has the same format as RFC822 mail headers. It contains document
descriptions separated by blank lines, with lines beginning with a hash
character ('#') treated as comments. A document description consists of
<DD>The path to the file containing this variant, relative to the map file.
</DL>
-<h3>MultiViews</h3>
+<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
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#cachenegotiateddocs">CacheNegotiatedDocs</A>
<LI><A HREF="#languagepriority">LanguagePriority</A>
<HR>
-<h2><A name="cachenegotiateddocs">CacheNegotiatedDocs</A></h2>
+<H2><A name="cachenegotiateddocs">CacheNegotiatedDocs</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
-<h2><A name="languagepriority">LanguagePriority</A></h2>
+<H2><A name="languagepriority">LanguagePriority</A></H2>
<!--%plaintext <?INDEX {\tt LanguagePriority} directive> -->
<A
HREF="directive-dict.html#Syntax"
questions are addressed <A HREF="#configs">after the directive
descriptions</A>.
-<h3>Note:</h3>
+<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>
-<h2>Summary</h2>
+<H2>Summary</H2>
This module implements a proxy/cache for Apache. It implements
proxying capability for
The module can be configured to connect to other proxy modules for these
and other protocols.
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#proxyrequests">ProxyRequests</A>
<LI><A HREF="#proxyremote">ProxyRemote</A>
<HR>
-<A name="proxyrequests"><h2>ProxyRequests</h2></A>
+<A name="proxyrequests"><H2>ProxyRequests</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="proxyremote"><h2>ProxyRemote</h2></A>
+<A name="proxyremote"><H2>ProxyRemote</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="proxypass"><h2>ProxyPass</h2></A>
+<A name="proxypass"><H2>ProxyPass</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="proxyblock"><h2>ProxyBlock</h2></A>
+<A name="proxyblock"><H2>ProxyBlock</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="noproxy"><h2>NoProxy</h2></A>
+<A name="noproxy"><H2>NoProxy</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="proxydomain"><h2>ProxyDomain</h2></A>
+<A name="proxydomain"><H2>ProxyDomain</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cacheroot"><h2>CacheRoot</h2></A>
+<A name="cacheroot"><H2>CacheRoot</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachesize"><h2>CacheSize</h2></A>
+<A name="cachesize"><H2>CacheSize</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachegcinterval"><h2>CacheGcInterval</h2></A>
+<A name="cachegcinterval"><H2>CacheGcInterval</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachemaxexpire"><h2>CacheMaxExpire</h2></A>
+<A name="cachemaxexpire"><H2>CacheMaxExpire</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachelastmodifiedfactor"><h2>CacheLastModifiedFactor</h2></A>
+<A name="cachelastmodifiedfactor"><H2>CacheLastModifiedFactor</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachedirlevels"><h2>CacheDirLevels</h2></A>
+<A name="cachedirlevels"><H2>CacheDirLevels</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachedirlength"><h2>CacheDirLength</h2></A>
+<A name="cachedirlength"><H2>CacheDirLength</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="cachedefaultexpire"><h2>CacheDefaultExpire</h2></A>
+<A name="cachedefaultexpire"><H2>CacheDefaultExpire</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<HR>
-<A name="nocache"><h2>NoCache</h2></A>
+<A name="nocache"><H2>NoCache</H2></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<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="#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>
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>
-<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>
-<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
application/octet-stream bin dms lha lzh exe class tgz taz
</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>
-<
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>
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>
-<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
<EM>Configuration</EM> file, and follow the instructions there. SOCKS5
permitting connections on the appropriate ports in your SOCKS daemon's
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
requests through the company's firewall. However, when it has to access
>
<!--#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
1.2 and later. It provides a rule-based rewriting engine to rewrite requested
AddModule modules/standard/mod_rewrite.o
</PRE>
-<h2>Summary</h2>
+<H2>Summary</H2>
This module uses a rule-based rewriting engine (based on a
regular-expression parser) to rewrite requested URLs on the fly.
<!--/%hypertext -->
<P>
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#RewriteEngine">RewriteEngine</A>
</A>
</CENTER>
-<A name="RewriteEngine"><h3>RewriteEngine</h3></A>
+<A name="RewriteEngine"><H3>RewriteEngine</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteOptions"><h3>RewriteOptions</h3></A>
+<A name="RewriteOptions"><H3>RewriteOptions</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteLog"><h3>RewriteLog</h3></A>
+<A name="RewriteLog"><H3>RewriteLog</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteLogLevel"><h3>RewriteLogLevel</h3></A>
+<A name="RewriteLogLevel"><H3>RewriteLogLevel</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteMap"><h3>RewriteMap</h3></A>
+<A name="RewriteMap"><H3>RewriteMap</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteBase"><h3>RewriteBase</h3></A>
+<A name="RewriteBase"><H3>RewriteBase</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteCond"><h3>RewriteCond</h3></A>
+<A name="RewriteCond"><H3>RewriteCond</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<hr noshade size=1>
<P>
-<A name="RewriteRule"><h3>RewriteRule</h3></A>
+<A name="RewriteRule"><H3>RewriteRule</H3></A>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
</CENTER>
<A name="EnvVar">
-<h2>Environment Variables</h2>
+<H2>Environment Variables</H2>
</A>
This module keeps track of two additional (non-standard) CGI/SSI environment
systems use <A HREF="mod_dll.html">mod_dll</A> instead. This module is
only available in Apache 1.3 and up.
-<h2>Summary</h2>
+<H2>Summary</H2>
This is an experimental module. On selected operating systems it can
be used to load modules into Apache at runtime, rather than requiring
a recompilation.
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#loadfile">LoadFile</A>
<LI><A HREF="#loadmodule">LoadModule</A>
<HR>
-<h2><A name="loadfile">LoadFile</A></h2>
+<H2><A name="loadfile">LoadFile</A></H2>
<!--%plaintext <?INDEX {\tt LoadFile} directive> -->
<A
HREF="directive-dict.html#Syntax"
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>
+<H2><A name="loadmodule">LoadModule</A></H2>
<!--%plaintext <?INDEX {\tt LoadModule} directive> -->
<A
HREF="directive-dict.html#Syntax"
one document with a sufficiently similar name is found.
</P>
- <h2>Summary</h2>
+ <H2>Summary</H2>
<P>
Requests to documents sometimes cannot be served by the core apache
server because the request was misspelled or miscapitalized. This
</UL>
</P>
- <h2>Directives</h2>
+ <H2>Directives</H2>
<MENU>
<LI><A HREF="#checkspelling">CheckSpelling</A>
</MENU>
<HR> <!-- the HR is part of the directive description -->
- <A name="checkspelling"><h2>CheckSpelling</h2></A>
+ <A name="checkspelling"><H2>CheckSpelling</H2></A>
<!--%plaintext <?INDEX {\tt CheckSpelling} directive> -->
<A
HREF="directive-dict.html#Syntax"
>
<!--#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>
-<h2>Function</h2>
+<H2>Function</H2>
The Status module allows a server administrator to find out how well
their server is performing. A HTML page is presented that gives
the instrumentation required for obtaining these statistics does not
exist within standard Apache.
-<h2>Enabling Status Support</h2>
+<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
<A HREF="core.html#servertype">standalone</A> mode and not
<A HREF="core.html#servertype">inetd</A> mode.
-<h3>Automatic Updates</h3>
+<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
every N seconds.
-<h3>Machine Readable Status File</h3>
+<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>.
-<h2>Full Instrumentation</h2>
+<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
Unique identifiers are useful for various reasons which are beyond the
scope of this document.
-<h2>Theory</h2>
+<H2>Theory</H2>
<P>
First a brief recap of how the Apache server works on Unix machines.
<HR>
-<h2>Directives</h2>
+<H2>Directives</H2>
<CODE>mod_unique_id</CODE> has no directives.
<HR>
-<h2><A name="userdir">UserDir</A></h2>
+<H2><A name="userdir">UserDir</A></H2>
<!--%plaintext <?INDEX {\tt UserDir} directive> -->
<A
HREF="directive-dict.html#Syntax"
<HR>
-<h2>Logging</h2>
+<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,
old <TT>CookieLog</TT> directive, but this should be upgraded to the
above <TT>CustomLog</TT> directive.
-<h2>Directives</h2>
+<H2>Directives</H2>
<UL>
<LI><A HREF="#cookieexpires">CookieExpires</A>
<HR>
-<h2><A name="cookieexpires">CookieExpires</A></h2>
+<H2><A name="cookieexpires">CookieExpires</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
<P>If this directive is not used, cookies last only for the current
browser session.</P>
-<h2><A name="cookietracking">CookieTracking</A></h2>
+<H2><A name="cookietracking">CookieTracking</A></H2>
<A
HREF="directive-dict.html#Syntax"
REL="Help"
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
-<h1 ALIGN="CENTER">Hints on Running a High-Performance Web Server</H1>
+<H1 ALIGN="CENTER">Hints on Running a High-Performance Web Server</H1>
Running Apache on a heavily loaded web server, one often encounters
problems related to the machine and OS configuration. "Heavy" is
<HR>
-<h2><A name="req">Requirements</A></h2>
+<H2><A name="req">Requirements</A></H2>
<P>Apache 1.3b3 requires the following:</P>
<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
installed. It is easiest to compile with the command-line tools
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>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>
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
Apache decides which directives apply for a particular directory or
request URL.
-<h2>Directives allowed in the sections</h2>
+<H2>Directives allowed in the sections</H2>
Everything that is syntactically allowed in
<CODE><Directory></CODE> is also allowed in
<CODE><Files></CODE> -- syntactically everything is fine, but
semantically some things are different.
-<h2>How the sections are merged</h2>
+<H2>How the sections are merged</H2>
The order of merging is:
onwards. Before those releases sections inside virtual hosts were
applied <EM>before</EM> the main server).
-<h2>Notes about using sections</h2>
+<H2>Notes about using sections</H2>
The general guidelines are:
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
Apache decides which directives apply for a particular directory or
request URL.
-<h2>Directives allowed in the sections</h2>
+<H2>Directives allowed in the sections</H2>
Everything that is syntactically allowed in
<CODE><Directory></CODE> is also allowed in
<CODE><Files></CODE> -- syntactically everything is fine, but
semantically some things are different.
-<h2>How the sections are merged</h2>
+<H2>How the sections are merged</H2>
The order of merging is:
onwards. Before those releases sections inside virtual hosts were
applied <EM>before</EM> the main server).
-<h2>Notes about using sections</h2>
+<H2>Notes about using sections</H2>
The general guidelines are:
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,
but you should not send signals to any of them except the parent, whose
<A HREF="mod/core.html#serverroot">ServerRoot</A> and
<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-<h3>TERM Signal: stop now</h3>
+<H3>TERM Signal: stop now</H3>
<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
parent itself exits. Any requests in progress are terminated, and no
further requests are served.
-<h3>HUP Signal: restart now</h3>
+<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
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>
+<H3>USR1 Signal: graceful restart</H3>
<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and
shouldn't be used at all.
bound). If it fails for any other reason then it's probably a config file
error and the error should be fixed before issuing the graceful restart.
-<h3>Appendix: signals and race conditions</h3>
+<H3>Appendix: signals and race conditions</H3>
<P>Prior to Apache 1.2b9 there were several <EM>race conditions</EM>
involving the restart and die signals (a simple description of race
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,
but you should not send signals to any of them except the parent, whose
<A HREF="mod/core.html#serverroot">ServerRoot</A> and
<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-<h3>TERM Signal: stop now</h3>
+<H3>TERM Signal: stop now</H3>
<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
parent itself exits. Any requests in progress are terminated, and no
further requests are served.
-<h3>HUP Signal: restart now</h3>
+<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
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>
+<H3>USR1 Signal: graceful restart</H3>
<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and
shouldn't be used at all.
bound). If it fails for any other reason then it's probably a config file
error and the error should be fixed before issuing the graceful restart.
-<h3>Appendix: signals and race conditions</h3>
+<H3>Appendix: signals and race conditions</H3>
<P>Prior to Apache 1.2b9 there were several <EM>race conditions</EM>
involving the restart and die signals (a simple description of race
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 <STRONG>Apache 1.3</STRONG>.
This document attempts to explain exactly what Apache does when
<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>
+<H3>Config File Parsing</H3>
<P>There is a <EM>main_server</EM> which consists of all
the definitions appearing outside of <CODE><VirtualHost></CODE> sections.
is given the same <CODE>ServerName</CODE> as the main_server.
-<h3>Virtual Host Matching</h3>
+<H3>Virtual Host Matching</H3>
<P>The server determines which vhost to use for a request as follows:
-<h4>Hash table lookup</h4>
+<H4>Hash table lookup</H4>
<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.
found) the next step is to decide if we have to deal with an IP-based
or a name-base vhost.
-<h4>IP-based vhost</h4>
+<H4>IP-based vhost</H4>
<P>If the entry we found has an empty name list then we have found an
IP-based vhost, no further actions are performed and the request is
served from that vhost.
-<h4>Name-based vhost</h4>
+<H4>Name-based vhost</H4>
<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
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>
+<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
during a KeepAlive/persistent connection. In other words a client may
persistent connection.
-<h4>Absolute URI</h4>
+<H4>Absolute URI</H4>
<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
taken to be a proxy request.
-<h3>Observations</h3>
+<H3>Observations</H3>
<UL>
</UL>
-<h3>Tips</h3>
+<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:
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
it was written. It attempts to explain exactly what the code does when
<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>
+<H3>Config File Parsing</H3>
<P>There is a main_server which consists of all the definitions appearing
outside of <CODE>VirtualHost</CODE> sections. There are virtual servers,
<P>
-<h3>Vhost Matching</h3>
+<H3>Vhost Matching</H3>
<P><STRONG>Apache 1.3 differs from what is documented
<STRONG>last match</STRONG> is used regardless (again consider the ordering of
the virtual hosts).
-<h3>Observations</h3>
+<H3>Observations</H3>
<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:
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>
+<H2>Base configuration</H2>
<UL>
<LI><A HREF="#ip">IP-based vhosts only</A>
<LI><A HREF="#port">Port-based vhosts</A>
</UL>
-<h2>Additional features</h2>
+<H2>Additional features</H2>
<UL>
<LI><A HREF="#default">Using <CODE>_default_</CODE> vhosts</A>
<HR>
-<h3><A NAME="ip">IP-based vhosts only</A></h3>
+<H3><A NAME="ip">IP-based vhosts only</A></H3>
<UL>
</UL>
<HR>
-<h3><A NAME="name">Name-based vhosts only</A></h3>
+<H3><A NAME="name">Name-based vhosts only</A></H3>
<UL>
<HR>
-<h3><A NAME="mixed">Mixed name-/IP-based vhosts</A></h3>
+<H3><A NAME="mixed">Mixed name-/IP-based vhosts</A></H3>
-<Ul>
+<UL>
<LI><STRONG>Setup:</STRONG>
The server machine has three IP addresses (<SAMP>111.22.33.44</SAMP>,
<HR>
-<h3><A NAME="port">Port-based vhosts</A></h3>
+<H3><A NAME="port">Port-based vhosts</A></H3>
<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>
<HR>
-<h3><A NAME="migrate">Migrating a name-based vhost to an IP-based vhost</A></h3>
+<H3><A NAME="migrate">Migrating a name-based vhost to an IP-based vhost</A></H3>
<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>
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
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
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>
<HR>
-<h2>What is a Virtual Host</h2>
+<H2>What is a Virtual Host</H2>
<P>The "Virtual Host" refers to the practice of maintaining more than
one server on one machine, as differentiated by their apparent
later) do, but many browsers, especially older ones, do not. This can
cause problems, although a possible solution is addressed below.</P>
-<h2>Using non-IP Virtual Hosts</h2>
+<H2>Using non-IP Virtual Hosts</H2>
<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
server to know what domain the client uses for their name resolution
because the client doesn't provide that information in the request.</P>
-<h2>Security Considerations</h2>
+<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
HREF="mod/mod_access.html">allow, deny from,</A> etc.) are consistently
respected.
-<h2>Compatibility with Older Browsers</h2>
+<H2>Compatibility with Older Browsers</H2>
<P>As mentioned earlier, a majority of browsers do not send the
required data for the new virtual hosts to work properly. These
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>
<HR>
-<h2>System requirements</h2>
+<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>.
This can be achieved by the machine having several physical network connections,
frequently called "ip aliases", and the "ifconfig" command
is most commonly used to set them up).
-<h2>How to set up Apache</h2>
+<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.
loss in running separate daemons may be significant.
</UL>
-<h2>Setting up multiple daemons</h2>
+<H2>Setting up multiple daemons</H2>
Create a separate httpd installation for each virtual host.
For each installation, use the
<A HREF="../mod/core.html#listen">Listen</A> directive in the configuration
It is recommended that you use an IP address instead of a hostname
(see <A HREF="../dns-caveats.html">DNS caveats</A>).
-<h2>Setting up a single daemon with virtual hosts</h2>
+<H2>Setting up a single daemon with virtual hosts</H2>
For this case, a single httpd will service requests for the main server
and all the virtual hosts.
The <A HREF="../mod/core.html#virtualhost">VirtualHost</A> directive in the
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>
<HR>
-<h2>Name-based vs. IP-based virtual hosts</h2>
+<H2>Name-based vs. IP-based virtual hosts</H2>
<P>While the approach with IP-based virtual hosts works very well,
it is not the most elegant solution, because a dedicated IP address
old browsers in use who do not. This can cause problems, although a possible
solution is addressed below.</P>
-<h2>Using non-IP Virtual Hosts</h2>
+<H2>Using non-IP Virtual Hosts</H2>
<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
server to know what domain the client uses for their name resolution
because the client doesn't provide that information in the request.</P>
-<h2>Compatibility with Older Browsers</h2>
+<H2>Compatibility with Older Browsers</H2>
<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
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>
<HR>
-<h2>Name-based vs. IP-based virtual hosts</h2>
+<H2>Name-based vs. IP-based virtual hosts</H2>
<P>While the approach with IP-based virtual hosts works very well,
it is not the most elegant solution, because a dedicated IP address
old browsers in use who do not. This can cause problems, although a possible
solution is addressed below.</P>
-<h2>Using non-IP Virtual Hosts</h2>
+<H2>Using non-IP Virtual Hosts</H2>
<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
server to know what domain the client uses for their name resolution
because the client doesn't provide that information in the request.</P>
-<h2>Compatibility with Older Browsers</h2>
+<H2>Compatibility with Older Browsers</H2>
<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
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
it was written. It attempts to explain exactly what the code does when
<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>
+<H3>Config File Parsing</H3>
<P>There is a main_server which consists of all the definitions appearing
outside of <CODE>VirtualHost</CODE> sections. There are virtual servers,
<P>
-<h3>Vhost Matching</h3>
+<H3>Vhost Matching</H3>
<P><STRONG>Apache 1.3 differs from what is documented
<STRONG>last match</STRONG> is used regardless (again consider the ordering of
the virtual hosts).
-<h3>Observations</h3>
+<H3>Observations</H3>
<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:
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>
-<h2>What are virtual hosts?</h2>
+<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
http://www.baygroup.org/
</BLOCKQUOTE>
-<h2>System requirements</h2>
+<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
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.
-<h2>How to set up Apache</h2>
+<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.
loss in running separate daemons may be significant.
</UL>
-<h2>Setting up multiple daemons</h2>
+<H2>Setting up multiple daemons</H2>
Create a separate httpd installation for each virtual host.
For each installation, use the
<A HREF="mod/core.html#bindaddress">BindAddress</A> directive in the configuration
<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>
+<H2>Setting up a single daemon</H2>
For this case, a single httpd will service requests for all the virtual hosts.
The <A HREF="mod/core.html#virtualhost">VirtualHost</A> directive in the
configuration file is used to set the values of
projects / thirdparty / apache / httpd.git / commitdiff
