PQ81698: BROKEN ESI COMPONENT (SURROGATE-CONTROL HEADER) IN SIMPLEFILESERVLETIN ALL RELEASES OF WEBSPHERE 4.0

 A fix is available

PQ81698: WebContainer used a wrong key to check for surrogate capability



APAR status
Closed as program error.

Error description
We have broken ESI component in SimpleFileServlet in all
WebSphere releases.
There are cases, when customers need to configure WebSphere
5.0 plugin with WebSphere 4.0 Application server.  WebSphere
5.0 plugin can cache thru its ESI cache component static pages
returned by the WebSphere AppServerin case, that
Surrogate-Control http header is present in the response.
Static content in WebSphere is handled by SimpleFileServlet,
but unfortunately, the piece of the code that supposed to set
Surrogate-Control header on the response is broken & this
header is never being set.  The Surrogate-Control http header
suposed to be set in case, that the http request contains
Surrogate-Capability http header & the resource is not secured
by WebSphere security component.
.
Here is the piece of the code that needs to be changed in
SimpleFileServlet:
In file SimpleFileServlet.java, doGet method:
.
        // Add ESI control header
          if (req.getHeader ("Surrogate-Capabilities") != null
        // PQ81206 begin
          && (req.getAuthType() == null)
        // PQ81206 end
           ) {
              resp.addHeader ("Surrogate-Control",esiControl);
             }
.
This line is causing the problem, resulting that
Surrogate-Control http header is never being set:
if (req.getHeader ("Surrogate-Capabilities") != null
.
WebSphere 5.0 plug-in sets Surrogate-Capability and not
Surrogate-Capabilities http header, so this problem needs to
be fixed in SimpleFileServlet code.
.
The piece of the code that I included contains also security
exposure fix PQ81206.  This APAR (PQ81206) was cancelled because
there was not any security exposure defect in WebSphere 4.0
because ESI was broken completely & it never worked.  So please,
if you fix Surrogate-Control issue in WebSphere 4.0, in the same
APAR fix also the security exposure that is described in the
APAR PQ81192 for WebSphere 5.0 or cancelled APAR PQ81206.
If you did not do it, the WebSphere 4.0 with WebSphere 5.0
plugin would be exposed immediately to this security exposure.
.
We need to fix this broken ESI cache component in WebSphere
4.0.6, 4.0.7 & all future WebSphere 4.0.x releases, because
many of our customers configured WebSphere 4.0 with WebSphere
5.0 plug-in & they can benefit from caching static pages by
ESI cache component in the plug-in.  Today they do not have
this possibility so the performance for serving static content
that is not being secured by WebSphere Security component is
degraded.
Local fix
Not available.
Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users using ESI *
*                 to cache static content.                     *
****************************************************************
* PROBLEM DESCRIPTION: The webContainer checked for            *
*                      "Surrogate-Capabilities" keyword in the *
*                      response header which is incorrect.     *
*                      The correct header keyword should be    *
*                      "Surrogate-Capability"                  *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
In order to enable ESI to cache static content, the webContainer
has to add "Surrogate-Control" keyword to the response header.
The webContainer code first checked the response header to see
if "Surrogate-Capabilities" keyword is present before adding the
"Surrogate-Control" keyword.  However, in V4, the correct
keyword to check should be "Surrogate-Capability" instead of
"Surrogate-Capabilities".  As a result, the checking always
failed, and ESI caching was not enabled.
Problem conclusion
In order to fix this, problem, the webContainer code was changed
to check for "Surrogate-Capability" header.
Temporary fix
*********
* HIPER *
*********
Comments
APAR information
APAR number PQ81698
Reported component name WEBSPHERE AE AI
Reported component ID 5630A2200
Reported release 400
Status CLOSED PER
PE NoPE
HIPER YesHIPER
Submitted date 2003-12-04
Closed date 2004-02-18
Last modified date 2004-02-18

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
ENGINE          

SRLS

Fix information
Fixed component name WEBSPHERE AE AI
Fixed component ID 5630A2200

Applicable component levels
R400 PSY UP    PQ81698


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ81698
IBM Group: Software Group
Modified date: Feb 18, 2004