On 03/02/2021 16:06, Romain Manni-Bucau wrote: > Hi, > > Why not just adding a tomcat-application-fixer module (a more ugly name can > be relevant ;)) application could add in their WEB-INF/lib through web > resource definition (ie plain context.xml config or programmatic > equivalent) which would have a @WebFilter(/*, asyncSupported=true) which > would wrap the response to do the fixes you want for these apps but it > wouldnt be seen in the most common case at all (or if there is only this > small fix it can be a default filter of tomcat, depends the number of fixes > and related code IMHO).
Primarily because of the risk that wrapping the request breaks the application. While a well-behaved app should be unaffected by a Filter adding a wrapped response, we already know that these applications are not well-behaved - else they wouldn't be setting these headers in the first place. Hence I am looking at solutions further down the stack in the Tomcat internals. Mark > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mer. 3 févr. 2021 à 16:50, Rémy Maucherat <r...@apache.org> a écrit : > >> On Wed, Feb 3, 2021 at 1:03 PM Mark Thomas <ma...@apache.org> wrote: >> >>> Hi all, >>> >>> We have an open PR related to this for HTTP/2 (#277) and I am seeing >>> related issues at $work with HTTP. >>> >>> In short, applications are doing things like: >>> >>> response.setHeader("Transfer-Encoding", "chunked"); >>> >>> which, as you'd expect is causing problems if: >>> - Tomcat doesn't chunk the response >>> - Tomcat does chunk the response, adds its own "chunked" value and the >>> user agent rightly objects to "chunked" appearing twice >>> >>> And so on. >>> >>> I'd like to put something into Tomcat to address this. >>> >>> I think it should be disabled by default so correctly written >>> applications pay a very small penalty. Along the lines of >>> >>> if (someSetting != null) { >>> // Do header checks >>> } >>> >>> In terms of options I think we need: >>> - something representing the current, allow anything, behaviour >>> - an option to log (with a stack trace so the offending code can be >>> identified) attempts to set such headers >>> - an option to ignore attempts to set such headers >>> >>> Do we need an option that throws an exception if there is an attempt to >>> set such headers? >>> >>> Do we need an option to control which headers and which values will >>> trigger this behaviour? This would make the configuration rather more >>> complex. You'd need to be able to set multiple combinations of header, >>> value and action. >>> >>> Is adding debug (no stacktrace) and trace (with stacktrace) logging to >>> addHeader() sufficient? For identifying faulty code this helps but it >>> doesn't provide a way to work-around the problem. For that you need >>> something that blocks the adding of the header. >>> >>> I'm still considering what might be the best way to fix this. Hence the >>> brain dump above. Thoughts? >>> >> >> There has been some debate about this before, and you did add quite a bit >> of code to catch things that would break the protocol. So it seems this >> would go above and beyond, and attempt to catch *anything* that could make >> a response non compliant with the underlying protocol ? >> >> Rémy >> >> >>> >>> Mark >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
