Re: Double parsePostData(). Possible Tomcat bug.

[Gary Murphy <ja...@hilbertinc.com>]

I need a clarification on your answer.

I do access a parameter in the servlet, but I do not access any parameters in
the JSP.   The problem occurs when the JSP attempts to parse the POST data that
has already been parsed by my servlet code prior to calling the forward(...).

Does this still sound like a Tomcat bug?  I looked through the JSP spec and the
word POST only appears twice without helping me out on whether I have a coding
problem or whether this is a bug.

Thank you for the help.   Meanwhile, I will see if using getParameter in the
servlet makes a difference over calling the parsePostData directly. Sorry for
the long delay in reply.  I have been out of the country without ready access to
email.


Costin Manolache wrote:

> parsePostData is called internally if you access any parameter.
>
> If you don't do that begore forward and tomcat still reads the form data -
> it's a clear bug ( you can add a "throw new Exception.; catch( ex ) {
> printStackTrace() } "
> in the code that reads the form to find out where the bug is )
>
> If you do access any parameter - the spec requires us to read the form data,
> and you can't do it. We can't change the header either.
>
> I think the best for you would be to try to just use getParameter instead of
> reading the form data. Even if you are first, you may still have problems if
> getParameter is called later - and it'll try to read the form again.
>
> Costin
>
> Gary Murphy wrote:
>
> > 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.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org