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 fixProblem 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 fixComments
APAR information | APAR number | PQ49615 | Reported component name | WEBSPHERE AE SO | Reported component ID | 5648C8400 | Reported release | 350 | Status | CLOSED | PE | NoPE | HIPER | NoHIPER | Submitted date | 2003-03-03 | Closed date | 2003-03-03 | Last modified date | 2003-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 APAR is sysrouted TO one or more of the following:Modules/Macros
|
Fix information |
Fixed component name | WEBSPHERE AE SO | Fixed component ID | 5648C8400 |
Applicable component levels | R400 PSY | UP |
|