Quellcode-Bibliothek

^© Kompilation durch diese Firma

[Weder Korrektheit noch Funktionsfähigkeit der Software werden zugesichert.]

Datei: Sprache: XML

Original von: Apache^©

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE document [
 <!ENTITY project SYSTEM "project.xml">
]>
<document url="valve.html">

 &project;

 <properties>
 <author email="[email protected]">Craig R. McClanahan</author>
 <title>The Valve Component</title>
 </properties>

<body>

<section name="Table of Contents">
<toc/>
</section>

<section name="Introduction">

 A Valve element represents a component that will be
 inserted into the request processing pipeline for the associated
 Catalina container (<a href="engine.html">Engine</a>,
 <a href="host.html">Host</a>, or <a href="context.html">Context</a>).
 Individual Valves have distinct processing capabilities, and are
 described individually below.

 The description below uses the variable name $CATALINA_BASE to refer the
 base directory against which most relative paths are resolved. If you have
 not configured Tomcat for multiple instances by setting a CATALINA_BASE
 directory, then $CATALINA_BASE will be set to the value of $CATALINA_HOME,
 the directory into which you have installed Tomcat.

</section>

<section name="Access Logging">

Access logging is performed by valves that implement
org.apache.catalina.AccessLog interface.

<subsection name="Access Log Valve">

 <subsection name="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. This <code>Valve</code>
 uses self-contained logic to write its log files, which can be
 automatically rolled over at midnight each day. (The essential
 requirement for access logging is to handle a large continuous
 stream of data with low overhead. This <code>Valve</code> does not
 use Apache Commons Logging, thus avoiding additional overhead and
 potentially complex configuration).

 This <code>Valve</code> may be associated with any Catalina container
 (<code>Context</code>, <code>Host</code>, or <code>Engine</code>), and
 will record ALL requests processed by that container.

 Some requests may be handled by Tomcat before they are passed to a
 container. These include redirects from /foo to /foo/ and the rejection of
 invalid requests. Where Tomcat can identify the <code>Context</code> that
 would have handled the request, the request/response will be logged in the
 <code>AccessLog</code>(s) associated <code>Context</code>, <code>Host</code>
 and <code>Engine</code>. Where Tomcat cannot identify the
 <code>Context</code> that would have handled the request, e.g. in cases
 where the URL is invalid, Tomcat will look first in the <code>Engine</code>,
 then the default <code>Host</code> for the <code>Engine</code> and finally
 the ROOT (or default) <code>Context</code> for the default <code>Host</code>
 for an <code>AccessLog</code> implementation. Tomcat will use the first
 <code>AccessLog</code> implementation found to log those requests that are
 rejected before they are passed to a container.

 The output file will be placed in the directory given by the
 <code>directory</code> attribute. The name of the file is composed
 by concatenation of the configured <code>prefix</code>, timestamp and
 <code>suffix</code>. The format of the timestamp in the file name can be
 set using the <code>fileDateFormat</code> attribute. This timestamp will
 be omitted if the file rotation is switched off by setting
 <code>rotatable</code> to <code>false</code>.

 Warning: If multiple AccessLogValve instances
 are used, they should be configured to use different output files.

 If sendfile is used, the response bytes will be written asynchronously
 in a separate thread and the access log valve will not know how many bytes
 were actually written. In this case, the number of bytes that was passed to
 the sendfile thread for writing will be recorded in the access log valve.
 
 </subsection>

 <subsection name="Attributes">

 The Access Log Valve supports the following
 configuration attributes:

 <attributes>

 <attribute name="buffered" required="false">
 Flag to determine if logging will be buffered.
 If set to <code>false</code>, then access logging will be written after each
 request. Default value: <code>true</code>
 
 </attribute>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.AccessLogValve to use the
 default access log valve.
 </attribute>

 <attribute name="condition" required="false">
 The same as <code>conditionUnless</code>. This attribute is
 provided for backwards compatibility.
 
 </attribute>

 <attribute name="conditionIf" required="false">
 Turns on conditional logging. If set, requests will be
 logged only if <code>ServletRequest.getAttribute()</code> is
 not null. For example, if this value is set to
 <code>important</code>, then a particular request will only be logged
 if <code>ServletRequest.getAttribute("important") != null</code>.
 The use of Filters is an easy way to set/unset the attribute
 in the ServletRequest on many different requests.
 
 </attribute>

 <attribute name="conditionUnless" required="false">
 Turns on conditional logging. If set, requests will be
 logged only if <code>ServletRequest.getAttribute()</code> is
 null. For example, if this value is set to
 <code>junk</code>, then a particular request will only be logged
 if <code>ServletRequest.getAttribute("junk") == null</code>.
 The use of Filters is an easy way to set/unset the attribute
 in the ServletRequest on many different requests.
 
 </attribute>

 <attribute name="directory" required="false">
 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_BASE. If
 no directory attribute is specified, the default value is "logs"
 (relative to $CATALINA_BASE).
 </attribute>

 <attribute name="encoding" required="false">
 Character set used to write the log file. An empty string means
 to use the default character set. Default value: UTF-8.
 
 </attribute>

 <attribute name="fileDateFormat" required="false">
 Allows a customized timestamp in the access log file name.
 The file is rotated whenever the formatted timestamp changes.
 The default value is <code>.yyyy-MM-dd</code>.
 If you wish to rotate every hour, then set this value
 to <code>.yyyy-MM-dd.HH</code>.
 The date format will always be localized
 using the locale <code>en_US</code>.
 
 </attribute>

 <attribute name="ipv6Canonical" required="false">
 Flag to determine if IPv6 addresses should be represented in canonical
 representation format as defined by RFC 5952. If set to <code>true</code>,
 then IPv6 addresses will be written in canonical format (e.g.
 <code>2001:db8::1:0:0:1</code>, <code>::1</code>), otherwise it will be
 represented in full form (e.g. <code>2001:db8:0:0:1:0:0:1</code>,
 <code>0:0:0:0:0:0:0:1</code>). Default value: <code>false</code>
 
 </attribute>

 <attribute name="locale" required="false">
 The locale used to format timestamps in the access log
 lines. Any timestamps configured using an
 explicit SimpleDateFormat pattern (<code>%{xxx}t</code>)
 are formatted in this locale. By default the
 default locale of the Java process is used. Switching the
 locale after the AccessLogValve is initialized is not supported.
 Any timestamps using the common log format
 (<code>CLF</code>) are always formatted in the locale
 <code>en_US</code>.
 
 </attribute>

 <attribute name="maxDays" required="false">
 The maximum number of days rotated access logs will be retained for
 before being deleted. If not specified, the default value of
 <code>-1</code> will be used which means never delete old files.
 </attribute>

 <attribute name="maxLogMessageBufferSize" required="false">
 Log message buffers are usually recycled and re-used. To prevent
 excessive memory usage, if a buffer grows beyond this size it will be
 discarded. The default is <code>256</code> characters. This should be
 set to larger than the typical access log message size.
 </attribute>

 <attribute name="pattern" required="false">
 A formatting layout identifying the various information fields
 from the request and response to be logged, or the word
 <code>common</code> or <code>combined</code> to select a
 standard format. See below for more information on configuring
 this attribute.
 </attribute>

 <attribute name="prefix" required="false">
 The prefix added to the start of each log file's name. If not
 specified, the default value is "access_log".
 </attribute>

 <attribute name="renameOnRotate" required="false">
 By default for a rotatable log the active access log file name
 will contain the current timestamp in <code>fileDateFormat</code>.
 During rotation the file is closed and a new file with the next
 timestamp in the name is created and used. When setting
 <code>renameOnRotate</code> to <code>true</code>, the timestamp
 is no longer part of the active log file name. Only during rotation
 the file is closed and then renamed to include the timestamp.
 This is similar to the behavior of most log frameworks when
 doing time based rotation.
 Default value: <code>false</code>
 
 </attribute>

 <attribute name="requestAttributesEnabled" required="false">
 Set to <code>true</code> to check for the existence of request
 attributes (typically set by the RemoteIpValve and similar) that should
 be used to override the values returned by the request for remote
 address, remote host, server port and protocol. If the attributes are
 not set, or this attribute is set to <code>false</code> then the values
 from the request will be used. If not set, the default value of
 <code>false</code> will be used.
 </attribute>

 <attribute name="resolveHosts" required="false">
 This attribute is no longer supported. Use the connector
 attribute <code>enableLookups</code> instead.
 If you have <code>enableLookups</code> on the connector set to
 <code>true</code> and want to ignore it, use %a instead of
 %h in the value of <code>pattern</code>.
 </attribute>

 <attribute name="rotatable" required="false">
 Flag to determine if log rotation should occur.
 If set to <code>false</code>, then this file is never rotated and
 <code>fileDateFormat</code> is ignored.
 Default value: <code>true</code>
 
 </attribute>

 <attribute name="suffix" required="false">
 The suffix added to the end of each log file's name. If not
 specified, the default value is "" (a zero-length string),
 meaning that no suffix will be added.
 </attribute>

 </attributes>

 Values for the <code>pattern</code> 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:
 <ul>
 <li><code>%a</code> - Remote IP address.
 See also <code>%{xxx}a</code> below.</li>
 <li><code>%A</code> - Local IP address</li>
 <li><code>%b</code> - Bytes sent, excluding HTTP headers, or '-' if zero</li>
 <li><code>%B</code> - Bytes sent, excluding HTTP headers</li>
 <li><code>%D</code> - Time taken to process the request in microseconds</li>
 <li><code>%F</code> - Time taken to commit the response, in milliseconds</li>
 <li><code>%h</code> - Remote host name (or IP address if
 <code>enableLookups</code> for the connector is false)</li>
 <li><code>%H</code> - Request protocol</li>
 <li><code>%I</code> - Current request thread name (can compare later with stacktraces)</li>
 <li><code>%l</code> - Remote logical username from identd (always returns
 '-')</li>
 <li><code>%m</code> - Request method (GET, POST, etc.)</li>
 <li><code>%p</code> - Local port on which this request was received.
 See also <code>%{xxx}p</code> below.</li>
 <li><code>%q</code> - Query string (prepended with a '?' if it exists)</li>
 <li><code>%r</code> - First line of the request (method and request URI)</li>
 <li><code>%s</code> - HTTP status code of the response</li>
 <li><code>%S</code> - User session ID</li>
 <li><code>%t</code> - Date and time, in Common Log Format</li>
 <li><code>%T</code> - Time taken to process the request, in seconds</li>
 <li><code>%u</code> - Remote user that was authenticated (if any), else '-' (escaped if required)</li>
 <li><code>%U</code> - Requested URL path</li>
 <li><code>%v</code> - Local server name</li>
 <li><code>%X</code> - Connection status when response is completed:
 <ul>
 <li><code>X</code> = Connection aborted before the response completed.</li>
 <li><code>+</code> = Connection may be kept alive after the response is sent.</li>
 <li><code>-</code> = Connection will be closed after the response is sent.</li>
 </ul>
 </li>
 </ul>

 
 There is also support to write information incoming or outgoing
 headers, cookies, session or request attributes and special
 timestamp formats.
 It is modeled after the
 <a href="https://httpd.apache.org/">Apache HTTP Server</a> log configuration
 syntax. Each of them can be used multiple times with different <code>xxx</code> keys:
 
 <ul>
 <li><code>%{xxx}a</code> write remote address (client) (<code>xxx==remote</code>) or
 connection peer address (<code>xxx=peer</code>)</li>
 <li><code>%{xxx}i</code> write value of incoming header with name <code>xxx</code> (escaped if required)</li>
 <li><code>%{xxx}o</code> write value of outgoing header with name <code>xxx</code> (escaped if required)</li>
 <li><code>%{xxx}c</code> write value of cookie(s) with name <code>xxx</code> (comma separated and escaped if required)</li>
 <li><code>%{xxx}r</code> write value of ServletRequest attribute with name <code>xxx</code> (escaped if required, value <code>??</code> if request is null)</li>
 <li><code>%{xxx}s</code> write value of HttpSession attribute with name <code>xxx</code> (escaped if required, value <code>??</code> if request is null)</li>
 <li><code>%{xxx}p</code> write local (server) port (<code>xxx==local</code>) or
 remote (client) port (<code>xxx=remote</code>)</li>
 <li><code>%{xxx}t</code> write timestamp at the end of the request formatted using the
 enhanced SimpleDateFormat pattern <code>xxx</code></li>
 <li><code>%{xxx}T</code> write time taken to process the request using unit <code>xxx</code>
 where valid units are <code>ms</code> for milliseconds, <code>us</code> for microseconds,
 and <code>s</code> for seconds. <code>%{s}T</code> is equivalent to <code>%T</code> as well
 as <code>%{us}T</code> is equivalent to <code>%D</code>.</li>
 </ul>

 All formats supported by SimpleDateFormat are allowed in <code>%{xxx}t</code>.
 In addition the following extensions have been added:
 <ul>
 <li><code>sec</code> - number of seconds since the epoch</li>
 <li><code>msec</code> - number of milliseconds since the epoch</li>
 <li><code>msec_frac</code> - millisecond fraction</li>
 </ul>
 These formats cannot be mixed with SimpleDateFormat formats in the same format
 token.

 Furthermore one can define whether to log the timestamp for the request start
 time or the response finish time:
 <ul>
 <li><code>begin</code> or prefix <code>begin:</code> chooses
 the request start time</li>
 <li><code>end</code> or prefix <code>end:</code> chooses
 the response finish time</li>
 </ul>
 By adding multiple <code>%{xxx}t</code> tokens to the pattern, one can
 also log both timestamps.

 Escaping is applied as follows:
 <ul>
 <li><code>"</code> is escaped as <code>\"</code></li>
 <li><code>\</code> is escaped as <code>\\</code></li>
 <li>Standard C escaping are used for <code>\f</code>, <code>\n</code>,
 <code>\r</code> and <code>\t</code></li>
 <li>Any other control characters or characters with code points above 127
 are encoded using the standard Java unicode escaping
 (<code>\uXXXX</code>)</li>
 </ul>

 The shorthand pattern <code>pattern="common"</code>
 corresponds to the Common Log Format defined by
 '%h %l %u %t "%r" %s %b'.

 The shorthand pattern <code>pattern="combined"</code>
 appends the values of the <code>Referer</code> and <code>User-Agent</code>
 headers, each in double quotes, to the <code>common</code> pattern.

 Fields using unknown pattern identifiers will be logged as <code>???X???</code>
 where <code>X</code> is the unknown identifier. Fields with unknown pattern identifier
 plus <code>{xxx}</code> key will be logged as <code>???</code>.

 When Tomcat is operating behind a reverse proxy, the client information
 logged by the Access Log Valve may represent the reverse proxy, the browser
 or some combination of the two depending on the configuration of Tomcat and
 the reverse proxy. For Tomcat configuration options see
 <a href="#Proxies_Support">Proxies Support</a> and the
 <a href="../proxy-howto.html">Proxy How-To</a>. For reverse proxies that
 use mod_jk, see the <a
 href="https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html">generic
 proxy</a> documentation. For other reverse proxies, consult their
 documentation.
 </subsection>

