Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: 16 Jan 2004 14:05:36 -0000
Message-ID: <20040116140536.15674.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 26194] New:  -
    The common upload functions do not work on z/OS WebSphere

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