Take a look at http://jakarta.apache.org/site/getinvolved.html for
information about contributting to Jakarta projects. Specifically, use
the -u option for generating diffs and send the diffs as attachments instead
of inline.
Could you explain a little more what these diffs accomplish? My
understanding of the fix that went into revision 1.5.2.4 to fix the file
upload problem was that doRead() returns an 'int' and was causing the byte
0xFF to be sign extended into the integer -1 which is the EOF return value
for doRead(). The byte array version of doRead() should only return -1 if
there really isn't any more data. The actualy contents of the bytes read,
because they aren't interpretted, don't matter at all.
I don't see how the byte array returned is any different in the patched
version then what it was before. Converting a byte into a char and then
masking off all but the lowest 8 bits and then turning the results back into
a byte looks like a no-op to me.
> -----Original Message-----
> From: DAK [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 16, 2001 10:59 PM
> To: [EMAIL PROTECTED]
> Subject: Servlet Upload Data Corruption
>
>
> Here's my first submission! It pertains to Tomcat-3.2.1 and looks to be
> the same in 3.2.2.b4
>
> 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 may be called a developer now, but I'm certainly not a
> commiter, so what is the procedure for getting this fix validated by
> somebody else and put into the codebase?
>
> Index: Ajp13ConnectorRequest.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service
/connector/Attic/Ajp13ConnectorRequest.java,v
> retrieving revision 1.5.2.7
> diff -r1.5.2.7 Ajp13ConnectorRequest.java
> 274c274,277
> < System.arraycopy(bodyBuff, pos, b, off, c);
> ---
> > //System.arraycopy(bodyBuff, pos, b, off, c);
> > for (int i=pos, j=off, d=c; d > 0; i++, j++, d--) {
> > b[j] = (byte)(((char)bodyBuff[i])&0xff);
> > }
>
> What I've done here is to replace the array copy with a loop that does
> the appropriate data conversion.
>
>
> Index: Ajp12ConnectionHandler.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service
/connector/Attic/Ajp12ConnectionHandler.java,v
> retrieving revision 1.28.2.4
> diff -r1.28.2.4 Ajp12ConnectionHandler.java
> 542a543,549
> > public int read(byte b[], int off, int len) throws IOException {
> > int ret = super.read(b, off, len);
> > for (int i=0, j=off; i<len; i++, j++) {
> > b[j] = (byte)(((char)b[j])&0xff);
> > }
> > return ret;
> > }
>
> In this case, I over-rode the read method to convert the data after
> calling the super.read
>
>
> I'd like to see this stuff end up in 3.2.2.b5
>
>
> Thanks,
> David Kavanagh