</subsection>

<subsection name="Extended Access Log Valve">

 <subsection name="Introduction">

 The Extended Access Log Valve extends the
 <a href="#Access_Log_Valve">Access Log Valve</a> class, and so
 uses the same self-contained logging logic. This means it
 implements many of the same file handling attributes. The main
 difference to the standard <code>AccessLogValve</code> is that
 <code>ExtendedAccessLogValve</code> creates log files which
 conform to the Working Draft for the
 <a href="https://www.w3.org/TR/WD-logfile.html">Extended Log File Format</a>
 defined by the W3C.

 </subsection>

 <subsection name="Attributes">

 The Extended Access Log Valve supports all
 configuration attributes of the standard
 <a href="#Access_Log_Valve">Access Log Valve.</a> Only the
 values used for <code>className</code> and <code>pattern</code> differ.

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.ExtendedAccessLogValve to
 use the extended access log valve.
 </attribute>

 <attribute name="pattern" required="false">
 A formatting layout identifying the various information fields
 from the request and response to be logged.
 See below for more information on configuring this attribute.
 </attribute>

 </attributes>

 Values for the <code>pattern</code> attribute are made up of
 format tokens. Some of the tokens need an additional prefix. Possible
 prefixes are <code>c</code> for "client", <code>s</code> for "server",
 <code>cs</code> for "client to server", <code>sc</code> for
 "server to client" or <code>x</code> for "application specific".
 Furthermore some tokens are completed by an additional selector.
 See the <a href="https://www.w3.org/TR/WD-logfile.html">W3C specification</a>
 for more information about the format.

 The following format tokens are supported:
 <ul>
 <li>bytes - Bytes sent, excluding HTTP headers, or '-' if zero</li>
 <li>c-dns - Remote host name (or IP address if
 <code>enableLookups</code> for the connector is false)</li>
 <li>c-ip - Remote IP address</li>
 <li>cs-method - Request method (GET, POST, etc.)</li>
 <li>cs-uri - Request URI</li>
 <li>cs-uri-query - Query string (prepended with a '?' if it exists)</li>
 <li>cs-uri-stem - Requested URL path</li>
 <li>date - The date in yyyy-mm-dd format for GMT</li>
 <li>s-dns - Local host name</li>
 <li>s-ip - Local IP address</li>
 <li>sc-status - HTTP status code of the response</li>
 <li>time - Time the request was served in HH:mm:ss format for GMT</li>
 <li>time-taken - Time (in seconds as floating point) taken to serve the request</li>
 <li>x-threadname - Current request thread name (can compare later with stacktraces)</li>
 </ul>

 For any of the <code>x-H(XXX)</code> the following method will be called from the
 HttpServletRequest object:
 <ul>
 <li><code>x-H(authType)</code>: getAuthType </li>
 <li><code>x-H(characterEncoding)</code>: getCharacterEncoding </li>
 <li><code>x-H(contentLength)</code>: getContentLength </li>
 <li><code>x-H(locale)</code>: getLocale</li>
 <li><code>x-H(protocol)</code>: getProtocol </li>
 <li><code>x-H(remoteUser)</code>: getRemoteUser</li>
 <li><code>x-H(requestedSessionId)</code>: getRequestedSessionId</li>
 <li><code>x-H(requestedSessionIdFromCookie)</code>:
 isRequestedSessionIdFromCookie </li>
 <li><code>x-H(requestedSessionIdValid)</code>:
 isRequestedSessionIdValid</li>
 <li><code>x-H(scheme)</code>: getScheme</li>
 <li><code>x-H(secure)</code>: isSecure</li>
 </ul>

 
 There is also support to write information about headers
 cookies, context, request or session attributes and request
 parameters.
 
 <ul>
 <li><code>cs(XXX)</code> for incoming request headers with name XXX</li>
 <li><code>sc(XXX)</code> for outgoing response headers with name XXX</li>
 <li><code>x-A(XXX)</code> for the servlet context attribute with name XXX</li>
 <li><code>x-C(XXX)</code> for the cookie(s) with name XXX (comma separated if required)</li>
 <li><code>x-O(XXX)</code> for a concatenation of all outgoing response headers with name XXX</li>
 <li><code>x-P(XXX)</code> for the URL encoded (using UTF-8) request parameter with name XXX</li>
 <li><code>x-R(XXX)</code> for the request attribute with name XXX</li>
 <li><code>x-S(XXX)</code> for the session attribute with name XXX</li>
 </ul>

 </subsection>

