Le jeu. 4 févr. 2021 à 11:09, Mark Thomas <ma...@apache.org> a écrit :
> 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. > Not if we enforce it to be first which is only configuration as of today and what you are looking for, no? If not I'm not sure how the hypothesis that the app is broken on tomcat can be (if the app uses tomcat internals it works on tomcat or needs fixes tomcat does not need to do for the app IMHO). Concretely, I only see this feature as a portability helper (from another container/env), in other cases (ie the app was developped for tomcat but does not work on tomcat) I'm not sure tomcat should help. When I do "1+2" and expect 2 the language/compiler/other never help for good reasons. What I like with the filter option is that the user will understand what tomcat does even not aware of tomcat internals. If we add a HttpOutputBuffer wrapper which handles header keys/values and an error is logged/thrown from there I think it will be way less clear for most people even if it is very close. Overall a new Header dedicate spi seems overkill since we have already multiple extension point to control headers, no? > > <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 > >
