PQ49615: WEBSPHERE PLUGIN MALFUNCTION IN A LOAD-BALANCER CONFIGURATION

A fix is available
WebSphere Application Server Version 3.5 Fix Pack 7 (3.5.7)

APAR

APAR status
Closed with unknown close code.

Error description
Problem:
This problem con occur in any configuration where the port of an
incoming web request is mapped to a different port before
reaching the webserver.  When this happened, the iPlanet plugin
would use the wrong port number for URI matching - it would use
the port the webserver was listening on rather than the port in
the Host header of the HTTP request.  URI matching could be
forced to succeed by adding the webserver's port to the vhost
list, but this would still fail if the customer's servlet/jsp
did a sendRedirect() on a relative URI.  ( it would build an
absolute uri with the wrong port number ).  The iPlanet plugin
needs to be changed to use the port number specified in the Host
header, if it exists.
Problem:This problem con occur in any configuration where the port of anincoming web request is mapped to a different port beforereaching the webserver. When this happened, the iPlanet pluginwould use the wrong port number for URI matching - it would usethe port the webserver was listening on rather than the port inthe Host header of the HTTP request. URI matching could beforced to succeed by adding the webserver's port to the vhostlist, but this would still fail if the customer's servlet/jspdid a sendRedirect() on a relative URI. ( it would build anabsolute uri with the wrong port number ). The iPlanet pluginneeds to be changed to use the port number specified in the Hostheader, if it exists.
Local fix
Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users with      *
*                 certain configurations of load balancer in   *
*                 front of the web server.                     *
****************************************************************
* PROBLEM DESCRIPTION: WebSphere redirects go to the wrong     *
*                      port - they go to the web server port   *
*                      rather then the load balancer port.     *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
In some situations, the websphere plugins were defaulting
to the wrong port number for requests.  Instead of using
the port number in the Host header ( when it is available ),
we would default to the port the webserver was listening
on.  This works in most cases, but it will break
sendRedirect() on systems with particular configrations
of load balancers before the web server.  ( any setup
where the load balancer port is different than the ports
of the webservers it serves to ).  When this occurs, the
user will see redirects trying to use the webserver port
rather than the load balancer port.
Problem conclusion
Changed the behavior of the WebSphere plugins so we use
the port from the host header when it's availble, only
defaulting to the server port when no Host header is
available.
Temporary fix
Comments
APAR information
APAR numberPQ49615
Reported component nameWEBSPHERE AE SO
Reported component ID5648C8400
Reported release350
StatusCLOSED
PENoPE
HIPERNoHIPER
Submitted date2003-03-03
Closed date2003-03-03
Last modified date2003-03-17

APAR is sysrouted FROM one or more of the following:
PQ62683

APAR is sysrouted TO one or more of the following:APAR is sysrouted FROM one or more of the following:PQ62683


Modules/Macros
PLUGIN
APAR is sysrouted TO one or more of the following:Modules/Macros

Fix information
Fixed component nameWEBSPHERE AE SO
Fixed component ID5648C8400

Applicable component levels
R400 PSYUP











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, General
Software version: 350
Reference #: PQ49615
IBM Group: Software Group
Modified date: 2003-03-17