</subsection>

<subsection name="JSON Access Log Valve">

 <subsection name="Introduction">

 The JSON Access Log Valve extends the
 <a href="#Access_Log_Valve">Access Log Valve</a>, and so
 uses the same self-contained logging logic. This means it
 implements the same file handling attributes. The main
 difference to the standard <code>AccessLogValve</code> is that
 <code>JsonAccessLogValve</code> creates log files which
 follow the JSON syntax as defined by
 <a href="https://www.rfc-editor.org/rfc/rfc8259.html">RFC 8259</a>.

 </subsection>

 <subsection name="Attributes">

 The JSON Access Log Valve supports all
 configuration attributes of the standard
 <a href="#Access_Log_Valve">Access Log Valve.</a> Only the
 values used for <code>className</code> differ.

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.JsonAccessLogValve to
 use the extended access log valve.
 </attribute>

 </attributes>

 While the patterns supported are the same as for the regular
 <a href="#Access_Log_Valve">Access Log Valve</a>,
 there are a few differences:
 <ul>
 <li>requests are logged as JSON objects.</li>
 <li>each supported "%X" single character pattern
 identifier results in a key value pair in this object.
 See below for the list of keys used for the respective pattern
 identifiers.</li>
 <li>each pattern identifiers using a subkey of the form <code>%{xxx}X</code>
 where "X" is one of "a", "p" or "t"
 results in a key value pair of the form "key-xxx".
 See below for the list of keys used for the respective pattern
 identifiers.</li>
 <li>each pattern identifiers using a subkey of the form <code>%{xxx}X</code>
 where "X" is one of "c", "i", "o", "r" or "s"
 results in a sub object. See below for the key pointing at this
 sub object. The keys in the sub object are the "xxx" subkeys in the pattern.</li>
 <li>each unsupported "%X" character pattern
 identifier results in a key value pair using the key "other-X".</li>
 <li>the values logged are the same as the ones logged by
 the standard <a href="#Access_Log_Valve">Access Log Valve</a>
 for the same pattern identifiers.</li>
 <li>any "xxx" subkeys get Json escaped.</li>
 <li>any verbatim text between pattern identifiers gets silently ignored.</li>
 </ul>
 The JSON object keys used for the pattern identifiers which
 do not generate a sub object are the following:
 <ul>
 <li><code>%a</code>: remoteAddr</li>
 <li><code>%A</code>: localAddr</li>
 <li><code>%b</code>: size</li>
 <li><code>%B</code>: byteSentNC</li>
 <li><code>%D</code>: elapsedTime</li>
 <li><code>%F</code>: firstByteTime</li>
 <li><code>%h</code>: host</li>
 <li><code>%H</code>: protocol</li>
 <li><code>%I</code>: threadName</li>
 <li><code>%l</code>: logicalUserName</li>
 <li><code>%m</code>: method</li>
 <li><code>%p</code>: port</li>
 <li><code>%q</code>: query</li>
 <li><code>%r</code>: request</li>
 <li><code>%s</code>: statusCode</li>
 <li><code>%S</code>: sessionId</li>
 <li><code>%t</code>: time</li>
 <li><code>%T</code>: elapsedTimeS</li>
 <li><code>%u</code>: user</li>
 <li><code>%U</code>: path</li>
 <li><code>%v</code>: localServerName</li>
 <li><code>%X</code>: connectionStatus</li>
 </ul>
 The JSON object keys used for the pattern identifiers which
 generate a sub object are the following:
 <ul>
 <li><code>%c</code>: cookies</li>
 <li><code>%i</code>: requestHeaders</li>
 <li><code>%o</code>: responseHeaders</li>
 <li><code>%r</code>: requestAttributes</li>
 <li><code>%s</code>: sessionAttributes</li>
 </ul>
 

 </subsection>

