HttpServletRequest InputStream corrupted?

Question

I'm receiving a SOAPMessage over a java servlet with an attachmentpart containing a multipart mime. Doing this:

 InputStream inputStream = request.getInputStream();           
 byte[] data = IOUtils.toByteArray(inputStream);

 File file = new File("/usr/local/user/message.txt");
 FileOutputStream fos = new FileOutputStream(file);
 fos.write(data);
 fos.close();

Gives me corrupted data for the binary code in the multipart mime. Anyone knows why this is happening? I copied the binary data to a file and changed the file extension to the appropriate image extension but I'm getting a corrupted image. Comparing hexadecimal data of message.txt and a .snoop file shows that there are slight differences in the hexadecimal data causing the distortion. There were no changes in the ASCII data. Thanks.

There is distortion, as in you can see the picture looks correct at the start, but it starts looking weird after a while because the hexadecimal values are wrong. For example: 06 04 04 04 04 04 06 04 04 06 0a from the client becomes 06 04 04 04 04 04 06 04 04 06 0D after I do the above.

"Comparing hexadecimal data of message.txt and a .snoop file shows that there are slight differences in the hexadecimal data causing the distortion". Can you expand upon these distortions. Also, if you have the network snoop/capture, can you update the question with the Content-Encoding header sent by the client? — Vineet Reynolds, Jun 17 '11 at 09:37
Content-Encoding not sent, so assuming it's binary. Distortion as in you can see the picture looks correct at the start, but it starts looking weird after a while because the hexadecimal values are wrong. For example: 06 04 04 04 04 04 06 04 04 06 0a from the client becomes 06 04 04 04 04 04 06 04 04 06 0D after I do the above. — Maurice, Jun 17 '11 at 09:46
0A is LF and 0D is CR. I think this is a problem with unix vs windows line endings. — Vineet Reynolds, Jun 17 '11 at 09:52
What is happening is I'm writing the file into a Linux System. Using WINSCP I copy the file over to a windows machine to view it. Will this cause a change in the data? It's not just the 0A and 0D, some other data changes as well then they look the same again for a while. — Maurice, Jun 17 '11 at 09:58
Likely (given that you are naming the file as `.txt` originally). Read [this FAQ](http://winscp.net/eng/docs/transfer_mode) in the WinSCP site. **Edit:** Use the binary mode to transfer and see if there's a difference. — Vineet Reynolds, Jun 17 '11 at 10:00
Ok it works on the MAC OS! Is there something I must set in WINSCP? — Maurice, Jun 17 '11 at 10:16

score 1 · Accepted Answer · edited May 23 '17 at 12:12

Based on the comments, it appears that the file is being written to disk correctly (that is my interpretation).

WinSCP is used to transfer the file from the (Linux/Unix) machine to a Windows machine. The mode of transfer employed in the transfer process could result in WinSCP converting all unix-style line endings to Windows-style line endings, or vice-versa depending on where the transfer originated from. This occurs when text mode is employed to transfer the file, or when WinSCP is allowed to determine whether it should use the text or binary mode to transfer the file. You might have set it to the default mode, so force the file to be transferred in binary; if this hasn't worked, you'll need to investigate further.

If WinSCP appears to be the cause of this problem, you could confirm it, by viewing the binary contents of the files on both platforms. You could use xxd on Linux/Unix. On Windows, one of the utilities listed in this question will help.

You may also use any other file copy protocols like FTP, SFTP or even use NFS or Samba to transfer the files, and establish WinSCP to be the cause.

score 0 · Answer 2 · answered Jun 17 '11 at 09:47

0

For multipart MIME you can use Apache Fileupload library. you can find it here :

Apache Fileupload download path

Starter tutorial

answered Jun 17 '11 at 09:47

Asad Rasheed

518
5
13

Have you read the question? The OP is referring to discrepancies in parsing the request on the server-side, not how to parse the request. Besides, multipart post uses base64 encoding, and not binary attachments. – Vineet Reynolds Jun 17 '11 at 09:49

HttpServletRequest InputStream corrupted?

2 Answers2