PQ68237: WEBSPHERE V4.0 PTF4 REMOVES URI NAME ALIASES FROM PLUGIN-CFG.XMLCHANGES IT TO /* WHEN FILE SERVING ENABLED

 A fix is available

4.0.5: WebSphere Application Server Version 4.0 Fix Pack 5 (Version 4.0.5)



APAR status
Closed as documentation error.

Error description
Websphere Application Server V4.0.4
After applying PTF4 of V4.0, the plugin configuration file
 (plugin-cfg.xml) has changed.  In the URI Group, some URI
 Names are omitted and "/*" is placed instead.
......
Example of V4.0 PTF3 plugin-cfg.xml:
 UriGroup Name="xxxxxxxxxxx/xxxxxxx/xxxxx"
  <Uri Name= "*.jsp" />
  <Uri Name= "*.jsv" />
  <Uri Name= "*.jsw" />
......
Example of plugin-cfg.xml with PTF4 of V4.0
 UriGroup Name=xxxxxxxxxxxxx/xxxxxxxxx>
  <Uri Name= "/*" />
......
Prior to PTF4:
 Enabled the FileServingEnabler via AAT had no effect when
  requesting static resources via the webserver plugin.
 The original plugin regeneration code ignored the
  fileServingEnabler flag for context root of slash "/"
  and did not add the servlet mapping of "/*".
......
The reasons for this change:
 1) Different behavior when users were skipping the webserver
     and requesting URL's via the internal http transport
     ports.  The internal transport does not check the rules
     in plugin-cfg.xml when matching requests.
 2) Customers were unable to easily configure Websphere to
     handle all web content since Websphere ignored the
     FileEnablingServlet (SimpleFileServlet) for a webapp
     with a context root of "/".
......
The one reason for not making this change:
 Customers that enabled FileServing for context root of "/"
  and did not realize it was enabled.
......
Things to note:
 1) This was the case ONLY for the context root of "/".
     All other web applications will simply add the rule
     contextRoot/* if fileserving is enabled or list out each
     individual URI mapping if fileServing is not enabled.
     This makes the uri mapping rules consistent for all
      context roots instead of having a special case for the
      default context root "/".
 2) The reason for not listing each uri mapping for a
      particular context root when fileServingEnabled is to
      reduce the search path when plugins already know that if
      a request starts with "/contextRoot/" then it will be
      forwarded to Websphere for handling the request.
     If the fileServing is not enabled, each servlet mapping
      needs to be adding to the plugin-cfg.xml file to ensure
      that only those matches only handled by Websphere.
 3) If customer has a webapp with a context root of "/" with
      FileServingEnabled, the webserver will no longer service
      requests and thus make Websphere the handler of all
      requests made to that Websphere if the virtual host
      mappings are matched.
......
A quick test is to open the files /config/plugin-cfg.xml and a
 WEB-INF/ibm-web-ext.xmi file from one of the installed web
 modules.  In the ibm-web-ext.xmi file, add "false" for the
 value of fileServingEnabled.  Save the file and regen the
 plugin.  All of the URI's will show up (contextRoot/*.jsp,
 contextRoot/*.jsv, contextRoot/j_security_check, etc).

Next, change the value of fileServingEnabled to "true", save
 the file, and regen the plugin.  All the URI's will change
 to a single contextRoot/*.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: The users of WebSphere Application Server    *
*                 Version 4.0.5 and above.                     *
****************************************************************
* PROBLEM DESCRIPTION: After applying WebSphere Application    *
*                      Server Version 4.0.4, the plug-in       *
*                      configuration file (plugin-cfg.xml)     *
*                      is changed. This change results in      *
*                      some URI names being omitted and a      *
*                      "/*" is placed in the URI group         *
*                      instead.                                *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
If you have a Web application with the context root of a "/"
with FileServingEnabled, the Web server no longer requests
service and thus makes WebSphere Application Server the
handler of all requests if the virtual host mappings are matched
Problem conclusion
Close this APAR as a documentation change
(V405 release notes)
Temporary fix Comments
APAR information
APAR number PQ68237
Reported component name WEBSPHERE AE SO
Reported component ID 5630A2202
Reported release 400
Status CLOSED DOC
PE NoPE
HIPER NoHIPER
Submitted date 2002-11-14
Closed date 2002-11-22
Last modified date 2002-11-22

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

SRLS

Fix information

Applicable component levels


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ68237
IBM Group: Software Group
Modified date: Nov 22, 2002