On 04/02/2021 15:33, Christopher Schultz wrote: > Mark, > > On 2/4/21 8:52 AM, Mark Thomas wrote: >> On 04/02/2021 13:28, Christopher Schultz wrote: >>> I think this should be done in a Valve that is enabled by default, but >>> can be disabled, rendering zero penalty for "well-behaved" applications. >>> The Valve can simply wrap the response with a wrapper that either prints >>> an error to the log (maybe first migration path, enabled now) or throws >>> an exception (second migration path, in the future). >> >> Valves can't wrap requests or responses. It would require some major >> refactoring to make that possible. > > Well, you *can* wrap them. Maybe it's not a good idea[1], but its > certainly possible.
That is a lot simpler than I recall. > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014 > > I still don't understand why wrapping the request is such a risky thing. > Only in Tomcat code, suddenly OOP decoration pattern doesn't apply? My concern is if an application is doing things like addHeader("Transfer-Encoding","chunked") it is messing around at a fairly low level and I would not be surprised to see the same application trying to cast HttpServletResponse to ResponseFacade and assuming it is not wrapped. For a spec compliant app, I agree a Filter is the obvious choice. Maybe I am over estimating the risk of apps making inappropriate casts and/or assumptions of no wrapping. For the specific cases I have in mind I don't have hard information so I am leaning towards assuming the worst. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
