tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Murphy <jaka...@hilbertinc.com>
Subject Double parsePostData(). Possible Tomcat bug.
Date Thu, 22 Jun 2000 12:49:26 GMT

I have code (works on JRun and WebSphere if that makes any difference)
that has a problem on Tomcat.   I looked through the code and found out
what the problem is.

I have 39 bytes of POST data from a form that gets parsed via the
HttpUtils.parsePostData(...) in my servlet.  During the course of that
same HTTP request, I call a JSP using the

    getServletConfig().
       getServletContext().
          getRequestDispatcher(page).
             forward(request, response);

technique.  The JSP compiles and runs the service(...) method.  That JSP
code also automatically calls HttpUtils.parsePostData(...).  Since it is
the same request object that has been used by my servlet code, the
header still shows 39 bytes for the content length.  It attempts to read
the 39 bytes over again and one of two things happen (strangely
enough).  Either I get a short read exception, or there are two bytes, a
CR & LF that get read and the JSP hangs waiting for the other 37 bytes
that never arrive.

This fails with Netscape for Windows and Linux and IE.  I have looked at
the code enough to be certain this isn't a browser problem anyway.

I don't know of a good fix for this.  I hacked the request object and
stuff a content length of zero in the forward(...) method and that works
for me, but I doubt it is up to spec.   I can't call socket timeout
because the parsePostData is treating it as an input stream.    The
available() method on that input stream always shows zero, even before
the original 39 bytes are read.

Has anyone else seen this?  I should be able to work up a test case
pretty easily if that is necessary.


Mime
View raw message