tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/
Date Wed, 27 Feb 2008 19:51:00 GMT
Bill Barker wrote:
> "Remy Maucherat" <> wrote in message 
>> Filip Hanik - Dev Lists wrote:
>>> Test Case and 5.5.x patch can be found here.
>>> This is what is happening
>>> int result, 0, BUFFER_SIZE );
>>> is called with a "while (true)" statement,
>>> When the returns -1, the above statement 
>>> returns cnt==1.
>>> So to avoid calling, we must check to see if we have more bytes 
>>> to read by implementing the available() method, to avoid the inputstream 
>>> ever returning -1.
>> It's possible, but I have a hard time understanding the issue.
> The issue is that InputStreamReader reads 8192 bytes from 
> IntermediateInputStream on the first go.  It then translates them into 2734 
> chars, but thinks that the last few bytes represent an incomplete char, so 
> holds onto them.  On the next call, IntermediateInputStream returns -1, so 
> InputStreamReader outputs the last char as best it can (resulting in 
> returning 1).  Then the IntermediateInputStream buffer is reset, and it can 
> continue on reading (but from the wrong position, resulting in corruption).
> Filip's patch is inelegant (better would be to use the ByteChunk sink), but 
> other than my looking for a better way to do it, I can't come up with the 
> required technical reason to porting the base of it to 5.5 (of course, I 
> could care less what he does in his sandbox :).
unfortunately, the "elegant" solution caused a regression :(
I tested this with the inelegant (original proposed) patch and it worked 
fine, so I'm gonna fix this in trunk and propose the patch to 6.0


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message