</subsection>

</section>

<section name="Access Control">

<subsection name="Remote Address Valve">

 <subsection name="Introduction">

 The Remote Address Valve 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
 Valve can be associated with any Catalina container
 (<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
 <a href="context.html">Context</a>), 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 <code>java.util.regex</code>
 package. Please consult the Java documentation for details of the
 expressions supported.

 After setting the attribute <code>addConnectorPort</code> to
 <code>true</code>, one can append the server connector port separated with a
 semicolon (";") to allow different expressions for each connector.

 By setting the attribute <code>usePeerAddress</code> to
 <code>true</code>, the valve will use the connection peer address in its
 checks. This will differ from the client IP, if a reverse proxy is used
 in front of Tomcat in combination with either the AJP protocol, or the
 HTTP protocol plus the <code>RemoteIp(Valve|Filter)</code>.

 A refused request will be answered a response with status code
 <code>403</code>. This status code can be overwritten using the attribute
 <code>denyStatus</code>.

 By setting the attribute <code>invalidAuthenticationWhenDeny</code> to
 <code>true</code>, the behavior when a request is refused can be changed
 to not deny but instead set an invalid <code>authentication</code>
 header. This is useful in combination with the context attribute
 <code>preemptiveAuthentication="true"</code>.

 Note: There is a caveat when using this valve with
 IPv6 addresses. Format of the IP address that this valve is processing
 depends on the API that was used to obtain it. If the address was obtained
 from Java socket using Inet6Address class, its format will be
 <code>x:x:x:x:x:x:x:x</code>. That is, the IP address for localhost
 will be <code>0:0:0:0:0:0:0:1</code> instead of the more widely used
 <code>::1</code>. Consult your access logs for the actual value.

 See also: <a href="#Remote_Host_Valve">Remote Host Valve</a>,
 <a href="#Remote_CIDR_Valve">Remote CIDR Valve</a>,
 <a href="#Remote_IP_Valve">Remote IP Valve</a>,
 <a href="http.html">HTTP Connector</a> configuration.
 </subsection>

 <subsection name="Attributes">

 The Remote Address Valve supports the following
 configuration attributes:

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.RemoteAddrValve.
 </attribute>

 <attribute name="allow" required="false">
 A regular expression (using <code>java.util.regex</code>) 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 <code>deny</code>
 pattern.
 </attribute>

 <attribute name="deny" required="false">
 A regular expression (using <code>java.util.regex</code>) 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 <code>allow</code> attribute.
 </attribute>

 <attribute name="denyStatus" required="false">
 HTTP response status code that is used when rejecting denied
 request. The default value is <code>403</code>. For example,
 it can be set to the value <code>404</code>.
 </attribute>

 <attribute name="addConnectorPort" required="false">
 Append the server connector port to the client IP address separated
 with a semicolon (";"). If this is set to <code>true</code>, the
 expressions configured with <code>allow</code> and
 <code>deny</code> is compared against <code>ADDRESS;PORT</code>
 where <code>ADDRESS</code> is the client IP address and
 <code>PORT</code> is the Tomcat connector port which received the
 request. The default value is <code>false</code>.
 </attribute>

 <attribute name="invalidAuthenticationWhenDeny" required="false">
 When a request should be denied, do not deny but instead
 set an invalid <code>authentication</code> header. This only works
 if the context has the attribute <code>preemptiveAuthentication="true"</code>
 set. An already existing <code>authentication</code> header will not be
 overwritten. In effect this will trigger authentication instead of deny
 even if the application does not have a security constraint configured.
 This can be combined with <code>addConnectorPort</code> to trigger authentication
 depending on the client and the connector that is used to access an application.
 </attribute>

 <attribute name="usePeerAddress" required="false">
 Use the connection peer address instead of the client IP address.
 They will differ, if a reverse proxy is used in front of Tomcat in
 combination with either the AJP protocol, or the HTTP protocol plus
 the <code>RemoteIp(Valve|Filter)</code>.
 </attribute>

 </attributes>

 </subsection>

 <subsection name="Example 1" anchor="Remote_Address_Valve/Example_localhost">
 To allow access only for the clients connecting from localhost:
 <source><![CDATA[<Valve className="org.apache.catalina.valves.RemoteAddrValve"
 allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/>]]></source>
 </subsection>

 <subsection name="Example 2" anchor="Remote_Address_Valve/Example_localhost_port">
 To allow unrestricted access for the clients connecting from localhost
 but for all other clients only to port 8443:
 <source><![CDATA[<Valve className="org.apache.catalina.valves.RemoteAddrValve"
 addConnectorPort="true"
 allow="127\.\d+\.\d+\.\d+;\d*|::1;\d*|0:0:0:0:0:0:0:1;\d*|.*;8443"/>]]></source>
 </subsection>

 <subsection name="Example 3" anchor="Remote_Address_Valve/Example_port_auth">
 To allow unrestricted access to port 8009, but trigger basic
 authentication if the application is accessed on another port:
