PQ59244: BROWSER DISPLAYS "INTERNAL SERVER ERROR" WHEN CONTENT-LENGTH RESPONSE HEADER IS SET INCORRECTLY | |||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||
APAR status Closed as program error. Error description A servlet sets the Content-Length response header to the uncompressed length of the response message body. However, if the request arrived with an Accept-Encoding header asking for a compressed message body (i.e., gzip, compressed), then the Content-Length set to the uncompressed message body length is incorrect. This results in the HTTP plugin raising an HTTP error 500 (i.e., Internal Server Errror) because the Content-Length does not match the actual length of the compressed message body. . The HTTP 1.1 specification indicates that the Content-Length response header should not be set when the message body is encoded. WebSphere Application Server should not allow a servlet to set Content-Length in the response header when the message body is compressed.Local fix Modify the servlet so that it sets the Content-Length response header only if the request does not ask for a compressed message body in the response.Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * 4.0.x using the content-encoding and * * content-length header together. * **************************************************************** * PROBLEM DESCRIPTION: There is no way to accurately set the * * content-length header when sending * * compressed data. Customer's servlet * * is setting the content-length based on * * the files original length which is * * going to always be wrong for compressed * * data. * **************************************************************** * RECOMMENDATION: * **************************************************************** The following logic was used to determine what encoding should be used to transmit the data. A compression method is selected depending on the client's accept-encoding header. <cust logic> Object obj = null; String s6 = req.getHeader("Accept-Encoding"); if(s6 != null && s6.indexOf("gzip") != -1) { res.setHeader("Content-Encoding", "gzip"); obj = new GZIPOutputStream(res.getOutputStream()); } else if(s6 != null && s6.indexOf("compress") != -1) { res.setHeader("Content-Encoding", "compress"); obj = new ZipOutputStream(res.getOutputStream()); ((ZipOutputStream)obj).putNextEntry(new ZipEntry("a name")); } else obj = res.getOutputStream(); res.setHeader("Content-Length",Long.toString(file.length())); </cust logic> The content-length header can only be set accurately by the servlet in case #3 (else) because the client does not have an accept-encoding header. file.length() will return the file's original length, ignoring any type of compression. If case #1 or #2 (if & else if respectively) is selected, setting the content-length to the original file length will cause an internal server error to be displayed. The servlet should not set the content-length header at all because WebSphere will always calculate the proper value for the transmitted data, compressed or uncompressed.Problem conclusion Modified WebSphere to disallow the coexistance of a content-length header and a content-encoding header in the same response. Since WebSphere will always calculate the correct value of the content-length automatically, the code will ignore the value the servlet has tried to set.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ59244
IBM Group: Software Group
Modified date: May 16, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.