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=31175>.
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=31175

Problems uploading image file using multipart form request

           Summary: Problems uploading image file using multipart form
                    request
           Product: Commons
           Version: 1.0 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: File Upload
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


I am using the FormFile object that comes with Jakarta Struts to upload an 
image file as part of a multipart request form. The FormFile class in turn uses 
the FileItem interface (DefaultFileItem implementation) of the commons-
fileupload package. My poking around seems to indicate that the issue resides 
in the MultipartStream class, hence this bug report. Let me explain the problem:

I have been experiencing problems wherein image files uploaded using the 
FormFile class seem to get 'corrupted'. My first step in looking into this 
issue was to get the byte array from the FormFile and compare it byte by byte 
with the byte array obtained by openning the file directly using a 
FileInputStream. Doing so I determined two facts: 1) the length of the byte 
arrays were different, the one obtained from the FormFile was smaller by 
exactly the 'keepRegion' variable amount in the 'MultipartStream' class in the 
commons-fileupload package. 2) The contents of the byte arrays would differ at 
either the first or second boundary written to the output buffer in 
the 'readBodyData' method of the 'MultipartStream' class. In other words, the 
bytes were identical up to the value of 'tail - head - pad' of either the first 
iteration through the loop in the 'readBodyData' method, or the second 
iteration. In my case it happened to be at either byte 3777 (4096 - 276 - 43) 
or byte 7282 (3777 + (3548 - 0 - 43)), respectively. This problem does not 
occur with every image file I try to upload, but once I find an image file it 
does occur with, it is reliably reproducable every time. I have verified that 
the image is not corrupt, and I am able to open the file and successfully 
process the file by opening it directly using a FileInputStream, so I am fairly 
confident the issue is not directly related to the file itself.

I will continue to work through this issue to see if I can provide any 
additional information, but this is what I know now.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to