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).
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 > > > > >
