commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [Fileupload] Missing character in the middle of a file
Date Thu, 14 Oct 2010 16:01:53 GMT
Hash: SHA1


On 10/12/2010 5:15 PM, Brian Pontarelli wrote:
>> Hash: SHA1
>> Brian,
>> On 10/4/2010 11:43 AM, Brian Pontarelli wrote:
>>> I figured that the original File and the File written out by the
>>> FileUpload would have different bytes at the start or end and it was
>>> my mock input stream that was causing the issue. To test this theory
>>> I opened both files in a HEX editor. What I found was that the files
>>> differ by one a single byte and that byte is at position 305. The
>>> other interesting thing I found was that the byte that exists in the
>>> original and is missing from the FileUpload file is 'FF'.
>> That's weird. Is the missing byte always at position 305? What variety
>> of "test" files have you tried? Is it always 0xff that gets discarded?
>> Could you post some of your test driver code, and some of the servlet
>> code so we can see how they interact?
> I'm back from my travels and wanted to circle back on this thread.
> There is quite a bit of code for all of this stuff, but I'll post some
> of it. I'm going to post the code we use to create the multipart request
> and some unit test code we use to test it all:

Your MultipartInputStream looks good to me at first reading. I forgot
how verbose multipart messages were :)

Can you dump your ByteArrayOutputStream after building it, just to see
if the message it will (ultimately) send it legit?

What is the CLOSE_BOUNDARY being used for? I don't believe you need that
at the end of your stream. Also, where does the part of the message come
from that has "Content-Type: multipart/form-data"? Is that external?

Have you compared the message you send to your test server with, for
instance, the message that a web browser such as Firefox will send?

>     @Override
>     public int available() throws IOException {
>         return bytes.length;
>     }

This might not be correct, although it likely does not have an effect on
your code.

>     public int read() throws IOException {
>         if (index == bytes.length) {
>             return -1;
>         }
>         return bytes[index++];
>     }

I might check for index >= bytes.length, though it also shouldn't be a
problem: you'd be getting an ArrayIndexOutOfBoundsException if this were
a problem.

>     byte[] orig = read(new File("src/java/test/unit/org/jcatapult/servlet/test.jar"));
>     byte[] read = read(file);
>     assertEquals(orig.length, read.length);

So, the above call fails because the files are 1 byte different?

>     for (int i = 0; i < orig.length; i++) {
>         assertEquals("Byte at index " + i + " was invalid", orig[i], read[i]);
>     }

Without the length check, you get "invalid" starting at index 301 and
continuing to the end of the file?

I have to ask again: Is the missing byte always at position 305? What
variety of "test" files have you tried? Is it always 0xff that gets

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message