commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: [Fileupload] Missing character in the middle of a file
Date Thu, 14 Oct 2010 17:22:58 GMT
At first I thought the lengths were different, but that was actually in a much more complex
set of tests. I wrote the test code below after my first post to the list.

Here's what that code is doing:

The lengths are the same, but the byte at position 305 is -1 rather than -66.

The answers to your other questions are inline:

> 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?

The close boundary closes the body. It is the boundary plus -- like this:


That's part of the multipart specification. (

The content type is set in the MockHttpServletRequest object. That code is rather long, so
I didn't post it. It is also slightly messy because that is a mock. If you add files to the
mock, it sets the content type to multipart/form-data.

> 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?

No. I could write a simple HTTP server and spit out the InputStream bytes just to see. My
only concern would be if Firefox is using a multi-boundary stream or something else that is
allowable in the specification but not required.

>>    @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.

It should be correct if the headers aren't part of the length, which I believe they aren't:

This is the length of the entity-body (message body), which should be the length of the multipart/form-data
bytes I'm creating. But like you said, it shouldn't matter much.

>>    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?

No. That was my original issue, but this code doesn't fail here. It fails in the loop.

>>    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?

No. The assert fails and then the loop stops. The invalid byte is at position 305.

> 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
> discarded?

I'll try some other binary files now to see how they go.


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

View raw message