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>