Use this topic to perform advanced configuration on a proxy
server. Proxy settings enable the system administrator to fine tune
the behavior of the proxy server. 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 proxy logs.
The proxy server, upon creation, auto-senses the environment and
is capable of routing requests to WebSphere® Application Server. Additional configuration
can be applied to the proxy server to meet the needs of a particular
environment.
To view this administrative console page, click Servers > Proxy
Servers > server_name > HTTP Proxy Server Settings
> Proxy settings.
Avoid trouble: If the proxy server
you created is part of a proxy server cluster, the only HTTP proxy
server setting that you can modify at the proxy server level is
Local
outbound TCP address. The other HTTP proxy server settings
must be set at the proxy cluster level. See the topics
Modifying
a proxy server cluster, and
Proxy cluster member settings for
information on how to configure a proxy server that is part of a proxy
server cluster.
gotcha
You can edit configurable field settings for the proxy server on
the Configuration tab.
Configuration tab
Enable Web services support
Check this option to enable the proxy server to route Web
services traffic.
Exclusions
The proxy server 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 proxy server
rejects the requests with a METHOD DISALLOWED error. Enter each method
as a single line.
Outbound connection settings
Configure basic HTTP connection parameters between the
proxy server and content servers.
Outbound request read timeout ![[Updated in September 2012]](../../deltaend.gif)
sep2012
: The default
number of seconds the proxy server waits for a response before timing
out a request to a content server. Consider this option carefully
when changing the value.
Outbound request write timeout: The default
number of seconds the proxy server waits for a write request made
to a content server. Consider this option carefully when changing
the value. ![[Updated in September 2012]](../../deltaend.gif)
sep2012
Outbound connect timeout: The number of milliseconds that
the proxy server waits to connect to a server. If this time expires,
the proxy server attempts to connect to a different server. If no
other available servers exist, the request times out. A value of 0
indicates that the proxy server 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 proxy server to pool these connections and reuse them.
Maximum connections per server: The maximum number of connections
that will be pooled to any single content server.
- Local outbound TCP address
- Specifies the local outbound Transmission Control Protocol (TCP)
address for data that enters and exits the SIP container. The value
for this setting is the hostname or IP address to use for all communications
between the SIP proxy and the SIP containers when the network is segmented.
Information |
Value |
Data type |
String |
Default |
* |
Range |
IP address or valid host name |
![[Updated in September 2012]](../../deltaend.gif)
sep2012
The following proxy custom properties are available
to adjust the outbound connections. ![[Updated in September 2012]](../../deltaend.gif)
sep2012
- 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 the proxy
will attempt to select a new target content server for each request.
The default is 5.
- key=http.routing.sendReverseProxyNameInHost: Determines if the
proxy server 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 proxy 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 will not be appended. If the value is true, a default
via value is appended. Otherwise, the specified string via value is
appended. The default is null.
Inbound connection SSL Configuration ![[Updated in September 2012]](../../deltaend.gif)
sep2012
: Set
the SSL configuration from one of several sources:
Centrally managed |
Use the SSL configuration that is scoped for this endpoint. |
Specific to this endpoint |
Use a specific SSL configuration. |
Select SSL Configuration |
Options are NONE, CellDefaultSSLSettings, or NodeDefaultSSLSettings |
Caching
The proxy server 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:
Logging
The proxy server has logs that are generated for proxied
requests and stored cache requests. With this configuration, you can
specify the location of the proxy access log and the cache access
log.
- Access log maximum size
- Specify the maximum size, in megabytes, for an access log.
Information |
Value |
Data type |
Integer |
Units |
Megabytes |
Default |
500 |
![[Updated in September 2012]](../../deltaend.gif)
sep2012
- Proxy access log
- Specifies a directory location for a proxy access log.
Information |
Value |
Data type |
String |
Default |
${SERVER_LOG_ROOT}/proxy.log |
![[Updated in September 2012]](../../deltaend.gif)
sep2012
- Cache access log
- Specifies a directory location for a cache access log.
Information |
Value |
Data type |
String |
Default |
${SERVER_LOG_ROOT}/cache.log |
![[Updated in September 2012]](../../deltaend.gif)
sep2012
- Local access log
- Specifies a directory location for a local access log.
Information |
Value |
Data type |
String |
Default |
${SERVER_LOG_ROOT}/local.log |
![[Updated in September 2012]](../../deltaend.gif)
sep2012
Use the default location, or specify a directory location. There
is a third log called ${SERVER_LOG_ROOT}/local.log that logs
locally-served proxy content. This content does not come from the
proxy cache.
HTTP requests are logged in one of three logs: proxy, cache, and
local. Local log configuration is not currently available in the administrative
console, but it 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 National Center for Supercomputing Applications (NCSA) common
log format.
- 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: Logs all non-cache local responses, for example,
redirects and internal errors.
Proxy custom properties that can be used to tweak logging are as
follows:
- key=http.log.disableAll: This property disables all logging. A
value of true stops proxy, cache, and local logging.
- key=http.log.maxSize:The maximum log size in megabytes (MB). A
value of UNLIMITED indicates unlimited.
- key=http.log.localFileName: Contains the name of the local log.
A value of NULL indicates that the default ${SERVER_LOG_ROOT}/local.log is
used.
Security
Use this section to set up security options.
- Use a proxy-masking server header
- When selected, specifies to forward the content server's name
to the client.
- Use the backend server header
- When selected, specifies the default server name is sent as the
content server name.
- Specify a server header value
- When selected, the Server header setting
is enabled.
- Server header
- Specifies the server name that is used in HTTP responses.
- Trusted security proxies
- Specifies intermediaries other than the proxy server to handle
requests. This setting identifies which proxy servers can be trusted.
WebSphere Application Server plug-in clients
add private headers to the requests that they forward. For the proxy
server to use those headers, the request must come from one of the
trusted security proxies. If the request does not come from one of
the trusted security proxies, then those private headers are ignored
and removed from the request before the proxy server forwards the
request. Use an IP or fully qualified host name in this field. If
there are multiple IP addresses on the system where a WebSphere Application Server plug-in client
is running, then the value in the trusted list must match the IP address
of the outbound connection from that system. If you do not know the
IP address that is used on the plug-in side of the connection, you
should specify all of the IP addresses for that system to ensure that
no matter which IP address is used on the outbound connection to the
Proxy Server, that IP address matches one of the IP addresses in the
trusted list.
- Select the checkbox to enable Security proxy.
Click New or Delete to
add or remove proxies from the list.
Note: An empty list of trusted
security proxies, which is the default value, indicates that no WebSphere Application Server plug-in clients
are trusted.
Information |
Value |
Data type |
String |
Default |
Blank |
Range |
IP address or valid host name |
- Server header
- : Enables configuration of the HTTP server header that is returned
to clients. Used to suppress server information. If the value is “”,
the content server name is forwarded to client. If the value is “TRUE”,
the default server name “WebSphere Proxy”, is sent as the
content server name. If the value is anything else, the value that
is specified is sent as the content server name.
![[Updated in September 2012]](../../deltaend.gif)
sep2012
Proxy plugin configuration policy
- Generate plugin configuration: Use this parameter for the
generation of a proxy plugin configuration file that you can use on
a Web server that is deployed in front of the proxy server. The plugin
can determine the URI that the proxy is handling on behalf of the
application server. The plugin can determine the endpoint, or boundaries
of the proxy so that it can properly route requests that it receives
to the proxy. 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 proxy server.
Options are
available to define a level by which to generate the plugin, as follows:
Scope |
Description |
None |
No scope. |
All |
The proxy server generates a plugin configuration that includes
all of the URIs that are handled by proxy servers in the local cell
and all cells that are connected by a core group bridge. |
Cell |
The proxy server generates a plugin configuration that includes
all of the URIs that are handled by all the proxy servers in the cell. |
Node |
Includes all of the URIs that are configured for the node. |
Server |
The proxy server generates a plugin configuration file only
for the proxy server that is currently configured. |
- Plugin config change script: Specifies the path to a script
that is run after the WebSphere Application Server plugin
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:
-
Local error page handling: Route locally
generated error response to the application. You can handle errors
in two ways and specify error Mappings for specific error codes:
- Handle errors generated by the proxy server.
- Handle errors generated by application servers.
![[Updated in September 2012]](../../deltaend.gif)
sep2012
- Handle remote errors: When not selected, only HTTP response
error status codes generated by the proxy server are handled. When
selected, HTTP response error status codes generated by the proxy
server and HTTP response error status codes generated elsewhere after
the proxy on the proxy content server connection error responses are
handled. A best practice is to configure an error page application
on the same physical machine as the proxy server.
- 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.
- 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 that the error page policy provide a response for.
If a status code is not specified, the original content of responses
with that status code are 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
Proxy custom property to use when tweaking the custom error page: key=http.statuscode.errorPageRedirect. This
custom property determines whether error page generation is done using
the redirect, instead of using the proxy error page application. The
values are true or false. The default is false.