DO NOT REPLY [Bug 28613] New: - Multipart data corrupts as CommonsMultipartRequestHandler does not set headerEncoding

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28613>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28613

Multipart data corrupts as CommonsMultipartRequestHandler does not set headerEncoding

           Summary: Multipart data corrupts as
                    CommonsMultipartRequestHandler does not set
                    headerEncoding
           Product: Struts
           Version: 1.1 Final
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: File Upload
        AssignedTo: dev@struts.apache.org
        ReportedBy: ianwark@hotmail.com


When the character encoding in the request does not match the default encoding 
of the server in which Struts is contained the file upload API is unable to 
extract non-ASCII information from the request (e.g. Japanese writing). For 
example, inputting a file name into a Windows PC browser (e.g. Windows-31J) 
that goes to a Linux (or other UNIX)  web server (EUC-JP) with Struts.

Depending on exactly what combination of characters are used for the file name, 
the file name may simply become corrupted (garbage string) and then the file 
upload takes place normally, or, in a worst case scenario, corrupted 
information from the request will continue along until in BeanUtils you get an 
IllegalArgumentException from the Reflection API and Struts crashes. 
Information extracted prior from the request cannot be set into the Form beans 
because the number of parameters are incorrect. This occurs for single byte 
kana writing in odd byte combinations at the end of the string (and in some 
other instances).

The exception occurs on line 1019 in the BeanUtils.class where the property is 
set. (Of course, this problem has nothing to do with BeanUtils). [If someone 
wants the stack trace I can reproduce it on my Windows PC using Vmware with 
Linux (with some trouble). The encoding in Linux is set to EUC-JP.]

A simple solution to the problem might be the following. Just set the header 
encoding to the request character encoding. Below I have added this one line to 
the source in CommonsMultipartRequestHandler and this works perfectly. In our 
case we set the character encoding to Windows-31J in the JSP.

(extract from CommonsMultipartRequestHandler.java)

        // Create and configure a DIskFileUpload instance.
        DiskFileUpload upload = new DiskFileUpload();
        // Set the maximum size before a FileUploadException will be thrown.
        upload.setSizeMax((int) getSizeMax(ac));
        // Set the maximum size that will be stored in memory.
        upload.setSizeThreshold((int) getSizeThreshold(ac));
        // Set the the location for saving data on disk.
        upload.setRepositoryPath(getRepositoryPath(ac));
        // Set the header encoding to that of the request header
        upload.setHeaderEncoding(request.getCharacterEncoding());

        // Create the hash tables to be populated.
        elementsText = new Hashtable();
        elementsFile = new Hashtable();
        elementsAll = new Hashtable();

FWIW, this problem has been around a long time. There is even a website in 
Japan that offers a workaround for the problem without touching the Struts 
source. But the solution the author offers is very complex.

see the multipart filter at the below address
http://kvasir.skirnir.net/software/java/java00015.ksd

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