On demand router settings

Use this topic to perform advanced configuration on an on demand router (ODR). With ODR settings, you can fine tune the behavior of the ODR. In particular, you can configure the connections and requests to the application server, enable caching, configure the requests that must be rejected, define how error responses are handled, and specify the location of the ODR logs.

The ODR server, upon creation, senses the environment and is capable of routing requests to WebSphere® Application Server. Additional configuration can be applied to the ODR to meet the needs of a particular environment. Configuration of the ODR in the DMZ is not supported.

To view this administrative console page, click Servers > Server types > On demand routers > odr_name > On demand router properties > On demand router settings.

To change the ODR settings, you must have administrator or configurator administrative privileges.

You can edit configurable field settings for the ODR on the Configuration tab.

Content server connection

Configure basic HTTP connection parameters between the proxy server and content servers.

Outbound request timeout: The default number of seconds the ODR waits for a response prior timing out a request to a content server. Consider this option carefully when changing the value.

Outbound connect timeout: The number of milliseconds that the ODR waits to connect to a server. If this time expires, the ODR attempts to connect to a different server. If no other available servers exist, the request times out. A value of 0 indicates that the ODR should use the operating system kernel timeout value

Pool connections to content server: The option to pool connections to the server is an optimization feature. Pooling prevents the need to frequently create and destroy socket connections to the server, by allowing the ODR to pool these connections and reuse them. The default value for the maximum connections per server is 0, which means the number of connections can increase as needed.

Maximum connections per server

The maximum number of connections that are pooled to any single content server. ODR custom properties that tweak content server connections are as follows:

key=http.maxTargetReconnects: Maximum number of reconnects to the same target content server for each request. The default is 5.
key=http.maxTargetRetries: Maximum number of times that the ODR attempts to select a new target content server for each request. The default is 5.
key=http.routing.sendReverseProxyNameInHost: Determines whether or not the ODR name is placed in the host header for content that is not specific to WebSphere Application Server content servers. The options are true or false and are not case sensitive. The default is false.
key=http.compliance.disable: Determines whether HTTP V1.1 compliance is enforced on ODR content server connections. The options are true or false and are not case sensitive. The default is false.
key=http.compliance.via: The value of the via header that is appended to requests and responses for HTTP compliance. If the value is null, a via header is not appended. If the value is true, a default via value is appended. Otherwise, the specified string via value is appended. The default is null.

Caching

The ODR can be configured to cache the content of servers.

By default, caching content is enabled. The properties that follow apply only if caching is enabled:

Enable caching: Enables caching framework for the ODR server and enables static content caching, as defined by HTTP 1.1 specifications.

Cache instance name: The dynamic cache object cache instance, that is configured under Resourcs > Cache instances > Object cache instances, used to cache all static and dynamic content responses. This object cache instance must be configured to support new I/O (NIO) application program interfaces (APIs).

Cache SSL content: Determines whether client ODR SSL connections that are terminated by the ODR should have their responses cached.

Cache aggressively: Enables caching of HTTP responses that would not normally be cached. Caching rules that are defined by HTTP 1.1 can be broken to gain caching optimization.

Cache dynamic content: Determines whether dynamic content that is generated by WebSphere Application Servers V6.02, or later, is cached. Caching dynamic content generated by content servers prior to WebSphere Application Server V6.02 is not supported.

Cache update URI: When caching dynamic content, this is the relative URI of an installed content server application that is used to invalidate cached entries.

Compression Policy

Enables compression of the HTTP response message body prior to sending it to the client.

gzip-only: Compress the response using the gzip compression mechanism. The response is compressed only if it is acceptable to the client, based on the Accept-Encoding request header.

deflate-only: Compress the response using the deflate compression mechanism. The response is compressed only if it is acceptable to the client, based on the Accept-Encoding request header.

auto-only: Use either gzip, deflate, or no compression as determined by the client preference

Exclusions

The ODR examines every incoming request. You can define certain methods for exclusion and if the requested HTTP method matches any of the configured methods for exclusion, the ODR rejects the requests with a METHOD DISALLOWED error.

