commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26194] New: - The common upload functions do not work on z/OS WebSphere
Date Fri, 16 Jan 2004 14:05:36 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26194>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26194

The common upload functions do not work on z/OS WebSphere

           Summary: The common upload functions do not work on z/OS
                    WebSphere
           Product: Commons
           Version: 1.0 Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: File Upload
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: philippe.eymann@cie.etat.lu


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.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message