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, auto-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.
To view this administrative console page, click Servers > On demand
routers > ODR_name > On demand router properties > On demand
router settings.
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 SSL alias
- The SSL (secure sockets layer) repertoire alias, configured under Security
> SSL, that is used to secure ODR content server connections. If requests
can be handled over SSL connections only, it is recommended that you create
a new SSL alias that contains the trusted certificate authorities and point
to that alias. Create an SSL alias in the administrative console by clicking Security
> SSL > New JSSE Repertoire.
- Outbound request timeout
- The default number of seconds the ODR waits for a response before timing
out a request to a content server. Consider this option carefully when changing
the value.
- Pool connections to 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.
- 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.
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, only HTTP response error status codes generated by
the ODR are handled. When selected, HTTP response error status codes generated
by the ODR and HTTP response error status codes generated elsewhere after
the ODR on the ODR content server connection error responses are handled.
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