You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by cr...@apache.org on 2001/03/21 02:59:21 UTC
cvs commit: jakarta-tomcat-4.0/catalina/docs/config logger.html realm.html valve.html context.html engine.html host.html
craigmcc 01/03/20 17:59:21
Modified: catalina/docs/config context.html engine.html host.html
Added: catalina/docs/config logger.html realm.html valve.html
Log:
Flesh out configuration documents for the Logger, Realm, and Valve
utility components. Several more need to be finished before the
configuration document can be considered complete.
Revision Changes Path
1.4 +4 -2 jakarta-tomcat-4.0/catalina/docs/config/context.html
Index: context.html
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/context.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- context.html 2001/02/26 03:48:59 1.3
+++ context.html 2001/03/21 01:59:18 1.4
@@ -338,11 +338,13 @@
</pre>
-<p>See <a href="valve.html#RequestFilterValve">Request Filter Valve</a> for
-more information on the syntax of the filters, and the logic that is applied
+<p>See <a href="valve.html#RemoteAddressFilter">Remote Address Filter</a> or
+<a href="valve.html#RemoteHostFilter">Remote Host Filter</a> for more
+information on the syntax of these filters, and the logic that is applied
when they are executed.</p>
<br>
+
</body>
</html>
1.3 +4 -2 jakarta-tomcat-4.0/catalina/docs/config/engine.html
Index: engine.html
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/engine.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- engine.html 2001/01/14 04:17:05 1.2
+++ engine.html 2001/03/21 01:59:19 1.3
@@ -203,11 +203,13 @@
</pre>
-<p>See <a href="valve.html#RequestFilterValve">Request Filter Valve</a> for
-more information on the syntax of the filters, and the logic that is applied
+<p>See <a href="valve.html#RemoteAddressFilter">Remote Address Filter</a> or
+<a href="valve.html#RemoteHostFilter">Remote Host Filter</a> for more
+information on the syntax of these filters, and the logic that is applied
when they are executed.</p>
<br>
+
</body>
</html>
1.4 +5 -2 jakarta-tomcat-4.0/catalina/docs/config/host.html
Index: host.html
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/host.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- host.html 2001/01/27 00:21:38 1.3
+++ host.html 2001/03/21 01:59:19 1.4
@@ -284,10 +284,12 @@
</pre>
-<p>See <a href="valve.html#RequestFilterValve">Request Filter Valve</a> for
-more information on the syntax of the filters, and the logic that is applied
+<p>See <a href="valve.html#RemoteAddressFilter">Remote Address Filter</a> or
+<a href="valve.html#RemoteHostFilter">Remote Host Filter</a> for more
+information on the syntax of these filters, and the logic that is applied
when they are executed.</p>
+
<h3>User Web Applications</h3>
<p>Many web servers automtically map a request path starting with a
@@ -344,6 +346,7 @@
and all directories above it, for this feature to operate correctly.</p>
<br>
+
</body>
</html>
1.1 jakarta-tomcat-4.0/catalina/docs/config/logger.html
Index: logger.html
===================================================================
<html>
<head>
<title>The 'Logger' Component</title>
</head>
<body bgcolor="white">
<div align="center">
<h1>The <u>Logger</u> Component</h1>
<br>
<a href="#Introduction">[Introduction]</a>
<a href="#Common Attributes">[Common Attributes]</a>
<a href="#Standard Implementation Attributes">[Standard Implementation Attributes]</a>
<br>
</div>
<a name="Introduction"></a>
<h2>Introduction</h2>
<p>A <strong>Logger</strong> component represents a mechanism by which event,
error, and debugging information from a Catalina component, or group of such
components, can be directed to a common destination. Each Logger is
associated with a <strong>Container</strong>, by being nested inside the
corresponding <code><Engine></code>, <code><Host></code>, or
<code><Context></code> element for that Container.</p>
<p>If you attach a <strong>Logger</strong> to an outer Container (such as an
<strong>Engine</strong>, that logger will be used for all nested Containers
(<strong>Host</strong> and <strong>Context</strong> components), unless you
specifically nest a different logger inside the nested Container.</p>
<br>
<a name="Common Attributes"></a>
<h2>Common Attributes</h2>
<p>All implementations of the <strong>Logger</strong> component support the
following attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td><code>className</code></td>
<td>Java class name of the implementation to use. This class must
implement the <code>org.apache.catalina.Logger</code> interface.
Because there is no single standard implementation, this attribute
is required. See <a href="#Standard Implementation Attributes">
Standard Implementation Attributes</a> for the names of the
supported classes.
</td>
</tr>
<tr>
<td><code>verbosity</code></td>
<td>The verbosity level for this logger. Messages with a higher
verbosity than the specified level will be silently ignored.
Available levels are 0 (fatal messages only), 1 (errors),
2 (warnings), 3 (information), and 4 (debug). If not specified,
the default value is 1 (error). Note that messages logged with
no verbosity parameter are logged unconditionally.
</tr>
</table>
<br>
<a name="Standard Implementation Attributes"></a>
<h2>Standard Implementation Attributes</h2>
<p>Unlike most other Catalina components, there is not a single standard
implementation of the <strong>Logger</strong> component available. Instead,
a variety of standard implementations are available for your use. To select
one, use the specified value for the <code>className</code> attribute, and
configure the remaining attributes as described below.</p>
<a name="FileLogger"></a>
<h3>File Logger (<code>org.apache.catalina.logger.FileLogger</code>)</h3>
<p>The <strong>File Logger</strong> records all logged messages (other than
those ignored based on verbosity level) to disk file(s) in a specified
directory. The actual filenames of the log files are created from a
configured prefix, the current date in YYYY-MM-DD format, and a configured
suffix. At midnight each night, the next logged message causes a switch to
a new log file (based on the new date), without having to shut down Catalina
in order to switch logs.</p>
<p>The File Logger supports the following additional attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td><code>directory</code></td>
<td>Relative or absolute pathname of the directory into which log
files will be created. If a relative path is specified, it is
interpreted as relative to $CATALINA_HOME. If no directory is
specified, the default value is "logs" (relative to the
Catalina home directory).
</td>
</tr>
<tr>
<td><code>prefix</code></td>
<td>The prefix added to the front of each log file name. If not
specified, the default value is "catalina.". To specify no
prefix, use a zero-length string.
</td>
</tr>
<tr>
<td><code>suffix</code></td>
<td>The suffix added to the end of each log file name. If not
specified, the default value is ".log". To specify no suffix,
use a zero-length string.
</td>
</tr>
<tr>
<td><code>timestamp</code></td>
<td>Should log messages be date/time stamped? Set this value to
<code>true</code> or <code>false</code>. If not specified,
log messages will not be date/time stamped.
</td>
</tr>
</table>
<h3>Standard Error Logger (<code>org.apache.catalina.logger.SystemErrLogger</code>)</h3>
<p>The <strong>Standard Error Logger</strong> records all logged messages
(other than those ignored based on verbosity level) to whatever stream the
standard error output of Catalina is pointed at. The default Catalina startup
script points this at file <code>logs/catalina.out</code> relative to
$CATALINA_HOME. This Logger accepts no additional attributes.</p>
<h3>Standard Output Logger (<code>org.apache.catalina.logger.SystemOutLogger</code>)</h3>
<p>The <strong>Standard Output Logger</strong> records all logged messages
(other than those ignored based on verbosity level) to whatever stream the
standard output of Catalina is pointed at. The default Catalina startup
script points this at file <code>logs/catalina.out</code> relative to
$CATALINA_HOME. This Logger accepts no additional attributes.</p>
</body>
</html>
1.1 jakarta-tomcat-4.0/catalina/docs/config/realm.html
Index: realm.html
===================================================================
<html>
<head>
<title>The 'Realm' Component</title>
</head>
<body bgcolor="white">
<div align="center">
<h1>The <u>Realm</u> Component</h1>
<br>
<a href="#Introduction">[Introduction]</a>
<a href="#Common Attributes">[Common Attributes]</a>
<a href="#Standard Implementation Attributes">[Standard Implementation Attributes]</a>
<a href="#Special Features">[Special Features]</a>
<br>
</div>
<a name="Introduction"></a>
<h2>Introduction</h2>
<p>A <strong>Realm</strong> component represents a mechanism by which a
"database" of usernames, passwords, and their associated security roles can
be linked into Catalina, for the purpose of authenticating users and validating
security constraints. A variety of standard implementations is available,
or you can implement your own to customize Tomcat's behavior to utilize your
own security infrastructure.</p>
<p>If you attach a <strong>Realm</strong> to an outer Container (such as an
<strong>Engine</strong>, that Realm will be used for all nested Containers
(<strong>Host</strong> and <strong>Context</strong> components), unless you
specifically nest a different Realm inside the nested Container. If you are
using the Single Sign On capability (see <a href="#Special Features">Special
Features</a>), you <strong>must</strong> share a Realm at either the
Engine or Host level.</p>
<br>
<a name="Common Attributes"></a>
<h2>Common Attributes</h2>
<p>All implementations of the <strong>Realm</strong> component support the
following attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td><code>className</code></td>
<td>Java class name of the implementation to use. This class must
implement the <code>org.apache.catalina.Realm</code> interface.
Because there is no single standard implementation, this attribute
is required. See <a href="#Standard Implementation Attributes">
Standard Implementation Attributes</a> for the names of the
supported classes.
</td>
</tr>
</table>
<br>
<a name="Standard Implementation Attributes"></a>
<h2>Standard Implementation Attributes</h2>
<p>Unlike most other Catalina components, there is not a single standard
implementation of the <strong>Realm</strong> component available. Instead,
a variety of standard implementations are available for your use. To select
one, use the specified value for the <code>className</code> attribute, and
configure the remaining attributes as described below.</p>
<a name="JDBCRealm"></a>
<h3> JDBC Database Realm (<code>org.apache.catalina.realm.JDBCRealm</code>)</h3>
<p>The <strong>JDBC Database Realm</strong> connects Catalina to a relational
database, accessed through an appropriate JDBC driver, to perform lookups of
usernames, passwords, and their associated roles. Because the lookup is done
each time it is required, changes to the database will be immediately reflected
in the information used to authenticate new logins. A rich set of
configuration attributes lets you customize the database to which Catalina will
connect, as well as the names of relevant tables and columns within the
database that contains the information of interest.</p>
<p>The JDBC Database Realm supports the following additional attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td>connectionName</td>
<td>The database username to use when establishing the JDBC connection.
This attribute is required.
</td>
</tr>
<tr>
<td>connectionPassword</td>
<td>The database password to use when establishing the JDBC connection.
This attribute is required.
</tr>
<tr>
<td>connectionURL</td>
<td>The connection URL to be passed to the JDBC driver. This attribute
is required.
</td>
</tr>
<tr>
<td>digest</td>
<td>The name of the MessageDigest algorithm to be used to encode passwords
in the database, or a zero-length string for no encoding. If not
specified, no encoding is the default.
</td>
</tr>
<tr>
<td>driverName</td>
<td>The fully qualified Java class name of the JDBC driver to be used.
This attribute is required. (Note that the corresponding driver's
JAR file needs to be placed in the $CATALINA_HOME/server directory
in order to be accessible.
</td>
</tr>
<tr>
<td>roleNameCol</td>
<td>The name of the column, in the "user roles" table, which contains
the role name to be compared to. This attribute is required.
</td>
</tr>
<tr>
<td>userCredCol</td>
<td>The name of the column, in the "users" table, which contains the
user's credentials (i.e. password). This attribute is required.
</td>
</tr>
<tr>
<td>userNameCol</td>
<td>The name of the column, in the "users" and "user roles" tables,
which contains the username of the user being looked up. This
attribute is required.
</td>
</tr>
<tr>
<td>userRoleTable</td>
<td>The name of the table, in the associated database, containing the
"user roles" information. This attribute is required.
</td>
</tr>
<tr>
<td>userTable</td>
<td>The name of the table, in the associated database, containing the
"users" information. This attribute is required.
</td>
</tr>
</table>
<p>In order to be used by the JDBC Database Realm, your database must conform
to the following rules:</p>
<ul>
<li>It must be possible for Catalina to establish a JDBC connection to this
database, using the configuration parameters described above.
<li>The database must contain a table containing "users" information, which
must conform to the following rules:
<ul>
<li>There must be exactly one row for each valid user.</li>
<li>There must be a column, named by the <code>userNameCol</code>
attribute, that contains the username of the user represented
by this row.</li>
<li>There must be a column, named by the <code>userCredCol</code>
attribute, that contains the credentials (password) of the user
represented by this row.</li>
<li>The credentials must be encoded by the MessageDigest algorithm
configured by the <code>digest</code> attribute.
<li>There must be at most one row for any specific username value.</li>
</ul></li>
<li>The database must contain a table containing "user roles" information,
which must conform to the following rules:
<ul>
<li>There must be exactly one row for each valid role that is assigned
to a particular valid user.</li>
<li>There may be more than one row for each valid user, one for each
role assigned to that user.</li>
<li>A valid user may have zero rows in this table, if that user is not
assigned to any roles.</li>
<li>There must be a column, named by the <code>userNameCol</code>
attribute, that contains the username of the user whose role
assignment is represented by this row.</li>
<li>There must be a column, named by the <code>userRoleCol</code>
attribute, that contains the role name assigned to this user.</li>
</ul></li>
</ul>
<p>Once a user is successfully authenticated, the following methods of the
<code>HttpServletRequest</code> interface will return useful values:</p>
<ul>
<li><strong>getRemoteUser()</strong> - Will return the username of the user
who was authenticated.</li>
<li><strong>getUserPrincipal()</strong> - Will return a synthesized
<code>java.security.Principal</code> implementation object representing
the user who was authenticated.</li>
<li><strong>isUserInRole(String)</strong> - Will return <code>true</code> if
the currently authenticated user has a valid assignment to the
specified role.</li>
</ul>
<br>
<a name="MemoryRealm"></a>
<h3>Memory Based Realm (<code>org.apache.catalina.realm.MemoryRealm</code>)</h3>
<p>The <strong>Memory Based Realm</strong> initializes a simple memory-based
database from an XML configuration file (by default,
<code>$CATALINA_HOME/conf/tomcat-users.xml</code>) when Tomcat is first
initialized. The format of this file is consistent with the format of the
corresponding file used in Tomcat 3.x versions. An instance of a Memory
Based Realm is used in the example application that is shipped with Catalina.
</p>
<p>The Memory Based Realm supports the following additional attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td><code>pathname</code></td>
<td>Relative or absolute pathname of the configuration file used to
initialize the contents of this Realm. If a relative path is
specified, it is interpreted as relative to $CATALINA_HOME. If
no pathname is specified the default value is "conf/tomcat-users.xml"
(relative to the Catalina home directory).
</td>
</tr>
</table>
<p>The configuration file specified by the <code>pathname</code> attribute must
be in XML format. It consists of an outer element named
<code><tomcat-users></code>, along with one nested
<code><user></code> element for each defined user. Each user element
supports the following attributes:</p>
<ul>
<li><strong>name</strong> - The username of this user (must be unique among
all users defined in this configuration file)</li>
<li><strong>password</strong> - The corresponding login password, in clear
text</li>
<li><strong>roles</strong> - A comma-delimited list of the roles to which
this user belongs, or a zero-length string for no role assignments</li>
</ul>
<p>Once a user is successfully authenticated, the following methods of the
<code>HttpServletRequest</code> interface will return useful values:</p>
<ul>
<li><strong>getRemoteUser()</strong> - Will return the username of the user
who was authenticated.</li>
<li><strong>getUserPrincipal()</strong> - Will return a synthesized
<code>java.security.Principal</code> implementation object representing
the user who was authenticated.</li>
<li><strong>isUserInRole(String)</strong> - Will return <code>true</code> if
the currently authenticated user has a valid assignment to the
specified role.</li>
</ul>
<br>
<a name="Special Features"></a>
<h2>Special Features</h2>
<h3>Single Sign On Support</h3>
<p>Normally, an individual user will need to authenticate himself or herself
to each web application individually, even if the underlying Realm is being
shared across an entire virtual host. Often, it is desirable for the user
to be required to authenticate only once, and have that identity recognized
across all of the web applications for this host.</p>
<p>Tomcat includes <em>Single Sign On</em> support to enable this. The
detailed configuration requirements can be found
<a href="../singlesignon.html" target="_new">here</a>.
<br>
</body>
</html>
1.1 jakarta-tomcat-4.0/catalina/docs/config/valve.html
Index: valve.html
===================================================================
<html>
<head>
<title>The 'Valve' Component</title>
</head>
<body bgcolor="white">
<div align="center">
<h1>The <u>Valve</u> Component</h1>
<br>
<a href="#Introduction">[Introduction]</a>
<a href="#Common Attributes">[Common Attributes]</a>
<a href="#Standard Implementation Attributes">[Standard Implementation Attributes]</a>
<br>
</div>
<a name="Introduction"></a>
<h2>Introduction</h2>
<p>A <strong>Valve</strong> component represents an instance of a specified
Java class that will be involved in the processing of each request and response
handled by the <strong>Container</strong> within which it is nested,
as follows:</p>
<ul>
<li>A Valve nested inside an <a href="engine.html">Engine</a> will process
all requests received by any <strong>Connector</strong> associated with
the <a href="service.html">Service</a> in which this Engine is nested.</li>
<li>A Valve nested inside a <a href="host.html">Host</a> will process all
requests received by the associated <a href="engine.html">Engine</a> and
directed to the specified virtual host, but not requests directed to any
other virtual host associated with that Engine.</li>
<li>A Valve nested inside a <a href="context.html">Context</a> will process
all requests received by the associated <a href="host.html">Host</a>, and
mapped to the specified web application, but not requests mapped to any
other web application associated with that Host.</li>
</ul>
<p>Valves are typically used to implement optional features for the associated
Container. See the "Special Features" section of the documentation on
<a href="engine.html">Engine</a>, <a href="host.html">host</a>, and
<a href="context.html">Context</a> Containers for more information about the
Valves designed to be associated with each Container type. This page
summarizes the configuration information for all standard Valve implementations
that are provided with Catalina.</p>
<br>
<a name="Common Attributes"></a>
<h2>Common Attributes</h2>
<p>All implementations of the <strong>Valve</strong> component support the
following attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td><code>className</code></td>
<td>Java class name of the implementation to use. This class must
implement the <code>org.apache.catalina.Valve</code> interface.
Because there is no single standard implementation, this attribute
is required. See <a href="#Standard Implementation Attributes">
Standard Implementation Attributes</a> for the names of the
supported classes.
</td>
</tr>
</table>
<br>
<a name="Standard Implementation Attributes"></a>
<h2>Standard Implementation Attributes</h2>
<p>Unlike most other Catalina components, there is not a single standard
implementation of the <strong>Valve</strong> component available. Instead,
a variety of standard implementations, with different functional purposes,
are available for your use. To select one, use the specified value for the
<code>className</code> attribute, and configure the remaining attributes
as described below.</p>
<a name="AccessLogValve"></a>
<h3>Access Log Valve (<code>org.apache.catalina.valve.AccessLogValve</code>)</h3>
<p>The <strong>Access Log Valve</strong> creates log files in the same format
as those created by standard web servers. These logs can later be analyzed
by standard log analysis tools to track page hit counts, user session activity,
and so on. The access log Valve shares many configuration characteristics with
the <a href="logger.html#FileLogger">File Logger</a>
components used to record internal event, exception, and debugging output from
Catalina components, including the automatic rollover of log files at
midnight each night. An Access Log Valve can be associated with an
<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
<a href="context.html">Context</a> Container, and will log requests processed
by the associated Container and any nested Containers.</p>
<p>The Access Log Valve supports the following additional attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td><code>directory</code></td>
<td>Relative or absolute pathname of the directory into which log
files will be created. If a relative path is specified, it is
interpreted as relative to $CATALINA_HOME. If no directory is
specified, the default value is "logs" (relative to the
Catalina home directory).
</td>
</tr>
<tr>
<td><code>pattern</code></td>
<td>A formatting layout identifying the various information fields
from the request and response to be logged, or the word
<code>common</code> to select the standard Common Log Format.
See below for more information on pattern variables. If no
value is specified, the <code>common</code> format is utilized.
</tr>
<tr>
<td><code>prefix</code></td>
<td>The prefix added to the front of each log file name. If not
specified, the default value is "access_log.". To specify no
prefix, use a zero-length string.
</td>
</tr>
<tr>
<td><code>resolveHosts</code></td>
<td>Should the IP address of the remote client for each request be
resolved to the corresponding host name (via a DNS lookup)? You
might wish to turn off host resolution to improve performance
in high activity web applications. If not specified, the default
value is <code>false</code>, indicating that remote host resolution
will not take place.
</td>
</tr>
<tr>
<td><code>suffix</code></td>
<td>The suffix added to the end of each log file name. If not
specified, the default value is "". To specify no suffix,
use a zero-length string.
</td>
</tr>
<tr>
<td><code>timestamp</code></td>
<td>Should log messages be date/time stamped? Set this value to
<code>true</code> or <code>false</code>. If not specified,
log messages will not be date/time stamped.
</td>
</tr>
</table>
<p>Values for the <code>pattern</code> attribute are made up of literal text
strings, and pattern identifiers prefixed by the <strong>%</strong> character,
which cause replacement by the corresponding variable value from the current
request and response. The following pattern codes are supported:</p>
<ul>
<li><b>%a</b> - Remote IP address</li>
<li><b>%A</b> - Local IP address</li>
<li><b>%b</b> - Bytes sent, excluding HTTP headers, or '-' if zero</li>
<li><b>%B</b> - Bytes sent, excluding HTTP headers</li>
<li><b>%h</b> - Remote host name (or IP address if resolveHosts is false)</li>
<li><b>%H</b> - Request protocol</li>
<li><b>%l</b> - Remote logical username from identd (always returns '-')</li>
<li><b>%m</b> - Request method (GET, POST, etc.)</li>
<li><b>%p</b> - Local port on which this request was received</li>
<li><b>%q</b> - Query string (prepended with a '?' if it exists)</li>
<li><b>%r</b> - First line of the request (method and request URI)</li>
<li><b>%s</b> - HTTP status code of the response</li>
<li><b>%t</b> - Date and time, in Common Log Format</li>
<li><b>%u</b> - Remote user that was authenticated (if any), else '-'</li>
<li><b>%U</b> - Requested URL path</li>
<li><b>&v</b> - Local server name</li>
</ul>
<p>If you specify a pattern of <code>common</code>, or do not specify a pattern
at all, the common pattern <code>%h %l %u %t "%r" %s %b</code> is used, which
corresponds to the default logging format for many web servers.</p>
<a name="RemoteAddressFilter"></a>
<h3>Remote Address Filter (<code>org.apache.catalina.valve.RemoteAddrValve</code>)</h3>
<p>The <strong>Remote Address Filter</strong> allows you to compare the IP
address of the client that submitted this request against one or more
<em>regular expressions</em>, and either allow the request to continue
or refuse to process a request from this client based on the outcome of the
comparison. A Remote Address Filter can be associated with an
<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
<a href="context.html">Context</a> Container, and will filter requests
processed by the associated Container and any nested Containers.</p>
<p>The Remote Address Filter supports the following additional attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td>allow</td>
<td>A comma-separated list of <em>regular expression</em> patterns that
the remote client's IP address is compared to. If this attribute is
specified, the remote address <strong>must</strong> match at least
one of the patterns to be allowed. If this attribute is not
specified, all requests are allowed unless the remote address
matches a <code>deny</code> pattern.
</td>
</tr>
<tr>
<td>deny</td>
<td>A comma-separated list of <em>regular expression</em> patterns that
the remote client's IP address is compared to. If this attribute is
specified, the remote address <strong>must not</strong> match any of
the specified patterns to be allowed. If this attribute is not
specified, any request where the remote address matches one of the
<code>accept</code> patterns is allowed.
</td>
</tr>
</table>
<a name="RemoteHostFilter"></a>
<h3>Remote Host Filter (<code>org.apache.catalina.valve.RemoteHostValve</code>)</h3>
<p>The <strong>Remote Host Filter</strong> allows you to compare the remote
host address of the client that submitted this request against one or more
<em>regular expressions</em>, and either allow the request to continue
or refuse to process a request from this client based on the outcome of the
comparison. A Remote Host Filter can be associated with an
<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
<a href="context.html">Context</a> Container, and will filter requests
processed by the associated Container and any nested Containers.</p>
<p>The Remote Address Host supports the following additional attributes:</p>
<table border="1" width="100%">
<tr>
<th width="15%">Attribute</th>
<th width="85%">Description</th>
</tr>
<tr>
<td>allow</td>
<td>A comma-separated list of <em>regular expression</em> patterns that
the remote client's host address is compared to. If this attribute is
specified, the remote address <strong>must</strong> match at least
one of the patterns to be allowed. If this attribute is not
specified, all requests are allowed unless the remote address
matches a <code>deny</code> pattern.
</td>
</tr>
<tr>
<td>deny</td>
<td>A comma-separated list of <em>regular expression</em> patterns that
the remote client's host address is compared to. If this attribute is
specified, the remote address <strong>must not</strong> match any of
the specified patterns to be allowed. If this attribute is not
specified, any request where the remote address matches one of the
<code>accept</code> patterns is allowed.
</td>
</tr>
</table>
<a name="RequestDumperValve"></a>
<h3>Request Dumper Valve (<code>org.apache.catalina.valve.RequestDumperValve</code>)</h3>
<p>The <strong>Request Dumper Valve</strong> is a debugging tool that lets you
insert a component that dumps the HTTP headers associated with the specified
request (before processing) and response (after processing) to the
<a href="logger.html">Logger</a> that is associated with our corresponding
Container. It is especially useful when trying to debug problems related to
headers or cookies sent by an HTTP client. A Request Dumper Filter can be
associated with an <a href="engine.html">Engine</a>,
<a href="host.html">Host</a>, or <a href="context.html">Context</a> Container,
and will log requests processed by the associated Container and any nested
Containers.</p>
<p>The Request Dumper Filter supports no additional attributes.</p>
<br>
</body>
</html>