I don't think this patch is what we really want to do.
Currently, the code is testing for all of the following conditions before
trying to parse request parameters from the input stream:
1) The HTTP method is "POST"
2) The content length is greater than zero
3) The servlet has never called getInputStream() or getReader()
4) The content type is the required value
Your patch would change test (3) to require that the servlet *must* have
called getInputStream() or getReader() first, which would break a large
number of existing servlets.
Do you have a test case that demonstrates a problem? I've got lots of
different web apps that seem to have no problems reading POST-ed request
parameters.
On Mon, 21 May 2001, Mark T. Miller wrote:
>
> [I sent this to the users list on Friday - someone sent me email
> telling me I should send it to this group - sorry for the double
> post]
>
> I just started using TomCat B5 using the builtin HTTPConnector.
> When POST-ing a form, none of the name-value pairs of the
> "Query string" make it through.
>
> I found the below minor logic bug, and it now is working for me.
>
> --- HttpRequestBase.java.orig Fri May 18 16:36:30 2001
> +++ HttpRequestBase.java Fri May 18 16:39:40 2001
> @@ -616,7 +616,7 @@
> if (semicolon >= 0)
> contentType = contentType.substring(0, semicolon).trim();
> if ("POST".equals(getMethod()) && (getContentLength() > 0)
> - && (this.stream == null)
> + && (this.stream != null)
> && "application/x-www-form-urlencoded".equals(contentType)) {
> try {
> int max = getContentLength();
>
>
