This specific bug has been fixed in 3.2.2, and the relevant function
(doRead()) has been extensively cleaned up. The 3.2.2 support for ajp13 is
much, much better than in 3.2.1.
-Dan
Andrey Kartashov wrote:
On Fri, Apr 27, 2001 at 11:17:32AM -0700, Lucian Cionca wrote:
The reason for this is a bug in the doRead() method of Ajp13ConnectorRequest, which
causes the
doRead(byte[] b, int off, int len) in that same class to prematurely end processing
.
The bug is in the conversion of the value read from the bodyBuff byte-array, to an
integer result. Bytes can have values
from -128 to 127, while the result is expected to be a positive integer (in the
range 0 to 255). A result of -1 is interpreted in the
doRead(byte[] b, int off, int len) method as an error/end of input.
The patch to Tomcat sources is very simple. In function int doRead()
in Ajp13ConnectorRequest.java instead of the line
return bodyBuff[pos++];
the line
return bodyBuff[pos++] 0xFF;
should be used.
Credit for the solution should go to Amir Nuri [EMAIL PROTECTED] who
indicated the solution to me.
On the other hand there is always the workaround to use ajp12 for the specific
servlets that use multipart/form-data POST.
[skpd]
Thank you all for looking into this problem!
I looked at doRead(...) function that you've mentioned and I think I'm going to
stick with ajp12 for now:) It seems that this function is just a temporary hack
anyway (at least this is what comment says).
For one thing I'm not sure that it'll properly behave in all the cases
because it always returns len. If I'm not mistaken - this means that it's
possible to read more data than there is which may confuse some other code:)
I compared it to the same function in Ajp12 implementation and I like ajp12 one
better because it utilizes java's BufferedInputStream which I hope always does
the right thing :)
Anyway, thanks again for your help!
--
oo Andrey
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
All mail clients suck. This one just sucks less.
-- http://www.mutt.org/ Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
--
Dan Milstein // [EMAIL PROTECTED]
