Roel, On 12/15/15 5:13 PM, Roel Storms wrote: > I don't believe that your suggestion works, but correct me if I'm wrong. > You aren't overwriting the getInputStream or getReader method. You are > wrapping them, which is a big difference. Since the internal > Request#parseParameter() won't use your wrapped version of the method but > rather uses it's own version which won't work since you've already called > getInputStream or getReader.
My code is a Filter which executes too late. If you implement this as a Valve, you ought to be able to capture the input data (whether it is a stream or a reader) and re-play it to any code later in the valve pipeline. I must admit I haven't read all the Connector/Request code so I don't know for sure if a Valve wrapping the (non-spec-defined) request object will be sufficient. > In your case it works since you aren't calling getParameter(). You're > implementation works as long as you restrict your application to using > getReader or getInputStream. Again, correct me if I'm wrong. Calling > HttpRequestRecorderWrapper.getParameter() in the web application, should > mess up your wrapper since it doesn't intercepts this method call and will > invoke the Request.getParameter() which will call Request.getStream() and > not HttpRequestRecorderWrapper.getStream() as you're implementation > requires. Servlet code calling HttpServletRequest.getParameter* should end up calling getInputStream on the wrapper. If that's not what Tomcat does, I'd consider it a bug because Filters are supposed to be able to replace request entities and things like that. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
