Responses in line: On 03/02/2021 19:55, Raymond Auge wrote: > What about an integration point that acts as a passthrough to such changes > that let you "monitor" and/or "defend" against these operations (using > whatever policy you wish). > The default would be no-op.
That certainly provides most flexibility and could easily be implemented in a way that avoids the issues with the Filter approach. I suspect a lot of users that want/need the sort of functionality we are discussing here won't want to / be able to deploy custom code and would prefer a configuration only solution. We could address that by providing some custom implementations. > On Wed, Feb 3, 2021 at 11:15 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: <snip/> >> So you mean the application uses tomcat internals (like casting the >> Response/Request) but does not work on Tomcat? :s Yes, casting is what concerns me. And making assumptions about whether the response is wrapped and with what concrete classes in what order. Adding another wrapper might break things. <snip/> I spent a little time this morning looking through the Tomcat code base for calls that manipulated the response headers to see what might be problematic. If we look at which headers and/or values are known to cause problems or might cause problems the list is a lot shorter than I expected. Tomcat already silently prevents an application from setting multiple content-length (and content-type) headers. As far as I can tell we'd need at least the following additional checks: - Any app set vary header needs to by syntactically correct (Tomcat depends on this if Tomcat needs to manipulate the header). - The app must not set "Transfer-Encoding: chunked" as Tomcat always adds this if required and multiple values are known to be rejected by some reverse proxies. - The app must not set "Connection: keep-alive" if useKeepAliveResponseHeader="true" is set on the Connector. - It is debatable whether or not we allow users to set "Connection: close". Given there may still be valid use cases for this I think we should allow it. I don't think we need to restrict Connection any further. We need to allow "Connection: upgrade" so we can't block it completely. I am currently wondering whether a simple solution that blocks known bad header/value combinations and logs what has been blocked is sufficient or whether we need / should go down the integration point approach and introduce "HeaderValidator" or similar. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
