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
