Re: File Upload - \n inserts in DiskMultipartl

[SCHACHTER,MICHAEL (HP-NewJersey,ex2)]

Buenos Dias Mark,

There's been a few issues with multipart form handling, but I won't
be able to work on this stuff until middle to late next week.

This one in particular has been reported to bugzilla and will
be taken care of, thank you.

-----Original Message-----
From: Mark Takacs [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 03, 2001 7:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: File Upload - \n inserts in DiskMultiPart


  We ran into this bug when using Struts uploads on a Microsoft Excel 
spreadsheet that we are trying to run a conversion utility (xlHtml) on. 
  The Excel conversion was failing when done via upload, but not when 
done via commmand line. After some sleuthing, it looks like struts is 
clobbering the last char of  the web.xml bufferSize with a "\n" char.  

I added some details to an existing bug covering this problem.  


-tak

------

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

Using struts to handle uploaded files, if the files contain lines > 4k (or
the 
file is binary), the file data gets \n characters inserted at the 4k
boundaries 
of the long lines.



/------- Additional Comments From Tak <mailto:[EMAIL PROTECTED]> 
2001-08-03 16:33 -------/

This seems very clear-cut. At least the error, in any case. I'm looking at
the
1.0 final codebase.

The 4096 limit comes directly from the (default) value in web.xml

        <init-param>
            <param-name>bufferSize</param-name>
            <param-value>4096</param-value>
        </init-param>

Uploading a (binary) file and doing a cmp results in the following:

cmp -l /tmp/strts27203.tmp ~/myBinaryFileTest.xls
 Byte#  Oct Oct
  4097  12  57
  8194  12 144
 12291  12 142
 16388  12 145
 20485  12 156
 24582  12 147
 28679  12  55
 71584  12   0 

This sez that every 4096 bytes, a linefeed (Octal 12) is being inserted
instead
of the various original data (last column)

upload.DiskMultipartRequestHandler.java seems like a good place to start.
It pulls the
value (4096) out of the config file and (?) cuts up the input into
bufferSize'd
chunks which are stored in a Hashtable.  

Whatever is writing that hashtable back to disk is replacing the last char
of
each hashtable value with a \n and writing the file out.  Or maybe the First
char of the next block? 

I'm hoping that bumping the config file value of bufferSize is an acceptable
workaround for now...


--------