David,
Thanks for the example code. I tried this on the following configurations
and was not able to duplicate the problem.
Win2000
Tomcat 3.2.2b5
Apache 1.3.19
mod_jk (both ajp12 and ajp13)
As the jar file to transfer I JARed up the entire examples web application
directory tree. That contains text files, GIF images, and .class files. I
tried using Tomcat stand-alone and through Apache/mod_jk using both AJP12
and AJP13. If you'd like to send me a JAR file that causes you problems I
can try it out.
I still don't see how the proposed patches would have any impact on the
outcome. To test this I wrote a simple Java application simply ran through
all possible byte values and did your char/mask/byte translation and then
tested if the result was different than the original value. It never was.
I'm not saying that you aren't seeing something go wrong, I just can't see
what it is yet.
> -----Original Message-----
> From: DAK [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, May 19, 2001 11:24 PM
> To: [EMAIL PROTECTED]
> Subject: upload data corruption report
>
>
> I've been asked to provide more information, so here is combination of
> the two messages I posted with some more commentary and attachments.
>
> It pertains to Tomcat-3.2.1 and looks to be the same in 3.2.2.b4. I'm
> running Apache 1.3.17 on Win 2K Professional. I'm also using mod_jk
>
> I have some client code that sends a jar file to the servlet. The jar
> file was getting corrupted. After much digging, I found a CVS commit to
> Ajp13ConnectorRequest.java that mentioned a problem like this with the
> doRead() method. It turns out the the same applies to the doRead(byte[],
> int, int) method. The same problem exists in the Ajp12ConnectionHandler
> for that byte array read. Single byte reads for both protocols work just
> fine. I'm including the diffs for these classes to show what I'm talking
> about.
>
>
> I finally got out from under some work and was able to make some test
> code. I'm attaching the client and servlet code.
> The code transfers a couple parameters, then a binary file (I was using
> a .jar). If you call the client with
> "BinTestClient localhost something.jar b", it uses byte-by-byte read on
> the server to spool the file to a temp file. If you call the client
> without the 'b', it uses the byte-array read that I was complaining
> about. Transfer a file, then try "jar tvf testXXXX.jar" to see if it
> works. I uses a jar that contains .jpg images and when using the byte
> array read method, it creats a corrupt jar file. If I apply my fix to
> the Ajp13ConnectorRequest class, it works fine.
> (I tried a jar that contained class files and it worked anyway...)
> I'd like for someone else to try this out to make sure I didn't screw
> something up. The code seems pretty simple.
> I discovered this when using JarIn/OutputStream to transfer data from
> client to servlet.I've seen this type of thing in Java before when
> writing code that talks to hardware (such as touchscreen driver and
> scanner drivers).
>
> David
>
>
