Fix for tomcat WarpConnector 0xFF-Bug

[Philipp Klaus <to...@pylonsoft.ch>]

Hi,

please find attached a fix for an bug in the WarpConnector of Tomcat4. I
had the problem that when uploading a picture (JPG) using a HTML form
(with <input type="file"> tag) I got broken pictures on the server.
After comparing the two files (locally and on the server) I realized the
version on the server lost all 0xff bytes. They were simply stripped
off, all other content was correctly transfered. After investigating in
the C code of mod_webapp I had to move over to the JAVA code of the
WarpConnector. There I found a code part which simply coerced the
received byte to an int. Both are signed numeric values so the ASCII
character 255 is converted to the integer -1. This -1 is a special value
meaning end of stream. The attached code changes this behaviour.

Hope you can integrate this in the main distribution.

Philipp

Re: Fix for tomcat WarpConnector 0xFF-Bug

[Pier Fumagalli <pi...@betaversion.org>]

Philipp Klaus at tomcatml@pylonsoft.ch wrote:

> Hi,
> 
> please find attached a fix for an bug in the WarpConnector of Tomcat4. I
> had the problem that when uploading a picture (JPG) using a HTML form
> (with <input type="file"> tag) I got broken pictures on the server.
> After comparing the two files (locally and on the server) I realized the
> version on the server lost all 0xff bytes. They were simply stripped
> off, all other content was correctly transfered. After investigating in
> the C code of mod_webapp I had to move over to the JAVA code of the
> WarpConnector. There I found a code part which simply coerced the
> received byte to an int. Both are signed numeric values so the ASCII
> character 255 is converted to the integer -1. This -1 is a special value
> meaning end of stream. The attached code changes this behaviour.
> 
> Hope you can integrate this in the main distribution.

Right when I was fixing it :) Actually, there's a bug in your patch... All
negative values are sign-extended in casting, so, it's better to return the
value ANDed with a 0x0ff... It doesn't affect it if you actually save bytes
to disk (since that value is re-ANDded in java.io), but the integer values
coming out will not be correct...

    Pier