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: --Boundary ... --Boundary ... --Boundary-- That's part of the multipart specification. (http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2) 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: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 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. -bp --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
