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
Created attachment 27137 [details] TestClient
(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.
(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
(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
(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?
Created attachment 27138 [details] Patch for RDV javadoc including a warning.
Created attachment 27139 [details] Patch for the docs page on valves, including more info about RDV behaviour.
Done.
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"
(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.
Created attachment 27141 [details] corrected patch
Created attachment 27142 [details] corrected patch for docs
Modified patch applied (the updated patch still ignored the content-type) to 6.0.x and will be included in 6.0.33 onwards.
(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!