and ports Apache listens to.
<UL>
-<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to listening to
+<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to
+ listening to
a single address, and can be used to permit multiple Apache servers
on the same machine listening to different IP addresses.
-<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server listen
+<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server
+ listen
to more than one address and/or port.
</UL>
-<H3><A name="bindaddress">BindAddress</A></H3>
+<H3><A NAME="bindaddress">BindAddress</A></H3>
<A
HREF="mod/directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address | hostname ]</EM><BR>
+><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address
+ | hostname ]</EM><BR>
<A
HREF="mod/directive-dict.html#Default"
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="mod/directive-dict.html#Syntax"
REL="Help"
and ports Apache listens to.
<UL>
-<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to listening to
+<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to
+ listening to
a single address, and can be used to permit multiple Apache servers
on the same machine listening to different IP addresses.
-<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server listen
+<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server
+ listen
to more than one address and/or port.
</UL>
-<H3><A name="bindaddress">BindAddress</A></H3>
+<H3><A NAME="bindaddress">BindAddress</A></H3>
<A
HREF="mod/directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address | hostname ]</EM><BR>
+><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address
+ | hostname ]</EM><BR>
<A
HREF="mod/directive-dict.html#Default"
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="mod/directive-dict.html#Syntax"
REL="Help"
<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
<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
<LI>Select the variants with the highest language quality factor
<LI>Select the variants with the best language match, using either the
- order of languages on the <CODE>LanguagePriority</CODE> directive (if present),
+ order of languages on the <CODE>LanguagePriority</CODE> directive (if
+ present),
else the order of languages on the Accept-Language header.
<LI>Select the variants with the highest 'level' media parameter
</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
</UL>
<P>
-Here some more examples of filenames together with valid and invalid hyperlinks:
+Here some more examples of filenames together with valid and invalid
+hyperlinks:
</P>
-<table border=1 cellpadding=8 cellspacing=0>
+<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0>
<TR>
<TH>Filename</TH>
<TH>Valid hyperlink</TH>
<LI>Select the variants with the highest language quality factor
<LI>Select the variants with the best language match, using either the
- order of languages on the <CODE>LanguagePriority</CODE> directive (if present),
+ order of languages on the <CODE>LanguagePriority</CODE> directive (if
+ present),
else the order of languages on the Accept-Language header.
<LI>Select the variants with the highest 'level' media parameter
</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
</UL>
<P>
-Here some more examples of filenames together with valid and invalid hyperlinks:
+Here some more examples of filenames together with valid and invalid
+hyperlinks:
</P>
-<table border=1 cellpadding=8 cellspacing=0>
+<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0>
<TR>
<TH>Filename</TH>
<TH>Valid hyperlink</TH>
</OL>
<P>Redirecting to another URL can be useful, but only if some information
- can be passed which can then be used to explain and/or log the error/problem
+ can be passed which can then be used to explain and/or log the
+ error/problem
more clearly.
<P>To achieve this, Apache will define new CGI-like environment
<P>note the <CODE>REDIRECT_</CODE> prefix.
- <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE> will
- be passed to the new URL (assuming it's a cgi-script or a cgi-include). The
- other variables will exist only if they existed prior to the error/problem.
+ <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE>
+ will
+ be passed to the new URL (assuming it's a cgi-script or a cgi-include).
+ The
+ other variables will exist only if they existed prior to the
+ error/problem.
<STRONG>None</STRONG> of these will be set if your ErrorDocument is an
- <EM>external</EM> redirect (i.e. anything starting with a protocol name
+ <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a
+ scheme name
like <CODE>http:</CODE>, even if it refers to the same host as the
server).<P>
<DT>Configuration
<DD> Use of "ErrorDocument" is enabled for .htaccess files when the
- <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is allowed.
+ <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is
+ allowed.
<P>Here are some examples...
<DT>Old behavior
<DD>Standard CGI vars were made available to a script which has been
- redirected to. No indication of where the redirection came from was provided.
+ redirected to. No indication of where the redirection came from was
+ provided.
<P>
the access log.
</DL>
+<P>
+If the ErrorDocument specifies a local redirect to a CGI script, the script
+should include a "<SAMP>Status:</SAMP>" header field in its output
+in order to ensure the propagation all the way back to the client
+of the error condition that caused it to be invoked. For instance, a Perl
+ErrorDocument script might include the following:
+</P>
+<PRE>
+ :
+ print "Content-type: text/html\n";
+ printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
+ :
+</PRE>
+<P>
+If the script is dedicated to handling a particular error condition, such as
+<SAMP>404 Not Found</SAMP>, it can use the specific code and
+error text instead.
+</P>
<!--#include virtual="footer.html" -->
</BODY>
</OL>
<P>Redirecting to another URL can be useful, but only if some information
- can be passed which can then be used to explain and/or log the error/problem
+ can be passed which can then be used to explain and/or log the
+ error/problem
more clearly.
<P>To achieve this, Apache will define new CGI-like environment
<P>note the <CODE>REDIRECT_</CODE> prefix.
- <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE> will
- be passed to the new URL (assuming it's a cgi-script or a cgi-include). The
- other variables will exist only if they existed prior to the error/problem.
+ <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE>
+ will
+ be passed to the new URL (assuming it's a cgi-script or a cgi-include).
+ The
+ other variables will exist only if they existed prior to the
+ error/problem.
<STRONG>None</STRONG> of these will be set if your ErrorDocument is an
- <EM>external</EM> redirect (i.e. anything starting with a protocol name
+ <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a
+ scheme name
like <CODE>http:</CODE>, even if it refers to the same host as the
server).<P>
<DT>Configuration
<DD> Use of "ErrorDocument" is enabled for .htaccess files when the
- <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is allowed.
+ <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is
+ allowed.
<P>Here are some examples...
<DT>Old behavior
<DD>Standard CGI vars were made available to a script which has been
- redirected to. No indication of where the redirection came from was provided.
+ redirected to. No indication of where the redirection came from was
+ provided.
<P>
the access log.
</DL>
+<P>
+If the ErrorDocument specifies a local redirect to a CGI script, the script
+should include a "<SAMP>Status:</SAMP>" header field in its output
+in order to ensure the propagation all the way back to the client
+of the error condition that caused it to be invoked. For instance, a Perl
+ErrorDocument script might include the following:
+</P>
+<PRE>
+ :
+ print "Content-type: text/html\n";
+ printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
+ :
+</PRE>
+<P>
+If the script is dedicated to handling a particular error condition, such as
+<SAMP>404 Not Found</SAMP>, it can use the specific code and
+error text instead.
+</P>
<!--#include virtual="footer.html" -->
</BODY>
<MENU>
<LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A>
<LI> <A HREF="#req_orig">Where request_rec structures come from</A>
- <LI> <A HREF="#req_return">Handling requests, declining, and returning error codes</A>
+ <LI> <A HREF="#req_return">Handling requests, declining, and returning error
+ codes</A>
<LI> <A HREF="#resp_handlers">Special considerations for response handlers</A>
- <LI> <A HREF="#auth_handlers">Special considerations for authentication handlers</A>
+ <LI> <A HREF="#auth_handlers">Special considerations for authentication
+ handlers</A>
<LI> <A HREF="#log_handlers">Special considerations for logging handlers</A>
</MENU>
<LI> <A HREF="#pools">Resource allocation and resource pools</A>
<MENU>
<LI> <A HREF="#per-dir">Per-directory configuration structures</A>
<LI> <A HREF="#commands">Command handling</A>
- <LI> <A HREF="#servconf">Side notes --- per-server configuration, virtual servers, etc.</A>
+ <LI> <A HREF="#servconf">Side notes --- per-server configuration,
+ virtual servers, <EM>etc</EM>.</A>
</MENU>
</UL>
-<H2><A name="basics">Basic concepts.</A></H2>
+<H2><A NAME="basics">Basic concepts.</A></H2>
We begin with an overview of the basic concepts behind the
API, and how they are manifested in the code.
-<H3><A name="HMR">Handlers, Modules, and Requests</A></H3>
+<H3><A NAME="HMR">Handlers, Modules, and Requests</A></H3>
Apache breaks down request handling into a series of steps, more or
less the same way the Netscape server API does (although this API has
<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>ap_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>
<P>
One of the problems of writing and designing a server-pool server is
that of preventing leakage, that is, allocating resources (memory,
returns a pointer to 8 bytes worth of memory, initialized to
<CODE>"foo/bar"</CODE>.
</P>
-<H3><A name="pools-used">Commonly-used pools in the Apache Web server</A></H3>
+<H3><A NAME="pools-used">Commonly-used pools in the Apache Web server</A></H3>
<P>
A pool is really defined by its lifetime more than anything else. There
are some static pools in http_main which are passed to various
</LI>
<LI>created at the beginning of a config "cycle"; exists until the
server is terminated or restarts; passed to all config-time
- routines, either via cmd->pool, or as the "pool *p" argument on
+ routines, either via cmd->pool, or as the "pool *p" argument on
those which don't take pools
</LI>
<LI>passed to the module init() functions
<LI>subpool of permanent_pool
</LI>
<LI>created at the beginning of a config "cycle"; exists until the
- end of config parsing; passed to config-time routines via
- cmd->temp_pool. Somewhat of a "bastard child" because it isn't
+ end of config parsing; passed to config-time routines <EM>via</EM>
+ cmd->temp_pool. Somewhat of a "bastard child" because it isn't
available everywhere. Used for temporary scratch space which
may be needed by some config routines but which is deleted at
the end of config.
<LI>cleared by the child before going into the accept() loop to receive
a connection
</LI>
- <LI>used as connection->pool
+ <LI>used as connection->pool
</LI>
</UL>
</DD>
- <DT>r->pool
+ <DT>r->pool
</DT>
<DD>
<UL>
- <LI>for the main request this is a subpool of connection->pool; for
+ <LI>for the main request this is a subpool of connection->pool; for
subrequests it is a subpool of the parent request's pool.
</LI>
<LI>exists until the end of the request (<EM>i.e.</EM>, destroy_sub_req, or
in child_main after process_request has finished)
</LI>
- <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>, r->pool is
+ <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>,
+ r->pool is
first created and then r is the first thing palloc()d from it
</LI>
</UL>
</DD>
</DL>
<P>
-For almost everything folks do, r->pool is the pool to use. But you
+For almost everything folks do, r->pool is the pool to use. But you
can see how other lifetimes, such as pchild, are useful to some
modules... such as modules that need to open a database connection once
per child, and wish to clean it up when the child dies.
</P>
<P>
You can also see how some bugs have manifested themself, such as setting
-connection->user to a value from r->pool -- in this case connection exists
-for the lifetime of ptrans, which is longer than r->pool (especially if
-r->pool is a subrequest!). So the correct thing to do is to allocate
-from connection->pool.
+connection->user to a value from r->pool -- in this case
+connection exists
+for the lifetime of ptrans, which is longer than r->pool (especially if
+r->pool is a subrequest!). So the correct thing to do is to allocate
+from connection->pool.
</P>
<P>
And there was another interesting bug in mod_include/mod_cgi. You'll see
-in those that they do this test to decide if they should use r->pool
-or r->main->pool. In this case the resource that they are registering
-for cleanup is a child process. If it were registered in r->pool,
+in those that they do this test to decide if they should use r->pool
+or r->main->pool. In this case the resource that they are registering
+for cleanup is a child process. If it were registered in r->pool,
then the code would wait() for the child when the subrequest finishes.
With mod_include this could be any old #include, and the delay can be up
to 3 seconds... and happened quite frequently. Instead the subprocess
-is registered in r->main->pool which causes it to be cleaned up when
+is registered in r->main->pool which causes it to be cleaned up when
the entire request is done -- <EM>i.e.</EM>, after the output has been sent to
the client and logging has happened.
</P>
-<H3><A name="pool-files">Tracking open files, etc.</A></H3>
+<H3><A NAME="pool-files">Tracking open files, etc.</A></H3>
<P>
As indicated above, resource pools are also used to track other sorts
of resources besides memory. The most common are open files. The
for a single main request that you should seriously consider the
<CODE>ap_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, <EM>etc</EM>.</A></H3>
The basic ideas behind per-server module configuration are basically
the same as those for per-directory configuration; there is a creation
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>
decisions of the port to this machine.
</P>
- <H2 ALIGN=center>Design Goals</H2>
+ <H2 ALIGN=CENTER>Design Goals</H2>
<P>
One objective of the EBCDIC port was to maintain enough backwards
compatibility with the (EBCDIC) CERN server to make the transition to
documents which must be converted.
</P>
- <H2 ALIGN=center>Technical Solution</H2>
+ <H2 ALIGN=CENTER>Technical Solution</H2>
<P>
Since all Apache input and output is based upon the BUFF data type
and its methods, the easiest solution was to add the conversion to
</UL>
</P>
-<H2 ALIGN=center>Porting Notes</H2>
+<H2 ALIGN=CENTER>Porting Notes</H2>
<P>
<OL>
<LI>
</OL>
</P>
- <H2 ALIGN=center>Document Storage Notes</H2>
- <H3 ALIGN=center>Binary Files</H3>
+ <H2 ALIGN=CENTER>Document Storage Notes</H2>
+ <H3 ALIGN=CENTER>Binary Files</H3>
<P>
All files with a <SAMP>Content-Type:</SAMP> which does not
start with <SAMP>text/</SAMP> are regarded as <EM>binary files</EM>
(the -b switch is not supported in unix rcp's).
</P>
- <H3 ALIGN=center>Text Documents</H3>
+ <H3 ALIGN=CENTER>Text Documents</H3>
<P>
The default assumption of the server is that Text Files
(i.e., all files whose <SAMP>Content-Type:</SAMP> starts with
set of the host, EBCDIC.
</P>
- <H3 ALIGN=center>Server Side Included Documents</H3>
+ <H3 ALIGN=CENTER>Server Side Included Documents</H3>
<P>
SSI documents must currently be stored in EBCDIC only. No
provision is made to convert it from ASCII before processing.
</P>
- <H2 ALIGN=center>Apache Modules' Status</H2>
+ <H2 ALIGN=CENTER>Apache Modules' Status</H2>
<TABLE BORDER ALIGN=middle>
<TR>
<TH>Module
</TR>
<TR>
- <TD ALIGN=left>http_core
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>http_core
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_access
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_access
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_actions
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_actions
+ <TD ALIGN=CENTER>?
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_alias
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_alias
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_asis
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_asis
+ <TD ALIGN=CENTER>?
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_auth
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_auth
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_auth_anon
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_auth_anon
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_auth_db
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_auth_db
+ <TD ALIGN=CENTER>?
<TD>with own libdb.a
</TR>
<TR>
- <TD ALIGN=left>mod_auth_dbm
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_auth_dbm
+ <TD ALIGN=CENTER>?
<TD>with own libdb.a
</TR>
<TR>
- <TD ALIGN=left>mod_autoindex
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_autoindex
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_cern_meta
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_cern_meta
+ <TD ALIGN=CENTER>?
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_cgi
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_cgi
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_digest
- <TD ALIGN=center>-
+ <TD ALIGN=LEFT>mod_digest
+ <TD ALIGN=CENTER>-
<TD>MD5 not ported yet
</TR>
<TR>
- <TD ALIGN=left>mod_dir
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_dir
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_dld
- <TD ALIGN=center>-
+ <TD ALIGN=LEFT>mod_dld
+ <TD ALIGN=CENTER>-
<TD>no shared libs
</TR>
<TR>
- <TD ALIGN=left>mod_env
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_env
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_example
- <TD ALIGN=center>-
+ <TD ALIGN=LEFT>mod_example
+ <TD ALIGN=CENTER>-
<TD>not tried yet
</TR>
<TR>
- <TD ALIGN=left>mod_expires
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_expires
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_headers
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_headers
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_imap
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_imap
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_include
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_include
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_info
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_info
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_log_agent
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_log_agent
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_log_config
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_log_config
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_log_referer
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_log_referer
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_mime
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_mime
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_mime_magic
- <TD ALIGN=center>-
+ <TD ALIGN=LEFT>mod_mime_magic
+ <TD ALIGN=CENTER>-
<TD>not tried yet
</TR>
<TR>
- <TD ALIGN=left>mod_negotiation
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_negotiation
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_proxy
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_proxy
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_rewrite
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_rewrite
+ <TD ALIGN=CENTER>?
<TD>untested
</TR>
<TR>
- <TD ALIGN=left>mod_setenvif
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_setenvif
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_speling
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_speling
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_status
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_status
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_unique_id
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_unique_id
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_userdir
- <TD ALIGN=center>+
+ <TD ALIGN=LEFT>mod_userdir
+ <TD ALIGN=CENTER>+
<TD>
</TR>
<TR>
- <TD ALIGN=left>mod_usertrack
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT>mod_usertrack
+ <TD ALIGN=CENTER>?
<TD>untested
</TR>
</TABLE>
- <H2 ALIGN=center>Third Party Modules' Status</H2>
+ <H2 ALIGN=CENTER>Third Party Modules' Status</H2>
<TABLE BORDER ALIGN=middle>
<TR>
<TH>Module
</TR>
<TR>
- <TD ALIGN=
left><A HREF="http://java.apache.org/">mod_jserv</A>
- <TD ALIGN=center>-
+ <TD ALIGN=
LEFT><A HREF="http://java.apache.org/">mod_jserv</A>
+ <TD ALIGN=CENTER>-
<TD>JAVA still being ported.
</TR>
<TR>
- <TD ALIGN=
left><A HREF="http://www.php.net/">mod_php</A>
- <TD ALIGN=center>-
+ <TD ALIGN=
LEFT><A HREF="http://www.php.net/">mod_php</A>
+ <TD ALIGN=CENTER>-
<TD>not ported yet
</TR>
<TR>
- <TD ALIGN=left><A HREF="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">mod_put</A>
- <TD ALIGN=center>?
+ <TD ALIGN=LEFT
+ ><A HREF="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">mod_put</A>
+ <TD ALIGN=CENTER>?
<TD>untested
</TR>
<TR>
- <TD ALIGN=left><A HREF="ftp://hachiman.vidya.com/pub/apache/">mod_session</A>
- <TD ALIGN=center>-
+ <TD ALIGN=LEFT
+ ><A HREF="ftp://hachiman.vidya.com/pub/apache/">mod_session</A>
+ <TD ALIGN=CENTER>-
<TD>untested
</TR>
<HR>
-<H2><A name="addhandler">AddHandler</A></H2>
+<H2><A NAME="addhandler">AddHandler</A></H2>
<A
HREF="mod/directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name extension</EM>><BR>
+><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name
+ extension</EM>><BR>
<A
HREF="mod/directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="mod/directive-dict.html#Status"
REL="Help"
<HR>
-<H2><A name="sethandler">SetHandler</A></H2>
+<H2><A NAME="sethandler">SetHandler</A></H2>
<A
HREF="mod/directive-dict.html#Syntax"
<HR>
-<H2><A name="addhandler">AddHandler</A></H2>
+<H2><A NAME="addhandler">AddHandler</A></H2>
<A
HREF="mod/directive-dict.html#Syntax"
REL="Help"
-><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name extension</EM>><BR>
+><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name
+ extension</EM>><BR>
<A
HREF="mod/directive-dict.html#Context"
REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR>
+><STRONG>Context:</STRONG></A> server config, virtual host, directory,
+ .htaccess<BR>
<A
HREF="mod/directive-dict.html#Status"
REL="Help"
<HR>
-<H2><A name="sethandler">SetHandler</A></H2>
+<H2><A NAME="sethandler">SetHandler</A></H2>
<A
HREF="mod/directive-dict.html#Syntax"
The modules we place in the Apache distribution are the ones we have
tested and are used regularly by various members of the Apache
development group. Additional modules contributed by members or third
-parties with specific needs or functions are available at <A
-HREF="http://www.apache.org/dist/contrib/modules/"><URL:http://www.apache.org/dist/contrib/modules/></A>.
+parties with specific needs or functions are available at
+<<A HREF="http://www.apache.org/dist/contrib/modules/"
+ >http://www.apache.org/dist/contrib/modules/</A>>.
There are instructions on that page for linking these modules into the
core Apache code.
The modules we place in the Apache distribution are the ones we have
tested and are used regularly by various members of the Apache
development group. Additional modules contributed by members or third
-parties with specific needs or functions are available at <A
-HREF="http://www.apache.org/dist/contrib/modules/"><URL:http://www.apache.org/dist/contrib/modules/></A>.
+parties with specific needs or functions are available at
+<<A HREF="http://www.apache.org/dist/contrib/modules/"
+ >http://www.apache.org/dist/contrib/modules/</A>>.
There are instructions on that page for linking these modules into the
core Apache code.
<DT><CODE>-v</CODE>
<DD>Print the version of httpd and its build date, and then exit.
-<DT><A name="version"><CODE>-V</CODE></A>
+<DT><A NAME="version"><CODE>-V</CODE></A>
<DD>Print the base version of httpd, its sub-version if defined, its
build date, and a list of compile time settings which influence the
-behavior and performance of the apache server (e.g., <SAMP>-D USE_MMAP_FILES</SAMP>),
+behavior and performance of the apache server (<EM>e.g.</EM>,
+<SAMP>-DUSE_MMAP_FILES</SAMP>),
then exit.
-<DT><A name="help"><CODE>-h</CODE></A>
+<DT><A NAME="help"><CODE>-h</CODE></A>
<DD>Give a list of directives together with expected arguments and
places where the directive is valid. (New in Apache 1.2)
However, these conventions need not be adhered to.
<P>
The server also reads a file containing mime document types; the filename
-is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> directive,
+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>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
+<A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs
+can
be set for different <A HREF="mod/core.html#virtualhost">virtual hosts</A>.
<H3>Transfer log</H3>
The server will typically log each request to a transfer file,
<CODE>logs/access_log</CODE> by default. The filename can be set using a
-<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different
-transfer logs can be set for different <A HREF="mod/core.html#virtualhost">virtual
-hosts</A>.
+<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive;
+different transfer logs can be set for different
+<A HREF="mod/core.html#virtualhost">virtual hosts</A>.
<!--#include virtual="footer.html" -->
</BODY>
<DT><CODE>-v</CODE>
<DD>Print the version of httpd and its build date, and then exit.
-<DT><A name="version"><CODE>-V</CODE></A>
+<DT><A NAME="version"><CODE>-V</CODE></A>
<DD>Print the base version of httpd, its sub-version if defined, its
build date, and a list of compile time settings which influence the
-behavior and performance of the apache server (e.g., <SAMP>-D USE_MMAP_FILES</SAMP>),
+behavior and performance of the apache server (<EM>e.g.</EM>,
+<SAMP>-DUSE_MMAP_FILES</SAMP>),
then exit.
-<DT><A name="help"><CODE>-h</CODE></A>
+<DT><A NAME="help"><CODE>-h</CODE></A>
<DD>Give a list of directives together with expected arguments and
places where the directive is valid. (New in Apache 1.2)
However, these conventions need not be adhered to.
<P>
The server also reads a file containing mime document types; the filename
-is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> directive,
+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>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
+<A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs
+can
be set for different <A HREF="mod/core.html#virtualhost">virtual hosts</A>.
<H3>Transfer log</H3>
The server will typically log each request to a transfer file,
<CODE>logs/access_log</CODE> by default. The filename can be set using a
-<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different
-transfer logs can be set for different <A HREF="mod/core.html#virtualhost">virtual
-hosts</A>.
+<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive;
+different transfer logs can be set for different
+<A HREF="mod/core.html#virtualhost">virtual hosts</A>.
<!--#include virtual="footer.html" -->
</BODY>
<!--#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="mod/directive-dict.html#Syntax"
<MENU>
<LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A>
<LI> <A HREF="#req_orig">Where request_rec structures come from</A>
- <LI> <A HREF="#req_return">Handling requests, declining, and returning error codes</A>
+ <LI> <A HREF="#req_return">Handling requests, declining, and returning error
+ codes</A>
<LI> <A HREF="#resp_handlers">Special considerations for response handlers</A>
- <LI> <A HREF="#auth_handlers">Special considerations for authentication handlers</A>
+ <LI> <A HREF="#auth_handlers">Special considerations for authentication
+ handlers</A>
<LI> <A HREF="#log_handlers">Special considerations for logging handlers</A>
</MENU>
<LI> <A HREF="#pools">Resource allocation and resource pools</A>
<MENU>
<LI> <A HREF="#per-dir">Per-directory configuration structures</A>
<LI> <A HREF="#commands">Command handling</A>
- <LI> <A HREF="#servconf">Side notes --- per-server configuration, virtual servers, etc.</A>
+ <LI> <A HREF="#servconf">Side notes --- per-server configuration,
+ virtual servers, <EM>etc</EM>.</A>
</MENU>
</UL>
-<H2><A name="basics">Basic concepts.</A></H2>
+<H2><A NAME="basics">Basic concepts.</A></H2>
We begin with an overview of the basic concepts behind the
API, and how they are manifested in the code.
-<H3><A name="HMR">Handlers, Modules, and Requests</A></H3>
+<H3><A NAME="HMR">Handlers, Modules, and Requests</A></H3>
Apache breaks down request handling into a series of steps, more or
less the same way the Netscape server API does (although this API has
<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>ap_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>
<P>
One of the problems of writing and designing a server-pool server is
that of preventing leakage, that is, allocating resources (memory,
returns a pointer to 8 bytes worth of memory, initialized to
<CODE>"foo/bar"</CODE>.
</P>
-<H3><A name="pools-used">Commonly-used pools in the Apache Web server</A></H3>
+<H3><A NAME="pools-used">Commonly-used pools in the Apache Web server</A></H3>
<P>
A pool is really defined by its lifetime more than anything else. There
are some static pools in http_main which are passed to various
</LI>
<LI>created at the beginning of a config "cycle"; exists until the
server is terminated or restarts; passed to all config-time
- routines, either via cmd->pool, or as the "pool *p" argument on
+ routines, either via cmd->pool, or as the "pool *p" argument on
those which don't take pools
</LI>
<LI>passed to the module init() functions
<LI>subpool of permanent_pool
</LI>
<LI>created at the beginning of a config "cycle"; exists until the
- end of config parsing; passed to config-time routines via
- cmd->temp_pool. Somewhat of a "bastard child" because it isn't
+ end of config parsing; passed to config-time routines <EM>via</EM>
+ cmd->temp_pool. Somewhat of a "bastard child" because it isn't
available everywhere. Used for temporary scratch space which
may be needed by some config routines but which is deleted at
the end of config.
<LI>cleared by the child before going into the accept() loop to receive
a connection
</LI>
- <LI>used as connection->pool
+ <LI>used as connection->pool
</LI>
</UL>
</DD>
- <DT>r->pool
+ <DT>r->pool
</DT>
<DD>
<UL>
- <LI>for the main request this is a subpool of connection->pool; for
+ <LI>for the main request this is a subpool of connection->pool; for
subrequests it is a subpool of the parent request's pool.
</LI>
<LI>exists until the end of the request (<EM>i.e.</EM>, destroy_sub_req, or
in child_main after process_request has finished)
</LI>
- <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>, r->pool is
+ <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>,
+ r->pool is
first created and then r is the first thing palloc()d from it
</LI>
</UL>
</DD>
</DL>
<P>
-For almost everything folks do, r->pool is the pool to use. But you
+For almost everything folks do, r->pool is the pool to use. But you
can see how other lifetimes, such as pchild, are useful to some
modules... such as modules that need to open a database connection once
per child, and wish to clean it up when the child dies.
</P>
<P>
You can also see how some bugs have manifested themself, such as setting
-connection->user to a value from r->pool -- in this case connection exists
-for the lifetime of ptrans, which is longer than r->pool (especially if
-r->pool is a subrequest!). So the correct thing to do is to allocate
-from connection->pool.
+connection->user to a value from r->pool -- in this case
+connection exists
+for the lifetime of ptrans, which is longer than r->pool (especially if
+r->pool is a subrequest!). So the correct thing to do is to allocate
+from connection->pool.
</P>
<P>
And there was another interesting bug in mod_include/mod_cgi. You'll see
-in those that they do this test to decide if they should use r->pool
-or r->main->pool. In this case the resource that they are registering
-for cleanup is a child process. If it were registered in r->pool,
+in those that they do this test to decide if they should use r->pool
+or r->main->pool. In this case the resource that they are registering
+for cleanup is a child process. If it were registered in r->pool,
then the code would wait() for the child when the subrequest finishes.
With mod_include this could be any old #include, and the delay can be up
to 3 seconds... and happened quite frequently. Instead the subprocess
-is registered in r->main->pool which causes it to be cleaned up when
+is registered in r->main->pool which causes it to be cleaned up when
the entire request is done -- <EM>i.e.</EM>, after the output has been sent to
the client and logging has happened.
</P>
-<H3><A name="pool-files">Tracking open files, etc.</A></H3>
+<H3><A NAME="pool-files">Tracking open files, etc.</A></H3>
<P>
As indicated above, resource pools are also used to track other sorts
of resources besides memory. The most common are open files. The
for a single main request that you should seriously consider the
<CODE>ap_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, <EM>etc</EM>.</A></H3>
The basic ideas behind per-server module configuration are basically
the same as those for per-directory configuration; there is a creation
<HEAD>
<TITLE>Apache Server Frequently Asked Questions</TITLE>
</HEAD>
-
- <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
<P>
- $Revision: 1.115 $ ($Date: 1998/05/20 11:12:42 $)
+ $Revision: 1.116 $ ($Date: 1998/05/20 14:22:39 $)
</P>
<P>
The latest version of this FAQ is always available from the main
<HR>
</LI>
- <LI><A name="jdk1-and-http1.1">
+ <LI><A NAME="jdk1-and-http1.1">
<STRONG>Why do my Java app[let]s give me plain text when I request
an URL from an Apache server?</STRONG>
</A>
should proceed (to step 3).
This step also sends a 100 Continue response
to HTTP/1.1 clients, so should not be called until the module
- is <STRONG>*definitely*</STRONG> ready to read content. (otherwise, the point of the
+ is <STRONG>*definitely*</STRONG> ready to read content. (otherwise, the
+ point of the
100 response is defeated). Never call this function more than once.
<LI>Finally, call <CODE>ap_get_client_block</CODE> in a loop. Pass it a
native language.
</P>
<P>
-By using XSSI, all <A HREF="../mod/core.html#errordocument">customized messages</A>
+By using XSSI, all
+<A HREF="../mod/core.html#errordocument">customized messages</A>
can share a homogenous and consistent style and layout, and maintenance work
(changing images, changing links) is kept to a minimum because all layout
information can be kept in a single file.<BR>
<LI>By defining the <A HREF="../mod/core.html#options">MultiViews option</A>,
we enable the language selection of the most appropriate language
alternative (content negotiation).
- <LI>By setting the <A HREF="../mod/mod_negotiation.html#languagepriority">LanguagePriority</A>
+ <LI>By setting the
+ <A HREF="../mod/mod_negotiation.html#languagepriority"
+ >LanguagePriority</A>
directive we define a set of default fallback languages in the situation
where the client's browser did not express any preference at all.
<LI>By enabling <A HREF="../mod/mod_include.html">Server Side Includes</A>
restricts these "special" settings to the error document directory
and avoids an impact on any of the settings for the regular document tree.
<LI>For each of the error codes to be handled (see RFC2068 for an exact
- description of each error code, or look at <CODE>src/main/http_protocol.c</CODE>
+ description of each error code, or look at
+ <CODE>src/main/http_protocol.c</CODE>
if you wish to see apache's standard messages), an
<A HREF="../mod/core.html#errordocument">ErrorDocument</A>
in the aliased <SAMP>/errordocs</SAMP> directory is defined.
because it contains server-parsed content but no language specific
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>
+<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>
implementation of the discussed example.
-<H3><A NAME="createdocs">Creating ErrorDocuments in different languages</A></H3>
+<H3><A NAME="createdocs">Creating ErrorDocuments in different languages</A>
+</H3>
After all this preparation work, little remains to be said about the
actual documents. They all share a simple common structure:
<PRE>
-<!--#set var="title" value="<EM>error description title</EM>" -->
-<!--#include virtual="head" -->
+<!--#set var="title" value="<EM>error description title</EM>" -->
+<!--#include virtual="head" -->
<EM>explanatory error text</EM>
-<!--#include virtual="foot" -->
+<!--#include virtual="foot" -->
</PRE>
In the <A HREF="#listings">listings section</A>, you can see an example
of a [400 Bad Request] error document. Documents as simple as that
Starting with this example, you will find it easy to add more error
documents, or to translate the error documents to different languages.
<HR><PRE>
-<!--#set var="title" value="Bad Request"
---><!--#include virtual="head" --><P>
+<!--#set var="title" value="Bad Request"
+--><!--#include virtual="head" --><P>
Your browser sent a request that this server could not understand:
<BLOCKQUOTE>
- <STRONG><!--#echo var="REQUEST_URI" --></STRONG>
+ <STRONG><!--#echo var="REQUEST_URI" --></STRONG>
</BLOCKQUOTE>
The request could not be understood by the server due to malformed
syntax. The client should not repeat the request without
modifications.
</P>
<P>
- <!--#if expr="\"$HTTP_REFERER\" != \"\"" -->
+ <!--#if expr="\"$HTTP_REFERER\" != \"\"" -->
Please inform the owner of
- <A HREF="<!--#echo var="HTTP_REFERER" -->">the referring page</A> about
+ <A HREF="<!--#echo var="HTTP_REFERER" -->">the referring page</A> about
the malformed link.
<!--#else -->
Please check your request for typing errors and retry.
<!--#endif -->
</P>
-<!--#include virtual="foot" -->
+<!--#include virtual="foot" -->
</PRE><HR>
Here is the complete <SAMP>head.shtml</SAMP> file (the funny line
of the form <BR><CODE>BrowserMatch "^Mozilla/[2-4]" anigif</CODE><BR>
for browser types which support animated GIFs).
<HR><PRE>
-<!--#if expr="\"$SERVER_NAME\" = /.*\.mycompany\.com/"
---><!--#set var="IMG_CorpLogo"
- value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif"
---><!--#set var="ALT_CorpLogo" value="Powered by Linux!"
+<!--#if expr="\"$SERVER_NAME\" = /.*\.mycompany\.com/"
+--><!--#set var="IMG_CorpLogo"
+ value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif"
+--><!--#set var="ALT_CorpLogo" value="Powered by Linux!"
--><!--#else
---><!--#set var="IMG_CorpLogo"
- value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif"
---><!--#set var="ALT_CorpLogo" value="Powered by Linux!"
+--><!--#set var="IMG_CorpLogo"
+ value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif"
+--><!--#set var="ALT_CorpLogo" value="Powered by Linux!"
--><!--#endif
---><!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif"
---><!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/"
---><!--#if expr="$anigif"
---><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif"
+--><!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif"
+--><!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/"
+--><!--#if expr="$anigif"
+--><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif"
--><!--#else
---><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif"
+--><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif"
--><!--#endif
---><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+--><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<TITLE>
- [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
+ [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
</TITLE>
</HEAD>
- <BODY BGCOLOR="white" BACKGROUND="<!--#echo var="IMG_BgImage" -->"><UL>
- <H1 ALIGN="center">
- [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
- <IMG SRC="<!--#echo var="IMG_CorpLogo" -->"
- ALT="<!--#echo var="ALT_CorpLogo" -->" ALIGN=right>
+ <BODY BGCOLOR="white" BACKGROUND="<!--#echo var="IMG_BgImage" -->"><UL>
+ <H1 ALIGN="center">
+ [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
+ <IMG SRC="<!--#echo var="IMG_CorpLogo" -->"
+ ALT="<!--#echo var="ALT_CorpLogo" -->" ALIGN=right>
</H1>
<HR><!-- ======================================================== -->
<DIV>
</DIV>
<HR>
- <DIV ALIGN="right"><SMALL><SUP>Local Server time:
- <!--#echo var="DATE_LOCAL" -->
+ <DIV ALIGN="right"><SMALL><SUP>Local Server time:
+ <!--#echo var="DATE_LOCAL" -->
</SUP></SMALL></DIV>
- <DIV ALIGN="center">
- <A HREF="<!--#echo var="DOC_Apache" -->">
- <IMG SRC="<!--#echo var="IMG_Apache" -->" BORDER=0 ALIGN="bottom"
- ALT="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></A><BR>
- <SMALL><SUP><!--#set var="var"
- value="Powered by $SERVER_SOFTWARE -- File last modified on $LAST_MODIFIED"
- --><!--#echo var="var" --></SUP></SMALL>
+ <DIV ALIGN="center">
+ <A HREF="<!--#echo var="DOC_Apache" -->">
+ <IMG SRC="<!--#echo var="IMG_Apache" -->" BORDER=0 ALIGN="bottom"
+ ALT="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></A><BR>
+ <SMALL><SUP><!--#set var="var"
+ value="Powered by $SERVER_SOFTWARE -- File last modified on $LAST_MODIFIED"
+ --><!--#echo var="var" --></SUP></SMALL>
</DIV>
<ADDRESS>If the indicated error looks like a misconfiguration, please inform
- <A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->"
- SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS"
- -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
- <!--#echo var="SERVER_NAME" -->'s WebMaster</A>.
+ <A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->"
+ SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS"
+ -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
+ <!--#echo var="SERVER_NAME" -->'s WebMaster</A>.
</ADDRESS>
</UL></BODY>
</HTML>
The following systems are known to have a timeout:
<P>
<UL>
- <LI><A HREF="http://www.freebsd.org/">FreeBSD</A> versions starting at 2.0 or possibly earlier.
+ <LI><A HREF="http://www.freebsd.org/">FreeBSD</A> versions starting at
+ 2.0 or possibly earlier.
<LI><A HREF="http://www.netbsd.org/">NetBSD</A> version 1.2(?)
<LI><A HREF="http://www.openbsd.org/">OpenBSD</A> all versions(?)
<LI><A HREF="http://www.bsdi.com/">BSD/OS</A> 2.1, with the
</UL>
<P>
There is a
-<A HREF="http://www.apache.org/dist/contrib/patches/1.2/fin_wait_2.patch">
-patch available</A> for adding a timeout to the FIN_WAIT_2 state; it
+<A HREF="http://www.apache.org/dist/contrib/patches/1.2/fin_wait_2.patch"
+>patch available</A> for adding a timeout to the FIN_WAIT_2 state; it
was originally intended for BSD/OS, but should be adaptable to most
systems using BSD networking code. You need kernel source code to be
able to use it. If you do adapt it to work for any other systems,
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
-<META NAME="description" CONTENT="Some 'how to' tips for the Apache httpd server">
+<META NAME="description"
+ CONTENT="Some 'how to' tips for the Apache httpd server">
<META NAME="keywords" CONTENT="apache,redirect,robots,rotate,logfiles">
<TITLE>Apache HOWTO documentation</TITLE>
</HEAD>
How to:
<UL>
-<LI><A HREF="#redirect">redirect an entire server or directory to a single URL</A>
+<LI><A HREF="#redirect">redirect an entire server or directory to a single
+ URL</A>
<LI><A HREF="#logreset">reset your log files</A>
<LI><A HREF="#stoprob">stop/restrict robots</A>
</UL>
<HR>
-<H2><A name="redirect">How to redirect an entire server or directory to a single URL</A></H2>
+<H2><A NAME="redirect">How to redirect an entire server or directory to a
+single URL</A></H2>
<P>There are two chief ways to redirect all requests for an entire
server to a single location: one which requires the use of
structure has changed after the move, and you simply want to direct people
to the home page.
-<P>The best option is to use the standard Apache module <CODE>mod_rewrite</CODE>.
-If that module is compiled in, the following lines:
+<P>The best option is to use the standard Apache module
+<CODE>mod_rewrite</CODE>.
+If that module is compiled in, the following lines
<BLOCKQUOTE><PRE>RewriteEngine On
RewriteRule /.* http://www.apache.org/ [R]
"http://www.apache.org".
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
+a <STRONG>cgi script</STRONG> which outputs a 301 or 302 status and the
+location
of the other server.</P>
-<P>By using a <STRONG>cgi-script</STRONG> you can intercept various requests and
+<P>By using a <STRONG>cgi-script</STRONG> you can intercept various requests
+and
treat them specially, e.g. you might want to intercept <STRONG>POST</STRONG>
requests, so that the client isn't redirected to a script on the other
server which expects POST information (a redirect will lose the POST
<P>Here's how to redirect all requests to a script... In the server
configuration file,
-<BLOCKQUOTE><PRE>ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script</PRE></BLOCKQUOTE>
+<BLOCKQUOTE><PRE>ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script</PRE>
+</BLOCKQUOTE>
and here's a simple perl script to redirect requests:
<HR>
-<H2><A name="logreset">How to reset your log files</A></H2>
+<H2><A NAME="logreset">How to reset your log files</A></H2>
<P>Sooner or later, you'll want to reset your log files (access_log and
error_log) because they are too big, or full of old information you don't
as big as the old one, but it now contains thousands (or millions) of null
characters.</P>
-<P>The correct procedure is to move the logfile, then signal Apache to tell it to reopen the logfiles.</P>
+<P>The correct procedure is to move the logfile, then signal Apache to tell
+it to reopen the logfiles.</P>
<P>Apache is signaled using the <STRONG>SIGHUP</STRONG> (-1) signal. e.g.
<BLOCKQUOTE><CODE>
</CODE></BLOCKQUOTE>
</P>
-<P>Note: <CODE>httpd.pid</CODE> is a file containing the <STRONG>p</STRONG>rocess <STRONG>id</STRONG>
+<P>Note: <CODE>httpd.pid</CODE> is a file containing the
+<STRONG>p</STRONG>rocess <STRONG>id</STRONG>
of the Apache httpd daemon, Apache saves this in the same directory as the log
files.</P>
nightly or weekly basis.</P>
<HR>
-<H2><A name="stoprob">How to stop or restrict robots</A></H2>
+<H2><A NAME="stoprob">How to stop or restrict robots</A></H2>
<P>Ever wondered why so many clients are interested in a file called
<CODE>robots.txt</CODE> which you don't have, and never did have?</P>
<P>If you decide to exclude robots completely, or just limit the areas
in which they can roam, create a <CODE>robots.txt</CODE> file; refer
-to the <A HREF="http://info.webcrawler.com/mak/projects/robots/robots.html">robot information pages</A> provided by Martijn Koster for the syntax.</P>
+to the <A HREF="http://info.webcrawler.com/mak/projects/robots/robots.html"
+>robot information pages</A> provided by Martijn Koster for the syntax.</P>
<!--#include virtual="footer.html" -->
</BODY>
<A HREF="../mod/mod_browser.html">mod_browser</A>. Unless otherwise
noted all of these workarounds exist in versions 1.2 and later.
-<H3><A name="trailing-crlf">Trailing CRLF on POSTs</A></H3>
+<H3><A NAME="trailing-crlf">Trailing CRLF on POSTs</A></H3>
<P>This is a legacy issue. The CERN webserver required <CODE>POST</CODE>
data to have an extra <CODE>CRLF</CODE> following it. Thus many
Apache works around this problem by eating any empty lines which
appear before a request.
-<H3><A name="broken-keepalive">Broken keepalive</A></H3>
+<H3><A NAME="broken-keepalive">Broken keepalive</A></H3>
<P>Various clients have had broken implementations of <EM>keepalive</EM>
(persistent connections). In particular the Windows versions of
support keepalive when it is used on 301 or 302 (redirect)
responses. Unfortunately Apache's <CODE>nokeepalive</CODE> code
prior to 1.2.2 would not work with HTTP/1.1 clients. You must apply
-<A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">this
-patch</A> to version 1.2.1. Then add this to your config:
+<A
+HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"
+>this patch</A> to version 1.2.1. Then add this to your config:
<BLOCKQUOTE><CODE>
BrowserMatch "MSIE 4\.0b2;" nokeepalive
</CODE></BLOCKQUOTE>
-<H3><A name="force-response-1.0">Incorrect interpretation of <CODE>HTTP/1.1</CODE> in response</A></H3>
+<H3><A NAME="force-response-1.0">Incorrect interpretation of
+<CODE>HTTP/1.1</CODE> in response</A></H3>
<P>To quote from section 3.1 of RFC1945:
<BLOCKQUOTE>
BrowserMatch "RealPlayer 4.0" force-response-1.0
</CODE></BLOCKQUOTE>
-<H3><A name="msie4.0b2">Requests use HTTP/1.1 but responses must be in HTTP/1.0</A></H3>
+<H3><A NAME="msie4.0b2">Requests use HTTP/1.1 but responses must be
+in HTTP/1.0</A></H3>
<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
BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
</CODE></BLOCKQUOTE>
This workaround is available in 1.2.2, and in a
-<A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">patch
-</A> against 1.2.1.
+<A
+HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch"
+>patch</A> against 1.2.1.
-<H3><A name="257th-byte">Boundary problems with header parsing</A></H3>
+<H3><A NAME="257th-byte">Boundary problems with header parsing</A></H3>
<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.
-<H3><A name="boundary-string">Multipart responses and Quoted Boundary Strings</A></H3>
+<H3><A NAME="boundary-string">Multipart responses and Quoted Boundary
+Strings</A></H3>
<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.
-<H3><A name="byterange-requests">Byterange requests</A></H3>
+<H3><A NAME="byterange-requests">Byterange requests</A></H3>
<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.
-<H3><A name="cookie-merge"><CODE>Set-Cookie</CODE> header is unmergeable</A></H3>
+<H3><A NAME="cookie-merge"><CODE>Set-Cookie</CODE> header is
+unmergeable</A></H3>
<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.
-<H3><A name="gif89-expires"><CODE>Expires</CODE> headers and GIF89A animations</A></H3>
+<H3><A NAME="gif89-expires"><CODE>Expires</CODE> headers and GIF89A
+animations</A></H3>
<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>.
-<H3><A name="no-content-length"><CODE>POST</CODE> without <CODE>Content-Length</CODE></A></H3>
+<H3><A NAME="no-content-length"><CODE>POST</CODE> without
+<CODE>Content-Length</CODE></A></H3>
<P>In certain situations Navigator 3.01 through 3.03 appear to incorrectly
issue a POST without the request body. There is no
<A HREF="http://www.arctic.org/~dgaudet/apache/no-content-length/">
some information</A> about the actual problem.
-<H3><A name="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3>
+<H3><A NAME="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3>
<P>The http client in the JDK1.2beta2 and beta3 will throw away the first part of
the response body when both the headers and the first part of the body are sent
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
-<TITLE>Apache Performance Notes</TITLE>
+ <TITLE>Apache Performance Notes</TITLE>
</HEAD>
-<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#000080" alink="#ff0000">
-
+<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+<BODY
+ BGCOLOR="#FFFFFF"
+ TEXT="#000000"
+ LINK="#0000FF"
+ VLINK="#000080"
+ ALINK="#FF0000"
+>
<H1>Apache Performance Notes</H1>
<P>Author: Dean Gaudet
15 seconds attempts to minimize this effect. The tradeoff
here is between network bandwidth and server resources.
In no event should you raise this above about 60 seconds, as
-<A HREF="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html">
-most of the benefits are lost</A>.
+<A HREF="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html"
+>most of the benefits are lost</A>.
<H3>Compile-Time Configuration Issues</H3>
system and timing issues).
They will all then fall down into the loop and try to <CODE>accept</CODE>
the connection. But only one will succeed (assuming there's still only
-one connection ready), the rest will be <EM>blocked</EM> in <CODE>accept</CODE>.
+one connection ready), the rest will be <EM>blocked</EM> in
+<CODE>accept</CODE>.
This effectively locks those children into serving requests from that
one socket and no other sockets, and they'll be stuck there until enough
new requests appear on that socket to wake them all up.
}
</PRE></BLOCKQUOTE>
-<A name="serialize">The functions</A>
+<A NAME="serialize">The functions</A>
<CODE>accept_mutex_on</CODE> and <CODE>accept_mutex_off</CODE>
implement a mutual exclusion semaphore. Only one child can have the
mutex at any time. There are several choices for implementing these
<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,
+<A
+ HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-http-connection-00.txt"
+>draft-ietf-http-connection-00.txt</A> section 8,
in order for an HTTP server to <STRONG>reliably</STRONG> implement the protocol
it needs to shutdown each direction of the communication independently
(recall that a TCP connection is bi-directional, each half is independent
Common Log Format dictates that the log record include a timestamp of the
end of the request. A custom logging module could eliminate one of the
calls. Or you can use a method which moves the time into shared memory,
-see the <a href="#patches">patches section below</a>.
+see the <A HREF="#patches">patches section below</A>.
<P>As described earlier, <CODE>Rule STATUS=yes</CODE> causes two
<CODE>gettimeofday</CODE> calls and a call to <CODE>times</CODE>:
That's 19 system calls, of which 4 remain relatively easy to remove,
but don't seem worth the effort.
-<h3><a name="patches">Appendix: Patches Available</a></h3>
+<H3><A NAME="patches">Appendix: Patches Available</A></H3>
There are
-<a href="http://www.arctic.org/~dgaudet/apache/1.3/">
-several performance patches available for 1.3.</a> But they may
+<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/">
+several performance patches available for 1.3.</A> But they may
be slightly out of date by the time Apache 1.3.0 has been released,
it shouldn't be difficult for someone with a little C knowledge to
update them. In particular:
-<ul>
-<li>A
-<a href="http://www.arctic.org/~dgaudet/apache/1.3/shared_time.patch">
-patch</a> to remove all <code>time(2)</code> system calls.
-<li>A
-<a href="http://www.arctic.org/~dgaudet/apache/1.3/mod_include_speedups.patch">
-patch</a> to remove various system calls from <code>mod_include</code>,
+<UL>
+<LI>A
+<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/shared_time.patch"
+>patch</A> to remove all <CODE>time(2)</CODE> system calls.
+<LI>A
+<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/mod_include_speedups.patch"
+>patch</A> to remove various system calls from <CODE>mod_include</CODE>,
these calls are used by few sites but required for backwards compatibility.
-<li>A
-<a href="http://www.arctic.org/~dgaudet/apache/1.3/top_fuel.patch">
-patch</a> which integrates the above two plus a few other speedups at the
+<LI>A
+<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/top_fuel.patch"
+>patch</A> which integrates the above two plus a few other speedups at the
cost of removing some functionality.
-</ul>
+</UL>
<H3>Appendix: The Pre-Forking Model</H3>
implementations of threaded Apache, one using the 1.3 code base on DCE,
and one using a custom user-level threads package and the 1.0 code base,
neither are available publically. There is also an experimental port of
-Apache 1.3 to <a href="http://www.mozilla.org/docs/refList/refNSPR/">
-Netscape's Portable Run Time</a>, which
-<a href="http://www.arctic.org/~dgaudet/apache/2.0/">is available</a>
+Apache 1.3 to <A HREF="http://www.mozilla.org/docs/refList/refNSPR/">
+Netscape's Portable Run Time</A>, which
+<A HREF="http://www.arctic.org/~dgaudet/apache/2.0/">is available</A>
(but you're encouraged to join the
-<a href="http://dev.apache.org/mailing-lists">new-httpd mailing list</a>
+<A HREF="http://dev.apache.org/mailing-lists">new-httpd mailing list</A>
if you intend to use it).
Part of our redesign for version 2.0
of Apache will include abstractions of the server model so that we
<HR>
-<H2><A name="serverroot">Permissions on ServerRoot Directories</A></H2>
+<H2><A NAME="serverroot">Permissions on ServerRoot Directories</A></H2>
<P>In typical operation, Apache is started by the root
user, and it switches to the user defined by the <A
HREF="../mod/core.html#user"><STRONG>User</STRONG></A> directive to serve hits.
<HR>
<H2>Non Script Aliased CGI</H2>
-<P>Allowing users to execute <STRONG>CGI</STRONG> scripts in any directory should only
+<P>Allowing users to execute <STRONG>CGI</STRONG> scripts in any directory
+should only
be considered if;
<OL>
<LI>You trust your users not to write scripts which will deliberately or
<HR>
<H2>Script Alias'ed CGI</H2>
-<P>Limiting <STRONG>CGI</STRONG> to special directories gives the admin control over
+<P>Limiting <STRONG>CGI</STRONG> to special directories gives the admin
+control over
what goes into those directories. This is inevitably more secure than
non script aliased CGI, but <STRONG>only if users with write access to the
directories are trusted</STRONG> or the admin is willing to test each new CGI
</A>
<H1 ALIGN="CENTER">Running a High-Performance Web Server for BSD</H1>
-Like other OS's, the listen queue is often the <STRONG>first limit hit</STRONG>. The
+Like other OS's, the listen queue is often the <STRONG>first limit
+hit</STRONG>. The
following are comments from "Aaron Gifford <agifford@InfoWest.COM>"
on how to fix this on BSDI 1.x, 2.x, and FreeBSD 2.0 (and earlier):
<P>
Be aware that your system may not boot with a kernel that is configured
-to use more resources than you have available system RAM. <STRONG>ALWAYS</STRONG>
+to use more resources than you have available system RAM.
+<STRONG>ALWAYS</STRONG>
have a known bootable kernel available when tuning your system this way,
and use the system tools beforehand to learn if you need to buy more
memory before tuning.
<P>
For versions of Apache later than 1.0.5 you'll need to change the
-definition for <STRONG>HARD_SERVER_LIMIT</STRONG> in <EM>httpd.h</EM> and recompile
-if you need to run more than the default 150 instances of httpd.
+definition for <STRONG>HARD_SERVER_LIMIT</STRONG> in <EM>httpd.h</EM> and
+recompile if you need to run more than the default 150 instances of httpd.
<P>
<H3>More welcome!</H3>
-If you have tips to contribute, send mail to <A
-HREF="mailto:brian@organic.com">brian@organic.com</A>
+If you have tips to contribute, send mail to
+<A HREF="mailto:brian@organic.com">brian@organic.com</A>
<!--#include virtual="footer.html" -->
</BODY></HTML>
Organization DEC Western Research
Date 30 May 1996 00:50:25 GMT
Newsgroups <A HREF="news:comp.unix.osf.osf1">comp.unix.osf.osf1</A>
-Message-ID <A HREF="news:4oirch$bc8@usenet.pa.dec.com"><4oirch$bc8@usenet.pa.dec.com></A>
+Message-ID <4oirch$bc8@usenet.pa.dec.com>
Subject Re: Web Site Performance
References 1
>runing DEC UNIX 3.2C, which run DEC's seal firewall and behind
>that Alpha 1000 and 2100 webservers.
-Our experience (running such Web servers as <A HREF="http://altavista.digital.com">altavista.digital.com</A>
-and <A HREF="http://www.digital.com">www.digital.com</A>) is that there is one important kernel tuning
+Our experience (running such Web servers as <A
+ HREF="http://altavista.digital.com">altavista.digital.com</A>
+and <A HREF="http://www.digital.com"
+ >www.digital.com</A>) is that there is one important kernel tuning
knob to adjust in order to get good performance on V3.2C. You
need to patch the kernel global variable "somaxconn" (use dbx -k
to do this) from its default value of 8 to something much larger.
level.
We have some Webstone performance results available at
- <A HREF="http://www.digital.com/info/alphaserver/news/webff.html">http://www.digital.com/info/alphaserver/news/webff.html</A>
+ <A HREF="http://www.digital.com/info/alphaserver/news/webff.html"
+ >http://www.digital.com/info/alphaserver/news/webff.html</A>
I'm not sure if these were done using V4.0 or an earlier version
of Digital UNIX, although I suspect they were done using a test
version of V4.0.
Organization DEC Western Research
Date 31 May 1996 21:01:01 GMT
Newsgroups <A HREF="news:comp.unix.osf.osf1">comp.unix.osf.osf1</A>
-Message-ID <A HREF="news:4onmmd$mmd@usenet.pa.dec.com"><4onmmd$mmd@usenet.pa.dec.com></A>
+Message-ID <4onmmd$mmd@usenet.pa.dec.com>
Subject Digital UNIX V3.2C Internet tuning patch info
----------------------------------------------------------------------------
file might be useful to people running V4.0 systems.
This patch kit does not appear to be available (yet?) from
- <A HREF="http://www.service.digital.com/html/patch_service.html">http://www.service.digital.com/html/patch_service.html</A>
+ <A HREF="http://www.service.digital.com/html/patch_service.html"
+ >http://www.service.digital.com/html/patch_service.html</A>
so I guess you'll have to call Digital's Customer Support to get it.
-Jeff
V3.2C
Feature V3.2C patch V4.0
- ======= ===== ===== ====
+======= ===== ===== ====
somaxconn X X X
sominconn - X X
sobacklog_hiwat - X -
<A HREF="http://www.sco.com">http://www.sco.com</A>
for UnixWare patch information.<P>
-<STRONG>NOTE:</STRONG> Unixware 2.1.2 and later already have patch ptf3123 included<P>
+<STRONG>NOTE:</STRONG> Unixware 2.1.2 and later already have patch ptf3123
+included<P>
In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not
defined by Apache autoconfiguration). To reduce instances of connections
<HR>
-<H2><A name="req">Requirements</A></H2>
+<H2><A NAME="req">Requirements</A></H2>
<P>Apache 1.3b6 requires the following:</P>
requirements unknown) with a connection to a TCP/IP network.
</UL>
-<P><SMALL><A name="351">*</A> Apache may run with Windows NT 3.5.1, but
+<P><SMALL><A NAME="351">*</A> Apache may run with Windows NT 3.5.1, but
has not been tested.</SMALL></P>
<P>If running on Windows 95, using the "Winsock2" upgrade is recommended
but may not be necessary. If running on NT 4.0, installing Service Pack 2
is recommended.</P>
-<H2><A name="down">Downloading Apache for Windows</A></H2>
+<H2><A NAME="down">Downloading Apache for Windows</A></H2>
<P>Information on the latest version of Apache can be found on the
Apache web server at <A
ready to install and run. There may also be a <CODE>.zip</CODE> file
containing the source code, to compile Apache yourself.
-<H2><A name="inst">Installing Apache for Windows</A></H2>
+<H2><A NAME="inst">Installing Apache for Windows</A></H2>
Run the Apache <SAMP>.exe</SAMP> file you downloaded above. This will
ask for:
which should be set before you start really using Apache. However to
get started the files should work as installed.
-<H2><A name="inst">Running Apache for Windows</A></H2>
+<H2><A NAME="inst">Running Apache for Windows</A></H2>
There are two ways you can run Apache:
Once your basic installation is working, you should configure it
properly by editing the files in the <SAMP>conf</SAMP> directory.
-<H2><A name="use">Configuring Apache for Windows</A></H2>
+<H2><A NAME="use">Configuring Apache for Windows</A></H2>
Apache is configured by files in the <SAMP>conf</SAMP>
directory. These are the same as files used to configure the Unix
is available.</A>
</UL>
-<H2><A name="cmdline">Running Apache for Windows from the Command Line</A></H2>
+<H2><A NAME="cmdline">Running Apache for Windows from the Command Line</A></H2>
The Start menu icons and the NT Service manager can provide an simple
interafce for administering Apache. But in some cases it is easier to
given on the <SAMP>ServerRoot</SAMP> directive line instead of the -f
or -d command line argument.
-<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
<P>To install the files into the <CODE>\Apache</CODE> directory
automatically, use one the following nmake commands (see above):</P>
<UL>
-<LI><CODE>nmake /f Makefile.nt installr INSTDIR=<i>dir</i></CODE> (for release build)
-<LI><CODE>nmake /f Makefile.nt installd INSTDIR=<i>dir</i></CODE> (for debug build)
+<LI><CODE>nmake /f Makefile.nt installr INSTDIR=<EM>dir</EM></CODE>
+ (for release build)
+<LI><CODE>nmake /f Makefile.nt installd INSTDIR=<EM>dir</EM></CODE>
+ (for debug build)
</UL>
The dir argument to INSTDIR gives the installation directory. The can
<P>This will install the following:</P>
<UL>
- <LI><CODE><i>dir</i>\Apache.exe</CODE> - Apache executable
- <LI><CODE><i>dir</i>\ApacheCore.dll</CODE> - Main Apache shared library
- <LI><CODE><i>dir</i>\modules\ApacheModule*.dll</CODE> - Optional Apache
+ <LI><CODE><EM>dir</EM>\Apache.exe</CODE> - Apache executable
+ <LI><CODE><EM>dir</EM>\ApacheCore.dll</CODE> - Main Apache shared library
+ <LI><CODE><EM>dir</EM>\modules\ApacheModule*.dll</CODE> - Optional Apache
modules (7 files)
- <LI><CODE><i>dir</i>\conf</CODE> - Empty configuration directory
- <LI><CODE><i>dir</i>\logs</CODE> - Empty logging directory
+ <LI><CODE><EM>dir</EM>\conf</CODE> - Empty configuration directory
+ <LI><CODE><EM>dir</EM>\logs</CODE> - Empty logging directory
</UL>
<P>If you do not have nmake, or wish to install in a different directory,
</LI>
- <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done simultaneously
+ <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done
+ simultaneously
</LI>
- <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done simultaneously
+ <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done
+ simultaneously
</LI>
</OL>
</LI>
- <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done simultaneously
+ <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done
+ simultaneously
</LI>
- <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done simultaneously
+ <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done
+ simultaneously
</LI>
</OL>
<A HREF="mod/core.html#serverroot">ServerRoot</A> and
<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-<p>As of Apache 1.3 we provide a script <code>src/support/apachectl</code>
+<P>As of Apache 1.3 we provide a script <CODE>src/support/apachectl</CODE>
which can be used to start, stop, and restart Apache. It may need a
little customization for your system, see the comments at the top of
the script.
will notice that the server statistics are
set to zero when a <CODE>HUP</CODE> is sent.
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a
+<P><STRONG>Note:</STRONG> If your configuration file has errors in it when
+you issue a
restart then your parent will not restart, it will exit with an error.
See below for a method of avoiding this.
<H3>USR1 Signal: graceful restart</H3>
-<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and
-shouldn't be used at all.
+<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable
+and shouldn't be used at all.
<P>The <CODE>USR1</CODE> signal causes the parent process to <EM>advise</EM>
the children to exit after their current request (or to exit immediately
<P>Users of the
<A HREF="mod/mod_status.html">status module</A>
will notice that the server statistics
-are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The code
+are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The
+code
was written to both minimize the time in which the server is unable to serve
new requests (they will be queued up by the operating system, so they're
not lost in any event) and to respect your tuning parameters. In order
complete for users on low bandwidth links then you could wait 15 minutes
before doing anything with the old log.
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a
+<P><STRONG>Note:</STRONG> If your configuration file has errors in it when
+you issue a
restart then your parent will not restart, it will exit with an error.
In the case of graceful
restarts it will also leave children running when it exits. (These are
<A HREF="mod/core.html#serverroot">ServerRoot</A> and
<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-<p>As of Apache 1.3 we provide a script <code>src/support/apachectl</code>
+<P>As of Apache 1.3 we provide a script <CODE>src/support/apachectl</CODE>
which can be used to start, stop, and restart Apache. It may need a
little customization for your system, see the comments at the top of
the script.
will notice that the server statistics are
set to zero when a <CODE>HUP</CODE> is sent.
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a
+<P><STRONG>Note:</STRONG> If your configuration file has errors in it when
+you issue a
restart then your parent will not restart, it will exit with an error.
See below for a method of avoiding this.
<H3>USR1 Signal: graceful restart</H3>
-<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and
-shouldn't be used at all.
+<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable
+and shouldn't be used at all.
<P>The <CODE>USR1</CODE> signal causes the parent process to <EM>advise</EM>
the children to exit after their current request (or to exit immediately
<P>Users of the
<A HREF="mod/mod_status.html">status module</A>
will notice that the server statistics
-are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The code
+are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The
+code
was written to both minimize the time in which the server is unable to serve
new requests (they will be queued up by the operating system, so they're
not lost in any event) and to respect your tuning parameters. In order
complete for users on low bandwidth links then you could wait 15 minutes
before doing anything with the old log.
-<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a
+<P><STRONG>Note:</STRONG> If your configuration file has errors in it when
+you issue a
restart then your parent will not restart, it will exit with an error.
In the case of graceful
restarts it will also leave children running when it exits. (These are
<P ALIGN="LEFT">
Third, it is assumed that you are using an <STRONG>unmodified</STRONG>
version of suEXEC code. All code for suEXEC has been carefully scrutinized and
-tested by the developers as well as numerous beta testers. Every precaution has
-been taken to ensure a simple yet solidly safe base of code. Altering this
+tested by the developers as well as numerous beta testers. Every precaution
+has been taken to ensure a simple yet solidly safe base of code. Altering this
code can cause unexpected problems and new security risks. It is
<STRONG>highly</STRONG> recommended you not alter the suEXEC code unless you
are well versed in the particulars of security programming and are willing to
The wrapper then employs the following process to determine success or
failure -- if any one of these conditions fail, the program logs the failure
and exits with an error, otherwise it will continue:
- <OL>
- <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG>
- <BLOCKQUOTE>
- The wrapper will only execute if it is given the proper number of arguments.
- The proper argument format is known to the Apache web server. If the wrapper
- is not receiving the proper number of arguments, it is either being hacked, or
- there is something wrong with the suEXEC portion of your Apache binary.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG>
- <BLOCKQUOTE>
- This is to ensure that the user executing the wrapper is truly a user of the system.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
- <BLOCKQUOTE>
- Is this user the user allowed to run this wrapper? Only one user (the Apache
- user) is allowed to execute this program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG>
- <BLOCKQUOTE>
- Does the target program contain a leading '/' or have a '..' backreference? These
- are not allowed; the target program must reside within the Apache webspace.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target user exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target group exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum user ID number is specified during configuration. This allows you
- to set the lowest possible userid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" accounts.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum group ID number is specified during configuration. This allows you
- to set the lowest possible groupid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" groups.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG>
- <BLOCKQUOTE>
- Here is where the program becomes the target user and group via setuid and setgid
- calls. The group access list is also initialized with all of the groups of which
- the user is a member.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exist, it can't very well contain files.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
- <BLOCKQUOTE>
- If the request is for a regular portion of the server, is the requested directory
- within the server's document root? If the request is for a UserDir, is the requested
- directory within the user's document root?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to open up the directory to others; only the owner user may be able
- to alter this directories contents.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exists, it can't very well be executed.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to give anyone other than the owner the ability to change the program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
- <BLOCKQUOTE>
- We do not want to execute programs that will then change our UID/GID again.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG>
- <BLOCKQUOTE>
- Is the user the owner of the file?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG>
- <BLOCKQUOTE>
- suEXEC cleans the process' environment by establishing a safe execution PATH (defined
- during configuration), as well as only passing through those variables whose names
- are listed in the safe environment list (also created during configuration).
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully become the target program and execute?</STRONG>
- <BLOCKQUOTE>
- Here is where suEXEC ends and the target program begins.
- </BLOCKQUOTE>
- </LI>
- </OL>
+<OL>
+ <LI><STRONG>Was the wrapper called with the proper number of
+ arguments?</STRONG>
+ <BLOCKQUOTE>
+ The wrapper will only execute if it is given the proper number of arguments.
+ The proper argument format is known to the Apache web server. If the
+ wrapper
+ is not receiving the proper number of arguments, it is either being hacked,
+ or
+ there is something wrong with the suEXEC portion of your Apache binary.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the user executing this wrapper a valid user of this
+ system?</STRONG>
+ <BLOCKQUOTE>
+ This is to ensure that the user executing the wrapper is truly a user of the
+ system.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
+ <BLOCKQUOTE>
+ Is this user the user allowed to run this wrapper? Only one user (the
+ Apache user) is allowed to execute this program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program have an unsafe hierarchical
+ reference?</STRONG>
+ <BLOCKQUOTE>
+ Does the target program contain a leading '/' or have a '..' backreference?
+ These are not allowed; the target program must reside within the Apache
+ webspace.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user name valid?</STRONG>
+ <BLOCKQUOTE>
+ Does the target user exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group name valid?</STRONG>
+ <BLOCKQUOTE>
+ Does the target group exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
+ <BLOCKQUOTE>
+ Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID
+ number?</STRONG>
+ <BLOCKQUOTE>
+ The minimum user ID number is specified during configuration. This allows
+ you
+ to set the lowest possible userid that will be allowed to execute CGI/SSI
+ programs. This is useful to block out "system" accounts.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
+ <BLOCKQUOTE>
+ Presently, suEXEC does not allow the 'root' group to execute CGI/SSI
+ programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID
+ number?</STRONG>
+ <BLOCKQUOTE>
+ The minimum group ID number is specified during configuration. This allows
+ you
+ to set the lowest possible groupid that will be allowed to execute CGI/SSI
+ programs. This is useful to block out "system" groups.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can the wrapper successfully become the target user and
+ group?</STRONG>
+ <BLOCKQUOTE>
+ Here is where the program becomes the target user and group via setuid and
+ setgid
+ calls. The group access list is also initialized with all of the groups
+ of which
+ the user is a member.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
+ <BLOCKQUOTE>
+ If it doesn't exist, it can't very well contain files.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
+ <BLOCKQUOTE>
+ If the request is for a regular portion of the server, is the requested
+ directory
+ within the server's document root? If the request is for a UserDir, is
+ the requested
+ directory within the user's document root?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
+ <BLOCKQUOTE>
+ We don't want to open up the directory to others; only the owner user
+ may be able
+ to alter this directories contents.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program exist?</STRONG>
+ <BLOCKQUOTE>
+ If it doesn't exists, it can't very well be executed.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone
+ else?</STRONG>
+ <BLOCKQUOTE>
+ We don't want to give anyone other than the owner the ability to
+ change the program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
+ <BLOCKQUOTE>
+ We do not want to execute programs that will then change our UID/GID again.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user/group the same as the program's
+ user/group?</STRONG>
+ <BLOCKQUOTE>
+ Is the user the owner of the file?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully clean the process environment to
+ ensure safe operations?</STRONG>
+ <BLOCKQUOTE>
+ suEXEC cleans the process' environment by establishing a safe
+ execution PATH (defined
+ during configuration), as well as only passing through those
+ variables whose names
+ are listed in the safe environment list (also created during
+ configuration).
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully become the target program and
+ execute?</STRONG>
+ <BLOCKQUOTE>
+ Here is where suEXEC ends and the target program begins.
+ </BLOCKQUOTE>
+ </LI>
+</OL>
</P>
<P ALIGN="LEFT">
<P ALIGN="LEFT">
For more information as to how this security model can limit your possibilities
-in regards to server configuration, as well as what security risks can be avoided
-with a proper suEXEC setup, see the <A HREF="#beware">"Beware the Jabberwock"</A>
+in regards to server configuration, as well as what security risks can be
+avoided with a proper suEXEC setup, see the
+<A HREF="#beware">"Beware the Jabberwock"</A>
section of this document.
</P>
</P>
<P ALIGN="LEFT">
-<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG><BR>
+<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG>
+<BR>
<STRONG><CODE>chmod 4711 /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG>
</P>
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3>
+<H3>
+<A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A>
+</H3>
<P ALIGN="LEFT">
<STRONG>NOTE!</STRONG> This section may not be complete. For the latest
revision of this section of the documentation, see the Apache Group's
<P ALIGN="LEFT">
Third, it is assumed that you are using an <STRONG>unmodified</STRONG>
version of suEXEC code. All code for suEXEC has been carefully scrutinized and
-tested by the developers as well as numerous beta testers. Every precaution has
-been taken to ensure a simple yet solidly safe base of code. Altering this
+tested by the developers as well as numerous beta testers. Every precaution
+has been taken to ensure a simple yet solidly safe base of code. Altering this
code can cause unexpected problems and new security risks. It is
<STRONG>highly</STRONG> recommended you not alter the suEXEC code unless you
are well versed in the particulars of security programming and are willing to
The wrapper then employs the following process to determine success or
failure -- if any one of these conditions fail, the program logs the failure
and exits with an error, otherwise it will continue:
- <OL>
- <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG>
- <BLOCKQUOTE>
- The wrapper will only execute if it is given the proper number of arguments.
- The proper argument format is known to the Apache web server. If the wrapper
- is not receiving the proper number of arguments, it is either being hacked, or
- there is something wrong with the suEXEC portion of your Apache binary.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG>
- <BLOCKQUOTE>
- This is to ensure that the user executing the wrapper is truly a user of the system.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
- <BLOCKQUOTE>
- Is this user the user allowed to run this wrapper? Only one user (the Apache
- user) is allowed to execute this program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG>
- <BLOCKQUOTE>
- Does the target program contain a leading '/' or have a '..' backreference? These
- are not allowed; the target program must reside within the Apache webspace.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target user exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target group exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum user ID number is specified during configuration. This allows you
- to set the lowest possible userid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" accounts.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum group ID number is specified during configuration. This allows you
- to set the lowest possible groupid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" groups.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG>
- <BLOCKQUOTE>
- Here is where the program becomes the target user and group via setuid and setgid
- calls. The group access list is also initialized with all of the groups of which
- the user is a member.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exist, it can't very well contain files.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
- <BLOCKQUOTE>
- If the request is for a regular portion of the server, is the requested directory
- within the server's document root? If the request is for a UserDir, is the requested
- directory within the user's document root?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to open up the directory to others; only the owner user may be able
- to alter this directories contents.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exists, it can't very well be executed.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to give anyone other than the owner the ability to change the program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
- <BLOCKQUOTE>
- We do not want to execute programs that will then change our UID/GID again.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG>
- <BLOCKQUOTE>
- Is the user the owner of the file?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG>
- <BLOCKQUOTE>
- suEXEC cleans the process' environment by establishing a safe execution PATH (defined
- during configuration), as well as only passing through those variables whose names
- are listed in the safe environment list (also created during configuration).
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully become the target program and execute?</STRONG>
- <BLOCKQUOTE>
- Here is where suEXEC ends and the target program begins.
- </BLOCKQUOTE>
- </LI>
- </OL>
+<OL>
+ <LI><STRONG>Was the wrapper called with the proper number of
+ arguments?</STRONG>
+ <BLOCKQUOTE>
+ The wrapper will only execute if it is given the proper number of arguments.
+ The proper argument format is known to the Apache web server. If the
+ wrapper
+ is not receiving the proper number of arguments, it is either being hacked,
+ or
+ there is something wrong with the suEXEC portion of your Apache binary.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the user executing this wrapper a valid user of this
+ system?</STRONG>
+ <BLOCKQUOTE>
+ This is to ensure that the user executing the wrapper is truly a user of the
+ system.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
+ <BLOCKQUOTE>
+ Is this user the user allowed to run this wrapper? Only one user (the
+ Apache user) is allowed to execute this program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program have an unsafe hierarchical
+ reference?</STRONG>
+ <BLOCKQUOTE>
+ Does the target program contain a leading '/' or have a '..' backreference?
+ These are not allowed; the target program must reside within the Apache
+ webspace.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user name valid?</STRONG>
+ <BLOCKQUOTE>
+ Does the target user exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group name valid?</STRONG>
+ <BLOCKQUOTE>
+ Does the target group exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
+ <BLOCKQUOTE>
+ Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID
+ number?</STRONG>
+ <BLOCKQUOTE>
+ The minimum user ID number is specified during configuration. This allows
+ you
+ to set the lowest possible userid that will be allowed to execute CGI/SSI
+ programs. This is useful to block out "system" accounts.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
+ <BLOCKQUOTE>
+ Presently, suEXEC does not allow the 'root' group to execute CGI/SSI
+ programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID
+ number?</STRONG>
+ <BLOCKQUOTE>
+ The minimum group ID number is specified during configuration. This allows
+ you
+ to set the lowest possible groupid that will be allowed to execute CGI/SSI
+ programs. This is useful to block out "system" groups.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can the wrapper successfully become the target user and
+ group?</STRONG>
+ <BLOCKQUOTE>
+ Here is where the program becomes the target user and group via setuid and
+ setgid
+ calls. The group access list is also initialized with all of the groups
+ of which
+ the user is a member.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
+ <BLOCKQUOTE>
+ If it doesn't exist, it can't very well contain files.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
+ <BLOCKQUOTE>
+ If the request is for a regular portion of the server, is the requested
+ directory
+ within the server's document root? If the request is for a UserDir, is
+ the requested
+ directory within the user's document root?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
+ <BLOCKQUOTE>
+ We don't want to open up the directory to others; only the owner user
+ may be able
+ to alter this directories contents.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program exist?</STRONG>
+ <BLOCKQUOTE>
+ If it doesn't exists, it can't very well be executed.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone
+ else?</STRONG>
+ <BLOCKQUOTE>
+ We don't want to give anyone other than the owner the ability to
+ change the program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
+ <BLOCKQUOTE>
+ We do not want to execute programs that will then change our UID/GID again.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user/group the same as the program's
+ user/group?</STRONG>
+ <BLOCKQUOTE>
+ Is the user the owner of the file?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully clean the process environment to
+ ensure safe operations?</STRONG>
+ <BLOCKQUOTE>
+ suEXEC cleans the process' environment by establishing a safe
+ execution PATH (defined
+ during configuration), as well as only passing through those
+ variables whose names
+ are listed in the safe environment list (also created during
+ configuration).
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully become the target program and
+ execute?</STRONG>
+ <BLOCKQUOTE>
+ Here is where suEXEC ends and the target program begins.
+ </BLOCKQUOTE>
+ </LI>
+</OL>
</P>
<P ALIGN="LEFT">
<P ALIGN="LEFT">
For more information as to how this security model can limit your possibilities
-in regards to server configuration, as well as what security risks can be avoided
-with a proper suEXEC setup, see the <A HREF="#beware">"Beware the Jabberwock"</A>
+in regards to server configuration, as well as what security risks can be
+avoided with a proper suEXEC setup, see the
+<A HREF="#beware">"Beware the Jabberwock"</A>
section of this document.
</P>
</P>
<P ALIGN="LEFT">
-<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG><BR>
+<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG>
+<BR>
<STRONG><CODE>chmod 4711 /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG>
</P>
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3>
+<H3>
+<A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A>
+</H3>
<P ALIGN="LEFT">
<STRONG>NOTE!</STRONG> This section may not be complete. For the latest
revision of this section of the documentation, see the Apache Group's
<!--#include virtual="header.html" -->
<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>.
+<P>The virtual host code was completely rewritten in
+<STRONG>Apache 1.3</STRONG>.
This document attempts to explain exactly what Apache does when
deciding what virtual host to serve a hit from. With the help of the
new <A HREF="../mod/core.html#namevirtualhost"><SAMP>NameVirtualHost</SAMP></A>
<P>The complete list of names in the <CODE>VirtualHost</CODE> directive
are treated just like a <CODE>ServerAlias</CODE> (but are not overridden by any
-<CODE>ServerAlias</CODE> statement) if all names resolve to the same address set.
-Note that subsequent <CODE>Port</CODE> statements for this vhost will not affect
-the ports assigned in the address set.
+<CODE>ServerAlias</CODE> statement) if all names resolve to the same address
+set. Note that subsequent <CODE>Port</CODE> statements for this vhost will not
+affect the ports assigned in the address set.
<P>During initialization a list for each IP address
is generated an inserted into an hash table. If the IP address is
<A HREF="../mod/core.html#resourceconfig"><CODE>ResourceConfig</CODE></A>,
<A HREF="../mod/core.html#accessconfig"><CODE>AccessConfig</CODE></A>,
<A HREF="../mod/core.html#timeout"><CODE>Timeout</CODE></A>,
- <A HREF="../mod/core.html#keepalivetimeout"><CODE>KeepAliveTimeout</CODE></A>,
+ <A HREF="../mod/core.html#keepalivetimeout"
+ ><CODE>KeepAliveTimeout</CODE></A>,
<A HREF="../mod/core.html#keepalive"><CODE>KeepAlive</CODE></A>,
- <A HREF="../mod/core.html#maxkeepaliverequests"><CODE>MaxKeepAliveRequests</CODE></A>,
+ <A HREF="../mod/core.html#maxkeepaliverequests"
+ ><CODE>MaxKeepAliveRequests</CODE></A>,
or
<A HREF="../mod/core.html#sendbuffersize"><CODE>SendBufferSize</CODE></A>
directive then the respective value is
<P>The first vhost on this list (the first vhost in the config file with
the specified IP address) has the highest priority and catches any request
to an unknown server name or a request without a <CODE>Host:</CODE>
-header.
+header field.
-<P>If the client provided a <CODE>Host:</CODE> header the list is
+<P>If the client provided a <CODE>Host:</CODE> header field the list is
searched for a matching vhost and the first hit on a <CODE>ServerName</CODE>
or <CODE>ServerAlias</CODE> is taken and the request is served from
-that vhost. A <CODE>Host:</CODE> header can contain a port number, but
+that vhost. A <CODE>Host:</CODE> header field can contain a port number, but
Apache always matches against the real port to which the client sent
the request.
<P>If the client submitted a HTTP/1.0 request without <CODE>Host:</CODE>
-header we don't know to what server the client tried to connect and
+header field we don't know to what server the client tried to connect and
any existing <CODE>ServerPath</CODE> is matched against the URI
from the request. The first matching path on the list is used and the
request is served from that vhost.
<P>
<LI>For security reasons the port number given in a <CODE>Host:</CODE>
- header is never used during the matching process. Apache always
+ header field is never used during the matching process. Apache always
uses the real port to which the client sent the request.
<P>
another <CODE>ServerPath</CODE> directive that appears later in
the configuration file, then the former will always be matched
and the latter will never be matched. (That is assuming that no
- Host header was available to disambiguate the two.)
+ <CODE>Host:</CODE> header field was available to disambiguate the two.)
<P>
<LI>If two IP-based vhosts have an address in common, the vhost appearing
and port number to which the client connected is unspecified
and does not match any other vhost (including a <CODE>_default_</CODE>
vhost). In other words the main_server only catches a request for an
- unspecified address/port combination (unless there is a <CODE>_default_</CODE>
- vhost which matches that port).
+ unspecified address/port combination (unless there is a
+ <CODE>_default_</CODE> vhost which matches that port).
<P>
<LI>A <CODE>_default_</CODE> vhost or the main_server is <EM>never</EM>
matched for a request with an unknown or missing <CODE>Host:</CODE> header
- if the client connected to an address (and port) which is used
+ field if the client connected to an address (and port) which is used
for name-based vhosts, e.g. in a <CODE>NameVirtualHost</CODE> directive.
<P>
</UL>
-<H3><A name="whatworks">What Works</A></H3>
+<H3><A NAME="whatworks">What Works</A></H3>
<P>In addition to the tips on the <A HREF="dns-caveats.html#tips">DNS
Issues</A> page, here are some further tips:
<P>To continue the <CODE>www.apache.org</CODE> example (Note: Apache's
web server does not actually function in this manner), we might use the
-new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE> virtual host,
-for example:
+new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE>
+virtual host, for example:
<PRE>
ServerPath /apache
<LI><A HREF="../mod/core.html#serverpath">ServerPath</A>
</UL>
-<p>Folks trying to debug their virtual host configuration may find the
-Apache <code>-S</code> command line switch useful. It will dump out a
+<P>Folks trying to debug their virtual host configuration may find the
+Apache <CODE>-S</CODE> command line switch useful. It will dump out a
description of how Apache parsed the configuration file. Careful
examination of the IP addresses and server names may help uncover
configuration mistakes.
<LI><A HREF="../mod/core.html#serverpath">ServerPath</A>
</UL>
-<p>Folks trying to debug their virtual host configuration may find the
-Apache <code>-S</code> command line switch useful. It will dump out a
+<P>Folks trying to debug their virtual host configuration may find the
+Apache <CODE>-S</CODE> command line switch useful. It will dump out a
description of how Apache parsed the configuration file. Careful
examination of the IP addresses and server names may help uncover
configuration mistakes.
<SAMP>www.domain.tld</SAMP> points to the IP address
<SAMP>111.22.33.44</SAMP></P>
-<p>Note: When you specify an IP address in a <code>NameVirtualHost</code>
+<P>Note: When you specify an IP address in a <CODE>NameVirtualHost</CODE>
directive then requests to that IP address will only ever be served
-by matching <VirtualHost>s. The "main server" will <b>never</b>
+by matching <VirtualHost>s. The "main server" will <STRONG>never</STRONG>
be served from the specified IP address.
<P>Additionally, many servers may wish to be accessible by more than
<SAMP>www.domain.tld</SAMP> points to the IP address
<SAMP>111.22.33.44</SAMP></P>
-<p>Note: When you specify an IP address in a <code>NameVirtualHost</code>
+<P>Note: When you specify an IP address in a <CODE>NameVirtualHost</CODE>
directive then requests to that IP address will only ever be served
-by matching <VirtualHost>s. The "main server" will <b>never</b>
+by matching <VirtualHost>s. The "main server" will <STRONG>never</STRONG>
be served from the specified IP address.
<P>Additionally, many servers may wish to be accessible by more than
</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:
<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
+<A HREF="mod/core.html#bindaddress">BindAddress</A> directive in the
+configuration
file to select which IP address (or virtual host) that daemon services.
-e.g.
+<EM>E.g.</EM>,
<BLOCKQUOTE><CODE>BindAddress www.smallco.com</CODE></BLOCKQUOTE>
This hostname can also be given as an IP address.
<A HREF="mod/core.html#errorlog">ErrorLog</A> and
<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> configuration
directives to different values for each virtual host.
-e.g.
+<EM>E.g.</EM>,
<BLOCKQUOTE><CODE>
<VirtualHost www.smallco.com><BR>
ServerAdmin webmaster@mail.smallco.com<BR>
<OL>
<LI>Have a <CODE>csh</CODE> script wrapper around httpd which sets the
"rlimit" to some large number, like 512.
-<LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines of
+<LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines
+of
<PRE>
struct rlimit rlp;
projects / apache / commitdiff