Bug 51346 - When RequestDumperValve is enabled, an attempt to read from InputStream from an application is failing
When RequestDumperValve is enabled, an attempt to read from InputStream from ...
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
6.0.32
PC All
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-06-09 07:54 UTC by Violeta Georgieva
Modified: 2011-06-14 14:17 UTC (History)
0 users



Attachments
test-input-stream web application (2.59 KB, application/x-zip-compressed)
2011-06-09 07:54 UTC, Violeta Georgieva
Details
TestClient (1.06 KB, application/octet-stream)
2011-06-09 07:55 UTC, Violeta Georgieva
Details
Patch for RDV javadoc including a warning. (818 bytes, patch)
2011-06-09 12:30 UTC, Pid
Details | Diff
Patch for the docs page on valves, including more info about RDV behaviour. (706 bytes, patch)
2011-06-09 12:38 UTC, Pid
Details | Diff
corrected patch (870 bytes, patch)
2011-06-09 19:50 UTC, Pid
Details | Diff
corrected patch for docs (767 bytes, patch)
2011-06-09 19:50 UTC, Pid
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Violeta Georgieva 2011-06-09 07:54:08 UTC
Created attachment 27136 [details]
test-input-stream web application

Hello,

I have an application that tries to get InputStream and to read from it.
Without RequestDumperValve everything is OK.
When I enable RequestDumperValve it appears that the InputStream is already read and the end of stream is reached.

How to reproduce:
1.Deploy the attached test-input-stream.war.
2.Use the attached TestClient that will send a POST request.
3.In the console you will see "in.read() != -1" which is OK
4.Enable the RequestDumperValve in the server.xml
5.Use again the attached TestClient that will send a POST request.
6.In the console you will see "in.read() == -1" which is true when the end of stream is reached.

What TestClient does:
- sends POST request via HttpURLConnection
- writes to the OutputStream

My suspicious is that RequestDumperValve wants to dump the parameters, but parsing the parameters operation will read InputStream.

Can you give me advice how to proceed.

Thanks in advance.
Regards
Violeta
Comment 1 Violeta Georgieva 2011-06-09 07:55:13 UTC
Created attachment 27137 [details]
TestClient
Comment 2 Pid 2011-06-09 09:37:43 UTC
(In reply to comment #1)
> Created attachment 27137 [details]
> TestClient

Yes, the valve dumps headers, parameters causing the InputStream to be consumed:
http://svn.apache.org/repos/asf/tomcat/sandbox/comet/java/org/apache/catalina/valves/RequestDumperValve.java

The users list is where to ask for help, rather than bugzilla.
Comment 3 Violeta Georgieva 2011-06-09 10:36:09 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Created attachment 27137 [details]
> > TestClient
> Yes, the valve dumps headers, parameters causing the InputStream to be
> consumed:
> http://svn.apache.org/repos/asf/tomcat/sandbox/comet/java/org/apache/catalina/valves/RequestDumperValve.java
> The users list is where to ask for help, rather than bugzilla.

Yes but don't you think that this is a problem?
Typically you can use this Valve for debugging your application:

"* ...It is especially useful in debugging problems
 * related to headers and cookies."

But what happens actually is that your application will stop working because of this valve.

Is it possible at least to document this behavior?

Thanks
Violeta
Comment 4 Konstantin Kolinko 2011-06-09 10:49:14 UTC
(In reply to comment #3)
> "* ...It is especially useful in debugging problems
>  * related to headers and cookies."

The JavaDoc that you are citing above does not have the warning,

but the documentation does have it,
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Request_Dumper_Valve
Comment 5 Violeta Georgieva 2011-06-09 10:55:30 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > "* ...It is especially useful in debugging problems
> >  * related to headers and cookies."
> The JavaDoc that you are citing above does not have the warning,
> but the documentation does have it,
> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Request_Dumper_Valve

The page contains the following:
"WARNING: Using this valve has side-effects. The output from this valve includes any parameters included with the request. The parameters will be decoded using the default platform encoding. Any subsequent calls to request.setCharacterEncoding() within the web application will have no effect.
"

There is no explicit note for inputstream consumption which actually happens.

I can propose a patch if you think it is applicable, but this will take some time.

What do you think?
Comment 6 Pid 2011-06-09 12:30:54 UTC
Created attachment 27138 [details]
Patch for RDV javadoc including a warning.
Comment 7 Pid 2011-06-09 12:38:37 UTC
Created attachment 27139 [details]
Patch for the docs page on valves, including more info about RDV behaviour.
Comment 8 Pid 2011-06-09 12:38:52 UTC
Done.
Comment 9 Mark Thomas 2011-06-09 19:28:30 UTC
That statements in the patch are incorrect. The inputstream is only consumed when a) the request is a POST and b) the request content type is "application/x-www-form-urlencoded"
Comment 10 Pid 2011-06-09 19:44:46 UTC
(In reply to comment #9)
> That statements in the patch are incorrect. The inputstream is only consumed
> when a) the request is a POST and b) the request content type is
> "application/x-www-form-urlencoded"

Doh.
Comment 11 Pid 2011-06-09 19:50:11 UTC
Created attachment 27141 [details]
corrected patch
Comment 12 Pid 2011-06-09 19:50:36 UTC
Created attachment 27142 [details]
corrected patch for docs
Comment 13 Mark Thomas 2011-06-14 13:46:44 UTC
Modified patch applied (the updated patch still ignored the content-type) to 6.0.x and will be included in 6.0.33 onwards.
Comment 14 Violeta Georgieva 2011-06-14 14:17:47 UTC
(In reply to comment #13)
> Modified patch applied (the updated patch still ignored the content-type) to
> 6.0.x and will be included in 6.0.33 onwards.

Thanks!