APAR status
Closed as program error.
Error description
Starting with v5.01, a 304 response corrupts the input stream
of the connection between the plugin and the application
server. If this stream is re-used later by another request,
then this request suffers from this corruption. If the
request is a POST request, the plugin expects a 100-Continue
header, but instead sees the uncleared input buffer from the
previous 304 response, so the request fails. Alternately, if
the request is a GET request, the plugin expects a structured
response header (for example: "HTTP/1.1 200 OK"), but instead
sees the uncleared input buffer from the previous 304 response.
.
What happens after the failure, since there is a previously
used stream being utilized, is that the request is typically
retried by the plugin, and this retry often successful on the
2nd try. Unfortunately, the app server sees and processes two
separate requests from its point of view - the first request
is successfully received by the app server but the plugin
"thinks" it had failed because it did not receive a response
in an expected manner. Thus the plugin sends a 2nd request,
which is also acted on by the app server. As a result, one
request from a client actually shows up as two requests from
the external HTTP server.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users of *
* HTTP plugin for webservers. *
****************************************************************
* PROBLEM DESCRIPTION: Starting with 5.0.1, a 304 response *
* corrupts the input stream of the *
* connection between the plugin and *
* the application server. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
Plugin was not resetting the keep alive stream when a 304
response is received.
Problem conclusion
Starting with 5.0.1, a 304 response corrupts the input stream
of the connection between the plugin and the application
server. If this stream is re-used later by another request,
then this request suffers from this corruption. If the
request is a POST request, the plugin expects a 100-Continue
header, but instead sees the uncleared input buffer from the
previous 304 response, so the request fails. Alternately, if
the request is a GET request, the plugin expects a structured
response header (for example: "HTTP/1.1 200 OK"), but instead
sees the uncleared input buffer from the previous 304 response.
.
What happens after the failure, since there is a previously
used stream being utilized, is that the request is typically
retried by the plugin, and this retry is often successful on the
second try. Unfortunately, the app server sees and processes
two separate requests from its point of view - the first request
is successfully received by the app server but the plugin
"thinks" it had failed because it did not receive a response
in an expected manner. Thus the plugin sends a 2nd request,
which is also acted on by the app server. As a result, one
request from a client actually shows up as two requests from
the external HTTP server.
Plugin is enhanced to reset the keepalive stream after
304 response is received.
Temporary fix Comments
APAR information |
APAR number |
PQ76174 |
Reported component name |
WAS BASE 5.0 |
Reported component ID |
5630A3600 |
Reported release |
00A |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2003-07-09 |
Closed date |
2003-07-18 |
Last modified date |
2003-07-18 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
Applicable component levels |
R003 PSY |
UP |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
|