-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian,
On 10/12/2010 5:15 PM, Brian Pontarelli wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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
discarded?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky3KXEACgkQ9CaO5/Lv0PDBgACdHISg3Apuy7dLsNptoZezKkaj
uUoAoK4Jr/Pyxz8Iwf8jjlvSIBVc/O0I
=Fr5w
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