<source><![CDATA[<Context>
 ...
 <Valve className="org.apache.catalina.valves.RemoteAddrValve"
 addConnectorPort="true"
 invalidAuthenticationWhenDeny="true"
 allow=".*;8009"/>
 <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" />
 ...
</Context>]]></source>
 </subsection>

</subsection>

<subsection name="Remote Host Valve">

 <subsection name="Introduction">

 The Remote Host Valve 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
 Valve can be associated with any Catalina container
 (<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
 <a href="context.html">Context</a>), 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 <code>java.util.regex</code>
 package. Please consult the Java documentation for details of the
 expressions supported.

 After setting the attribute <code>addConnectorPort</code> to
 <code>true</code>, one can append the server connector port separated with a
 semicolon (";") to allow different expressions for each connector.

 A refused request will be answered a response with status code
 <code>403</code>. This status code can be overwritten using the attribute
 <code>denyStatus</code>.

 By setting the attribute <code>invalidAuthenticationWhenDeny</code> to
 <code>true</code>, the behavior when a request is refused can be changed
 to not deny but instead set an invalid <code>authentication</code>
 header. This is useful in combination with the context attribute
 <code>preemptiveAuthentication="true"</code>.

 Note: This valve processes the value returned by
 method <code>ServletRequest.getRemoteHost()</code>. To allow the method
 to return proper host names, you have to enable "DNS lookups" feature on
 a Connector.

 See also: <a href="#Remote_Address_Valve">Remote Address Valve</a>,
 <a href="#Remote_CIDR_Valve">Remote CIDR Valve</a>,
 <a href="#Remote_IP_Valve">Remote IP Valve</a>,
 <a href="http.html">HTTP Connector</a> configuration.
 </subsection>

 <subsection name="Attributes">

 The Remote Host Valve supports the following
 configuration attributes:

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.RemoteHostValve.
 </attribute>

 <attribute name="allow" required="false">
 A regular expression (using <code>java.util.regex</code>) 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 <code>deny</code>
 pattern.
 </attribute>

 <attribute name="deny" required="false">
 A regular expression (using <code>java.util.regex</code>) 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 <code>allow</code> attribute.
 </attribute>

 <attribute name="denyStatus" required="false">
 HTTP response status code that is used when rejecting denied
 request. The default value is <code>403</code>. For example,
 it can be set to the value <code>404</code>.
 </attribute>

 <attribute name="addConnectorPort" required="false">
 Append the server connector port to the client hostname separated
 with a semicolon (";"). If this is set to <code>true</code>, the
 expressions configured with <code>allow</code> and
 <code>deny</code> is compared against <code>HOSTNAME;PORT</code>
 where <code>HOSTNAME</code> is the client hostname and
 <code>PORT</code> is the Tomcat connector port which received the
 request. The default value is <code>false</code>.
 </attribute>

 <attribute name="invalidAuthenticationWhenDeny" required="false">
 When a request should be denied, do not deny but instead
 set an invalid <code>authentication</code> header. This only works
 if the context has the attribute <code>preemptiveAuthentication="true"</code>
 set. An already existing <code>authentication</code> header will not be
 overwritten. In effect this will trigger authentication instead of deny
 even if the application does not have a security constraint configured.
 This can be combined with <code>addConnectorPort</code> to trigger authentication
 depending on the client and the connector that is used to access an application.
 </attribute>

 </attributes>

 </subsection>

