# Server Configuration Reference ## The Valve Component |
Introduction
A Valve element represents a component that will be inserted into the request processing pipeline for the associated Catalina container (Engine, Host, or Context). Individual Valves have distinct processing capabilities, and are described individually below. The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 5, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 5 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references.
Access Log Valve
> Introduction
> The Access Log Valve 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 and behavior characteristics of the File Logger, including the automatic rollover of log files at midnight each night. An Access Log Valve can be associated with any Catalina container, and will record ALL requests processed by that container.
> Attributes
> > The Access Log Valve supports the following configuration attributes:
> > Attribute | Description
> > --- | ---
> > `className` | Java class name of the implementation to use. This MUST be set to org.apache.catalina.valves.AccessLogValve.
> > `directory` | Absolute or relative pathname of a directory in which log files created by this valve will be placed. If a relative path is specified, it is interpreted as relative to $CATALINA_HOME. If no directory attribute is specified, the default value is "logs" (relative to $CATALINA_HOME).
> > `pattern` | A formatting layout identifying the various information fields from the request and response to be logged, or the word `common` or `combined` to select a standard format. See below for more information on configuring this attribute.
> > `prefix` | The prefix added to the start of each log file's name. If not specified, the default value is "access_log.". To specify no prefix, use a zero-length string.
> > `resolveHosts` | Set to `true` to convert the IP address of the remote host into the corresponding host name via a DNS lookup. Set to `false` to skip this lookup, and report the remote IP address instead.
> > `suffix` | The suffix added to the end of each log file's name. If not specified, the default value is "". To specify no suffix, use a zero-length string.
> > `rotatable` | Deafult true. Flag to determine if log rotation should occur. If set to false, then this file is never rotated and `fileDateFormat` is ignored. Use with caution!
> > `condition` | Turns on conditional logging. If set, requests will be logged only if `ServletRequest.getAttribute()` is null. For example, if this value is set to `junk`, then a particular request will only be logged if `ServletRequest.getAttribute("junk") == null`. The use of Filters is an easy way to set/unset the attribute in the ServletRequest on many different requests.
> > `fileDateFormat` | Allows a customized date format in the access log file name. The date format also decides how often the file is rotated. If you wish to rotate every hour, then set this value to: `yyyy-MM-dd.HH`
> Values for the `pattern` attribute are made up of literal text strings, combined with pattern identifiers prefixed by the "%" character to cause replacement by the corresponding variable value from the current request and response. The following pattern codes are supported: %a - Remote IP address %A - Local IP address %b - Bytes sent, excluding HTTP headers, or '-' if zero %B - Bytes sent, excluding HTTP headers %h - Remote host name (or IP address if `resolveHosts` is false) %H - Request protocol %l - Remote logical username from identd (always returns '-') %m - Request method (GET, POST, etc.) %p - Local port on which this request was received %q - Query string (prepended with a '?' if it exists) %r - First line of the request (method and request URI) %s - HTTP status code of the response %S - User session ID %t - Date and time, in Common Log Format %u - Remote user that was authenticated (if any), else '-' %U - Requested URL path %v - Local server name %D - Time taken to process the request, in millis %T - Time taken to process the request, in seconds There is also support to write information from the cookie, incoming header, the Session or something else in the ServletRequest. It is modeled after the apache syntax: `%{xxx}i` for incoming headers `%{xxx}c` for a specific cookie `%{xxx}r` xxx is an attribute in the ServletRequest `%{xxx}s` xxx is an attribute in the HttpSession The shorthand pattern name `common` (which is also the default) corresponds to %h %l %u %t "%r" %s %b". The shorthand pattern name `combined` appends the values of the `Referer` and `User-Agent` headers, each in double quotes, to the `common` pattern described in the previous paragraph.
Remote Address Filter
> Introduction
> The Remote Address Filter allows you to compare the IP address of the client that submitted this request against one or more regular expressions, and either allow the request to continue or refuse to process the request from this client. A Remote Address Filter can be associated with any Catalina container (Engine, Host, or Context), and must accept any request presented to this container for processing before it will be passed on. The syntax for regular expressions is different than that for 'standard' wildcard matching. Tomcat uses the Jakarta Regexp library. Please consult the Regexp documentation for details of the expressions supported.
> Attributes
> > The Remote Address Filter supports the following configuration attributes:
> > Attribute | Description
> > --- | ---
> > `className` | Java class name of the implementation to use. This MUST be set to org.apache.catalina.valves.RemoteAddrValve.
> > `allow` | A comma-separated list of regular expression patterns that the remote client's IP address is compared to. If this attribute is specified, the remote address MUST match for this request to be accepted. If this attribute is not specified, all requests will be accepted UNLESS the remote address matches a `deny` pattern.
> > `deny` | A comma-separated list of regular expression patterns that the remote client's IP address is compared to. If this attribute is specified, the remote address MUST NOT match for this request to be accepted. If this attribute is not specified, request acceptance is governed solely by the `accept` attribute.
Remote Host Filter
> Introduction
> The Remote Host Filter allows you to compare the hostname of the client that submitted this request against one or more regular expressions, and either allow the request to continue or refuse to process the request from this client. A Remote Host Filter can be associated with any Catalina container (Engine, Host, or Context), and must accept any request presented to this container for processing before it will be passed on. The syntax for regular expressions is different than that for 'standard' wildcard matching. Tomcat uses the Jakarta Regexp library. Please consult the Regexp documentation for details of the expressions supported.
> Attributes
> > The Remote Host Filter supports the following configuration attributes:
> > Attribute | Description
> > --- | ---
> > `className` | Java class name of the implementation to use. This MUST be set to org.apache.catalina.valves.RemoteHostValve.
> > `allow` | A comma-separated list of regular expression patterns that the remote client's hostname is compared to. If this attribute is specified, the remote hostname MUST match for this request to be accepted. If this attribute is not specified, all requests will be accepted UNLESS the remote hostname matches a `deny` pattern.
> > `deny` | A comma-separated list of regular expression patterns that the remote client's hostname is compared to. If this attribute is specified, the remote hostname MUST NOT match for this request to be accepted. If this attribute is not specified, request acceptance is governed solely by the `accept` attribute.
Request Dumper Valve
> Introduction
> The Request Dumper Valve is a useful tool in debugging interactions with a client application (or browser) that is sending HTTP requests to your Tomcat-based server. When configured, it causes details about each request processed by its associated Engine, Host, or Context to be logged to the Logger that corresponds to that container. WARNING: Using this valve has side-effects. The output from this valve includes any parameters included with the request. The parameters will be decoded using the default platform encoding. Any subsequent calls to `request.setCharacterEncoding()` within the web application will have no effect.
> Attributes
> > The Request Dumper Valve supports the following configuration attributes:
> > Attribute | Description
> > --- | ---
> > `className` | Java class name of the implementation to use. This MUST be set to org.apache.catalina.valves.RequestDumperValve.
Single Sign On Valve
> Introduction
> The Single Sign On Vale is utilized when you wish to give users the ability to sign on to any one of the web applications associated with your virtual host, and then have their identity recognized by all other web applications on the same virtual host. See the Single Sign On special feature on the Host element for more information.
> Attributes
> > The Single Sign On Valve supports the following configuration attributes:
> > Attribute | Description
> > --- | ---
> > `className` | Java class name of the implementation to use. This MUST be set to org.apache.catalina.authenticator.SingleSignOn.
> > `debug` | Detail level of debugging messages created by this component. By default, this is set to zero (0), which means no debug output.
> > `requireReauthentication` | Default false. Flag to determine whether each request needs to be reauthenticated to the security Realm. If "true", this Valve uses cached security credentials (username and password) to reauthenticate to the Realm each request associated with an SSO session. If "false", the Valve can itself authenticate requests based on the presence of a valid SSO cookie, without rechecking with the Realm.
Copyright © 1999-2003, Apache Software Foundation