Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0 Final
-
None
-
None
-
Operating System: other
Platform: Other
-
26194
Description
The FileUploadBase class uses the default platform encoding when getting the
content-type header attribute in order to determine the boundary value for a
multi-part request.
Method public List parseRequest(HttpServletRequest req) ::
...
String contentType = req.getHeader(CONTENT_TYPE);
...
byte[] boundary = contentType.substring(boundaryIndex + 9).getBytes();
This does not work on z/OS Websphere 4 (and maybe on other platforms) because
the request encoding is not similar to the platform encoding (CP1047) and thus
the corresponding bytes are not the same. As a consequence, the FileUpload
class does not find any request "parts", because the MultiPartStream class
performs a search on binary data with the wrong (local platform) bytes (see
findSeparator method).
This can be corrected by adding an encoding parameter to the getBytes() method
in the FileUploadBase class :
byte[] boundary = contentType.substring(boundaryIndex + 9).getBytes("ISO-8859-
1");
(This happens twice in this class)
Maybe I missed something but I think a server cannot determine the encoding
used by the browser to build the request headers, so this cannot be dynamically
setup during runtime. I would think the only "reasonable" way would be to use
the "headerEncoding" optional member :
byte[] boundary = null;
if (getHeaderEncoding() != null)
boundary = contentType.substring(boundaryIndex + 9).getBytes
(getHeaderEncoding());
else
boundary = contentType.substring(boundaryIndex + 9).getBytes();
Philippe.