PI33453: CHUNKED REQUEST MIGHT FAIL TO RECEIVE ALL RESPONSE CAUSED BY DELAYED LAST CRLF.

Fixes are available

APAR status

Closed as program error.

Error description

The request with the chunked transfer encoding should end
with CRLF after the last-chunk (RFC 2616). If the last CRLF is
delayed and arrives at the Application Server while it is
sending the response back to the client, the TCP session will be
disconnected and the client cannot receive all responses.

Local fix

Use the request with non-chunked transfer encoding at the client
side. The HTTP transport policy "Enable chunked transfer
encoding" sets to false if the client is a Web Service Requester
on WebSphere Application Server.

Problem summary

****************************************************************
* USERS AFFECTED:  IBM WebSphere Application Server Version    *
*                  7.0, 8.0, and 8.5.5 users                   *
****************************************************************
* PROBLEM DESCRIPTION: For chunked encoded requests, if data   *
*                      is sent after the end of body           *
*                      sequence 'CRLF 0 CRLF' is read, the     *
*                      connection is closed immediately with   *
*                      an RST packet.                          *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
According to section 3.6.1 of the HTTP 1.1 specifications
document, RFC-2616, "chunked encoding is ended by any chunk
whose size is zero, followed by the trailer, which is
terminated by an empty line". The RFC also specifies that
the trailer is optional. That is, the end of message is
considered to be the end of body, denoted by 'CRLF 0 CRLF'
followed by an OPTIONAL trailer (whose end is denoted by
'CRLF'). However, if the end of body was reached and no further
data had been provided at the moment, the HTTP Channel would
begin servicing the response. This causes problems if
additional data arrives for this same connection. In
persistent connections, the additional data would be
wrongfully recognized as another request; whereas in
non-persistent connections, the transmission would be abruptly
terminated with an RST packet if the peer had not finished
reading by this time.

Problem conclusion

The HTTP Channel code was modified to wait for the end of
message before declaring that the request has been fully read.
To enable this behavior, a new custom property was added to
the HTTP Channel. The property name is 'WaitForEndOfMessage'
with possible values of 'true|false' (default:false).

An HTTP Channel custom property can be set like this:

http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.i
bm.websphere.nd.doc/ae/rrun_chain_httpcustom.html?cp=SSAW57_8.5.
5%2F1-18-6-409&lang=en

Note: the instructions are for v8.5.5, but the same
instructions apply to all versions of WebSphere
Application Server Full Profile

The fix for this APAR is currently targeted for inclusion in
fix packs 8.5.5.6, 8.0.0.11, 7.0.0.39.  Please refer to the
Recommended Updates page for delivery information:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980

Temporary fix

Comments

APAR Information

APAR number
PI33453
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-01-26
Closed date
2015-03-03
Last modified date
2015-03-03

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

Fix information

Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800

Applicable component levels

R700 PSY
UP
R800 PSY
UP
R850 PSY
UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 April 2022

Tips

PI33453: CHUNKED REQUEST MIGHT FAIL TO RECEIVE ALL RESPONSE CAUSED BY DELAYED LAST CRLF.

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Fix information

Fixed component name

Fixed component ID

Applicable component levels

R700 PSY

R800 PSY

R850 PSY

Document Information

Share your feedback

Need support?