HTTP methods disabled: By default, the CONNECT, PUT, and DELETE methods are disabled.

Logging

HTTP requests are logged in one of three logs: proxy, cache, and local. Local log configuration is not available in the administrative console, but is available at ${SERVER_LOG_ROOT}local.log. Specify the location of this log by setting the http.log.localFileName custom property to the file location. The content of each log is formatted using the National Center for Supercomputing Applications common log format.

Enable access logging: Select to enable logging.

Access log maximum: The maximum log size in megabytes (MB). 25 MB is the default.

Proxy access log: Logs responses that are received from remote servers.

Cache access log: Logs responses that are served from the local cache.

Local access log: Contains the name of the local log. A value of NULL indicates that the default ${SERVER_LOG_ROOT}/local.log is used. Logs all non-cache local responses, for example, redirects and internal errors. This content does not come from the ODR cache.

Security

Use this section to set up security options.

Trusted security proxies: Some topologies have another layer of routing enabled on top of the ODR. For example, Web servers read incoming requests to verify which ODR they are routed to. This configuration field enables intermediaries other than the ODR server to handle the request by explicitly telling the ODR that is to trust them. Use an internet protocol or fully-qualified host name in this field.

Proxy plug-in configuration policy

Generate plug-in configuration: Use this parameter for the generation of an ODR plug-in configuration file that you can use on a Web server that is deployed in front of the ODR. The plug-in can determine the URI that the ODR is handling on behalf of the application server. The plug-in can determine the endpoint, or boundaries of the ODR so that it can properly route requests it receives to the ODR. This feature is useful for those who prefer to deploy a proven Web server in the demilitarized zone (DMZ), which is fully capable of exploiting the ability of the ODR. Note that the configuration of the ODR in the DMZ is not supported.
You can define a level by which to generate the plug-in. For the cell scope, the ODR generates a plug-in configuration that includes all of the URIs managed by all the ODRs in the cell. For the node scope, the plug-in configuration file contains all the URIs managed by the ODRs that are defined on the same node as the ODR that is generating the plug-in. Additionally, all traffic routed by the plug-in configuration file is routed through only the ODRs on the same node as this ODR. For the server scope, the plug-in configuration file contains all the URIs managed by only the ODR that is generating the plug-in, and all traffic routed by the plug-in configuration file is routed through this ODR only.

Plugin config change script: Specifies the path to a script that is run following the WebSphere Application Server plug-in configuration is generated.

Custom error page policy

Use this field to support the use of customized error pages when errors occur during the processing of the request.

The default is no customized error pages generated. The properties that follow enable customized error pages for use when errors occur during request processing:

Error page generation application URI: If a valid URI to an installed application is not provided, the custom error page policy does not handle requests.

Handle remote errors: When not selected, HTTP response error status codes are handled only when the ODR generates an error response. When selected, HTTP response error status codes are handled when the ODR generates an error response, as well as when an application server generates an error response. A best practice is to configure an error page application on the same physical machine as the ODR.

Headers to forward to error page application

Specifies additional header values from the client request to forward to the error page application as query parameters. The responseCode and URI query parameters are always sent to the error page application, in addition to the ones that are configured. The responseCode parameter is the HTTP status code that generates internally or is returned by the content server. The URI parameter is the request URI for the client.

Example - The error page URI is /ErrorPageApp/ErrorPage, the headers to forward contain Host, and a client sends the following request:

GET  /house/rooms/kitchen.jpg HTTP/1.1
Host:  homeserver.companyx.com
The request results in a HTTP 404 response (local or remote), and the request URI to the error page application would be:
/ErrorPageApp/ErrorPage?responseCode=404&uri=/house/rooms/kitchen.jpg&Host= homeserver.companyx.com

HTTP status codes that are to be recognized as errors

The status codes for which the error page policy provides a response. If a status code is not specified, the original content of responses with that status code is returned. If no HTTP status codes are specified, the defaults, 404 and 5XX, are used. Instead of specifying status codes individually, the following method is recommended to represent a range:

5XX: 500-599
4XX: 400-499
3XX: 300-399
2XX: 200-299

File name: odr_settings.html