</subsection>

<subsection name="Remote CIDR Valve">

 <subsection name="Introduction">

 The Remote CIDR Valve allows you to compare the
 IP address of the client that submitted this request against one or more
 netmasks following the CIDR notation, and either allow the request to
 continue or refuse to process the request from this client. IPv4 and
 IPv6 are both fully supported. A Remote CIDR Valve can be associated
 with any Catalina container (<a href="engine.html">Engine</a>,
 <a href="host.html">Host</a>, or <a href="context.html">Context</a>), and
 must accept any request presented to this container for processing before
 it will be passed on.
 

 This valve mimics Apache's Order,
 <code>Allow from</code> and <code>Deny from</code> directives,
 with the following limitations:
 

 <ul>
 <li><code>Order</code> will always be <code>allow, deny</code>;</li>
 <li>dotted quad notations for netmasks are not supported (that is, you
 cannot write <code>192.168.1.0/255.255.255.0</code>, you must write
 <code>192.168.1.0/24</code>;
 </li>
 <li>shortcuts, like <code>10.10.</code>, which is equivalent to
 <code>10.10.0.0/16</code>, are not supported;
 </li>
 <li>as the valve name says, this is a CIDR only valve,
 therefore subdomain notations like <code>.mydomain.com</code> are not
 supported either.
 </li>
 </ul>

 After setting the attribute <code>addConnectorPort</code> to
 <code>true</code>, one can append the server connector port separated with a
 semicolon (";") to allow different expressions for each connector.

 By setting the attribute <code>usePeerAddress</code> to
 <code>true</code>, the valve will use the connection peer address in its
 checks. This will differ from the client IP, if a reverse proxy is used
 in front of Tomcat in combination with either the AJP protocol, or the
 HTTP protocol plus the <code>RemoteIp(Valve|Filter)</code>.

 A refused request will be answered a response with status code
 <code>403</code>. This status code can be overwritten using the attribute
 <code>denyStatus</code>.

 By setting the attribute <code>invalidAuthenticationWhenDeny</code> to
 <code>true</code>, the behavior when a request is refused can be changed
 to not deny but instead set an invalid <code>authentication</code>
 header. This is useful in combination with the context attribute
 <code>preemptiveAuthentication="true"</code>.

 Some more features of this valve are:
 

 <ul>
 <li>if you omit the CIDR prefix, this valve becomes a single IP
 valve;</li>
 <li>unlike the <a href="#Remote_Host_Valve">Remote Host Valve</a>,
 it can handle IPv6 addresses in condensed form (<code>::1</code>,
 <code>fe80::/71</code>, etc).</li>
 </ul>

 See also: <a href="#Remote_Address_Valve">Remote Address Valve</a>,
 <a href="#Remote_Host_Valve">Remote Host Valve</a>,
 <a href="#Remote_IP_Valve">Remote IP Valve</a>,
 <a href="http.html">HTTP Connector</a> configuration.
 </subsection>

 <subsection name="Attributes">

 The Remote CIDR Valve supports the following
 configuration attributes:

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.RemoteCIDRValve.
 </attribute>

 <attribute name="allow" required="false">
 A comma-separated list of IPv4 or IPv6 netmasks or addresses
 that the remote client's IP address is matched against.
 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 IP is matched by a
 netmask in the <code>deny</code> attribute.
 
 </attribute>

 <attribute name="deny" required="false">
 A comma-separated list of IPv4 or IPv6 netmasks or addresses
 that the remote client's IP address is matched against.
 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 <code>accept</code>
 attribute.
 
 </attribute>

 <attribute name="denyStatus" required="false">
 HTTP response status code that is used when rejecting denied
 request. The default value is <code>403</code>. For example,
 it can be set to the value <code>404</code>.
 </attribute>

 <attribute name="addConnectorPort" required="false">
 Append the server connector port to the client IP address separated
 with a semicolon (";"). If this is set to <code>true</code>, the
 expressions configured with <code>allow</code> and
 <code>deny</code> is compared against <code>ADDRESS;PORT</code>
 where <code>ADDRESS</code> is the client IP address and
 <code>PORT</code> is the Tomcat connector port which received the
 request. The default value is <code>false</code>.
 </attribute>

 <attribute name="invalidAuthenticationWhenDeny" required="false">
 When a request should be denied, do not deny but instead
 set an invalid <code>authentication</code> header. This only works
 if the context has the attribute <code>preemptiveAuthentication="true"</code>
 set. An already existing <code>authentication</code> header will not be
 overwritten. In effect this will trigger authentication instead of deny
 even if the application does not have a security constraint configured.
 This can be combined with <code>addConnectorPort</code> to trigger authentication
 depending on the client and the connector that is used to access an application.
 </attribute>

 <attribute name="usePeerAddress" required="false">
 Use the connection peer address instead of the client IP address.
 They will differ, if a reverse proxy is used in front of Tomcat in
 combination with either the AJP protocol, or the HTTP protocol plus
 the <code>RemoteIp(Valve|Filter)</code>.
 </attribute>

 </attributes>

 </subsection>

 <subsection name="Example 1" anchor="Remote_CIDR_Valve/Example_localhost">
 To allow access only for the clients connecting from localhost:
 <source><![CDATA[<Valve className="org.apache.catalina.valves.RemoteCIDRValve"
 allow="127.0.0.1, ::1"/>]]></source>
 </subsection>

 <subsection name="Example 2" anchor="Remote_CIDR_Valve/Example_localhost_port">
 To allow unrestricted access for the clients connecting from the local network
 but for all clients in network 10. only to port 8443:
 <source><![CDATA[<Valve className="org.apache.catalina.valves.RemoteCIDRValve"
 addConnectorPort="true"
 allow="127.0.0.1;\d*|::1;\d*|10.0.0.0/8;8443"/>]]></source>
 </subsection>

 <subsection name="Example 3" anchor="Remote_CIDR_Valve/Example_port_auth">
 To allow access to port 8009 from network 10., but trigger basic
 authentication if the application is accessed on another port:
<source><![CDATA[<Context>
 ...
 <Valve className="org.apache.catalina.valves.RemoteCIDRValve"
 addConnectorPort="true"
 invalidAuthenticationWhenDeny="true"
 allow="10.0.0.0/8;8009"/>
 <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" />
 ...
</Context>]]></source>
 </subsection>

</subsection>

</section>

<section name="Proxies Support">
 <subsection name="Load Balancer Draining Valve">
 <subsection name="Introduction">
 
 When using mod_jk or mod_proxy_ajp, the client's session id is used to
 determine which back-end server will be used to serve the request. If the
 target node is being "drained" (in mod_jk, this is the DISABLED
 state; in mod_proxy_ajp, this is the Drain (N) state), requests
 for expired sessions can actually cause the draining node to fail to
 drain.
 
 
 Unfortunately, AJP-based load-balancers cannot prove whether the
 client-provided session id is valid or not and therefore will send any
 requests for a session that appears to be targeted to that node to the
 disabled (or "draining") node, causing the "draining" process to take
 longer than necessary.
 
 
 This Valve detects requests for invalid sessions, strips the session
 information from the request, and redirects back to the same URL, where
 the load-balancer should choose a different (active) node to handle the
 request. This will accelerate the "draining" process for the disabled
 node(s).
 

 
 The activation state of the node is sent by the load-balancer in the
 request, so no state change on the node being disabled is necessary. Simply
 configure this Valve in your valve pipeline and it will take action when
 the activation state is set to "disabled".
 

 
 You should take care to register this Valve earlier in the Valve pipeline
 than any authentication Valves, because this Valve should be able to
 redirect a request before any authentication Valve saves a request to a
 protected resource. If this happens, a new session will be created and
 the draining process will stall because a new, valid session will be
 established.
 
 </subsection>

 <subsection name="Attributes">
 The Load Balancer Draining Valve supports the
 following configuration attributes:

 <attributes>
 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.LoadBalancerDrainingValve.
 
 </attribute>

 <attribute name="redirectStatusCode" required="false">
 Allows setting a custom redirect code to be used when the client
 is redirected to be re-balanced by the load-balancer. The default is
 307 TEMPORARY_REDIRECT.
 </attribute>

 <attribute name="ignoreCookieName" required="false">
 When used with <code>ignoreCookieValue</code>, a client can present
 this cookie (and accompanying value) that will cause this Valve to
 do nothing. This will allow you to probe your disabled node
 before re-enabling it to make sure that it is working as expected.
 </attribute>

 <attribute name="ignoreCookieValue" required="false">
 When used with <code>ignoreCookieName</code>, a client can present
 a cookie (and accompanying value) that will cause this Valve to
 do nothing. This will allow you to probe your disabled node
 before re-enabling it to make sure that it is working as expected.
 </attribute>
 </attributes>
 </subsection>
 </subsection>

<subsection name="Remote IP Valve">

 <subsection name="Introduction">

 Tomcat port of
 <a href="https://httpd.apache.org/docs/trunk/mod/mod_remoteip.html">mod_remoteip</a>,
 this valve replaces the apparent client remote IP address and hostname for
 the request with the IP address list presented by a proxy or a load balancer
 via a request headers (e.g. "X-Forwarded-For").

 Another feature of this valve is to replace the apparent scheme
 (http/https), server port and <code>request.secure</code> with the scheme presented
 by a proxy or a load balancer via a request header
 (e.g. "X-Forwarded-Proto").

 This Valve may be used at the <code>Engine</code>, <code>Host</code> or
 <code>Context</code> level as required. Normally, this Valve would be used
 at the <code>Engine</code> level.

 If used in conjunction with Remote Address/Host valves then this valve
 should be defined first to ensure that the correct client IP address is
 presented to the Remote Address/Host valves.

 Note: By default this valve has no effect on the
 values that are written into access log. The original values are restored
 when request processing leaves the valve and that always happens earlier
 than access logging. To pass the remote address, remote host, server port
 and protocol values set by this valve to the access log,
 they are put into request attributes. Publishing these values here
 is enabled by default, but <code>AccessLogValve</code> should be explicitly
 configured to use them. See documentation for
 <code>requestAttributesEnabled</code> attribute of
 <code>AccessLogValve</code>.

 The names of request attributes that are set by this valve
 and can be used by access logging are the following:

 <ul>
 <li><code>org.apache.catalina.AccessLog.RemoteAddr</code></li>
 <li><code>org.apache.catalina.AccessLog.RemoteHost</code></li>
 <li><code>org.apache.catalina.AccessLog.Protocol</code></li>
 <li><code>org.apache.catalina.AccessLog.ServerPort</code></li>
 <li><code>org.apache.tomcat.remoteAddr</code></li>
 </ul>

 </subsection>

 <subsection name="Attributes">

 The Remote IP Valve supports the
 following configuration attributes:

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.RemoteIpValve.
 </attribute>

 <attribute name="remoteIpHeader" required="false">
 Name of the HTTP Header read by this valve that holds the list of
 traversed IP addresses starting from the requesting client. If not
 specified, the default of <code>x-forwarded-for</code> is used.
 </attribute>

 <attribute name="internalProxies" required="false">
 Regular expression (using <code>java.util.regex</code>) that a
 proxy's IP address must match to be considered an internal proxy.
 Internal proxies that appear in the remoteIpHeader will
 be trusted and will not appear in the proxiesHeader
 value. If not specified the default value of <code>
 10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|100\.6[4-9]{1}\.\d{1,3}\.\d{1,3}|100\.[7-9]{1}\d{1}\.\d{1,3}\.\d{1,3}|100\.1[0-1]{1}\d{1}\.\d{1,3}\.\d{1,3}|100\.12[0-7]{1}\.\d{1,3}\.\d{1,3}|172\.1[6-9]{1}\.\d{1,3}\.\d{1,3}|172\.2[0-9]{1}\.\d{1,3}\.\d{1,3}|172\.3[0-1]{1}\.\d{1,3}\.\d{1,3}|0:0:0:0:0:0:0:1
 </code> will be used.
 </attribute>

 <attribute name="proxiesHeader" required="false">
 Name of the HTTP header created by this valve to hold the list of
 proxies that have been processed in the incoming
 remoteIpHeader. If not specified, the default of
 <code>x-forwarded-by</code> is used.
 </attribute>

 <attribute name="requestAttributesEnabled" required="false">
 Set to <code>true</code> to set the request attributes used by
 AccessLog implementations to override the values returned by the
 request for remote address, remote host, server port and protocol.
 Request attributes are also used to enable the forwarded remote address
 to be displayed on the status page of the Manager web application.
 If not set, the default value of <code>true</code> will be used.
 </attribute>

 <attribute name="trustedProxies" required="false">
 Regular expression (using <code>java.util.regex</code>) that a
 proxy's IP address must match to be considered an trusted proxy.
 Trusted proxies that appear in the remoteIpHeader will
 be trusted and will appear in the proxiesHeader value.
 If not specified, no proxies will be trusted.
 </attribute>

 <attribute name="protocolHeader" required="false">
 Name of the HTTP Header read by this valve that holds the protocol
 used by the client to connect to the proxy. If not specified, the
 default of <code>X-Forwarded-Proto</code> is used.
 </attribute>

 <attribute name="hostHeader" required="false">
 Name of the HTTP Header read by this valve that holds the host
 used by the client to connect to the proxy. If not specified, the
 default of <code>null</code> is used.
 </attribute>

 <attribute name="portHeader" required="false">
 Name of the HTTP Header read by this valve that holds the port
 used by the client to connect to the proxy. If not specified, the
 default of <code>null</code> is used.
 </attribute>

 <attribute name="protocolHeaderHttpsValue" required="false">
 Value of the protocolHeader to indicate that it is
 an HTTPS request. If not specified, the default of <code>https</code> is
 used.
 </attribute>

 <attribute name="httpServerPort" required="false">
 Value returned by <code>ServletRequest.getServerPort()</code>
 when the protocolHeader indicates <code>http</code>
 protocol and no portHeader is present. If not
 specified, the default of <code>80</code> is used.
 </attribute>

 <attribute name="httpsServerPort" required="false">
 Value returned by <code>ServletRequest.getServerPort()</code>
 when the protocolHeader indicates <code>https</code>
 protocol and no portHeader is present. If not
 specified, the default of <code>443</code> is used.
 </attribute>

 <attribute name="changeLocalName" required="false">
 If <code>true</code>, the value returned by
 <code>ServletRequest.getLocalHost()</code> and
 <code>ServletRequest.getServerHost()</code> is modified by the this
 valve. If not specified, the default of <code>false</code> is used.
 </attribute>

 <attribute name="changeLocalPort" required="false">
 If <code>true</code>, the value returned by
 <code>ServletRequest.getLocalPort()</code> and
 <code>ServletRequest.getServerPort()</code> is modified by the this
 valve. If not specified, the default of <code>false</code> is used.
 </attribute>

 </attributes>

 </subsection>

</subsection>

<subsection name="SSL Valve">

 <subsection name="Introduction">

 When using mod_proxy_http, the client SSL information is not included in
 the protocol (unlike mod_jk and mod_proxy_ajp). To make the client SSL
 information available to Tomcat, some additional configuration is required.
 In httpd, mod_headers is used to add the SSL information as HTTP headers. In
 Tomcat, this valve is used to read the information from the HTTP headers and
 insert it into the request.

 Note: Ensure that the headers are always set by httpd for all requests to
 prevent a client spoofing SSL information by sending fake headers.

 To configure httpd to set the necessary headers, add the following:
<source><IfModule ssl_module>
 RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
 RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s"
 RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s"
 RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
</IfModule></source>

 </subsection>

 <subsection name="Attributes">

 The SSL Valve supports the following configuration
 attribute:

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.valves.SSLValve.
 
 </attribute>

 <attribute name="sslClientCertHeader" required="false">
 Allows setting a custom name for the ssl_client_cert header.
 If not specified, the default of <code>ssl_client_cert</code> is
 used.
 </attribute>

 <attribute name="sslClientEscapedCertHeader" required="false">
 Allows setting a custom name for the ssl_client_escaped_cert header.
 If not specified, the default of <code>ssl_client_escaped_cert</code> is
 used.
 This header is useful for Nginx proxying, and takes precedence over
 the ssl_client_cert header.
 </attribute>

 <attribute name="sslCipherHeader" required="false">
 Allows setting a custom name for the ssl_cipher header.
 If not specified, the default of <code>ssl_cipher</code> is
 used.
 </attribute>

 <attribute name="sslSessionIdHeader" required="false">
 Allows setting a custom name for the ssl_session_id header.
 If not specified, the default of <code>ssl_session_id</code> is
 used.
 </attribute>

 <attribute name="sslCipherUserKeySizeHeader" required="false">
 Allows setting a custom name for the ssl_cipher_usekeysize header.
 If not specified, the default of <code>ssl_cipher_usekeysize</code> is
 used.
 </attribute>

 </attributes>

 </subsection>

</subsection>

</section>

<section name="Single Sign On Valve">

 <subsection name="Introduction">

 The Single Sign On Valve 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 <a href="host.html#Single_Sign_On">Single Sign On</a> special
 feature on the Host element for more information.

 </subsection>

 <subsection name="Attributes">

 The Single Sign On Valve supports the following
 configuration attributes:

 <attributes>

 <attribute name="className" required="true">
 Java class name of the implementation to use. This MUST be set to
 org.apache.catalina.authenticator.SingleSignOn.
 </attribute>

 <attribute name="requireReauthentication" required="false">
 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.
--> --------------------

--> maximum size reached

--> --------------------

¤ Dauer der Verarbeitung: 0.57 Sekunden (vorverarbeitet) ¤

Druckansicht unsichere Verbindung
Druckansicht sprechenden Kalenders
in der Quellcodebibliothek suchen

Haftungshinweis

Die Informationen auf dieser Webseite wurden nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit, noch Qualität der bereit gestellten Informationen zugesichert.

Bemerkung:

Die farbliche Syntaxdarstellung ist noch experimentell.