You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by Andrey Kartashov <an...@sonatainc.com> on 2001/04/27 01:00:16 UTC

ERROR using multipart/form-data POST request

Hi, All!
We've recently migrated our application from Apache/JServ to
Tomcat and experienced the following problem:

==> /var/log/httpd/access_log <==
199.95.200.171 - - [26/Apr/2001:17:53:47 -0400] ".·\86&nomÍ"³
                                                              ¹sàä-PRá¸Z5;AàÀn8Á/bL¾"ãAÅÃÚ¢Úy±/mLâ_n"¯6RõÃ2éØåÉN¯2ÕèeÃUé
                                                  ÿr8Ø²¨y%6ç»XS¡?ÿHÑJDâ2ª¸ÍyÎ«ÂåH¸
    Êã¢Ò+UóÐÙ¼VÆ½L¤d?OF´ÔÖ©hBýZöÊ6KÈ=
                                       åUåÙ»¢§ÖA&êpö&lÁ|Û*Û?±UÛúL" 400 376 
==> /var/log/httpd/error_log <==
[Thu Apr 26 17:53:47 2001] [error] [client 199.95.200.171] request failed: error reading the headers

==

This error hapens when I try to upload file using form with
enctype="multipart/form-data" and method="post".

The environment: Linux(2.4.3), Apache(1.3.19),
mod_jk and Tomcat (3.2.1), using ajp13 protocol.


I can't seem to find anything like that in apache bug tracking system.
Did anyone have any experience using multipart/form-data with similar
server configuration?



-- 
oo Andrey
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less."
           -- http://www.mutt.org/  Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo

Re: ERROR using multipart/form-data POST request

Posted by Dan Milstein <da...@shore.net>.

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 <am...@mobilitec.com> 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 // danmil@shore.net

Re: ERROR using multipart/form-data POST request

Posted by Andrey Kartashov <an...@sonatainc.com>.

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 <am...@mobilitec.com> 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

Re: ERROR using multipart/form-data POST request

Posted by Lucian Cionca <lc...@savvion.com>.

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 <am...@mobilitec.com> 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.

Regards,
Lucian

Andrey Kartashov wrote:

> On Fri, Apr 27, 2001 at 03:57:43AM +0200, Incze Lajos wrote:
> > > This error hapens when I try to upload file using form with
> > > enctype="multipart/form-data" and method="post".
> > >
> > > The environment: Linux(2.4.3), Apache(1.3.19),
> > > mod_jk and Tomcat (3.2.1), using ajp13 protocol.
> > >
> > >
> > > I can't seem to find anything like that in apache bug tracking system.
> > > Did anyone have any experience using multipart/form-data with similar
> > > server configuration?
> > >
> > I think you should change to an 3.2.2 beta, as modjk had some difficulties
> > in the 3.2.1 tomcat release.                                       incze
>
> I just tested ajp12 protocol and it doesn't have this bug.
> I'm going to test 3.2.2 stuff as well some time later:) Just in case if someone
> else wants to try - this bug is triggered when uploading binary data
> (like image file). Uploading of the text file works (even a big one).
> I'd guess that code uses string functions somewhere where binary read/write
> would be more appropriate.
>
> --
> oo Andrey
> oo
> oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
> "All mail clients suck. This one just sucks less."
>            -- http://www.mutt.org/  Jeremy Blosser
> oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo

Re: ERROR using multipart/form-data POST request

Posted by Andrey Kartashov <an...@sonatainc.com>.

On Fri, Apr 27, 2001 at 03:57:43AM +0200, Incze Lajos wrote:
> > This error hapens when I try to upload file using form with
> > enctype="multipart/form-data" and method="post".
> > 
> > The environment: Linux(2.4.3), Apache(1.3.19),
> > mod_jk and Tomcat (3.2.1), using ajp13 protocol.
> > 
> > 
> > I can't seem to find anything like that in apache bug tracking system.
> > Did anyone have any experience using multipart/form-data with similar
> > server configuration?
> > 
> I think you should change to an 3.2.2 beta, as modjk had some difficulties
> in the 3.2.1 tomcat release.                                       incze

I just tested ajp12 protocol and it doesn't have this bug.
I'm going to test 3.2.2 stuff as well some time later:) Just in case if someone
else wants to try - this bug is triggered when uploading binary data
(like image file). Uploading of the text file works (even a big one).
I'd guess that code uses string functions somewhere where binary read/write 
would be more appropriate.

-- 
oo Andrey
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less."
           -- http://www.mutt.org/  Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo

Re: ERROR using multipart/form-data POST request

Posted by Incze Lajos <in...@mail.matav.hu>.

> This error hapens when I try to upload file using form with
> enctype="multipart/form-data" and method="post".
> 
> The environment: Linux(2.4.3), Apache(1.3.19),
> mod_jk and Tomcat (3.2.1), using ajp13 protocol.
> 
> 
> I can't seem to find anything like that in apache bug tracking system.
> Did anyone have any experience using multipart/form-data with similar
> server configuration?
> 
I think you should change to an 3.2.2 beta, as modjk had some difficulties
in the 3.2.1 tomcat release.                                       incze