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.
- Ray On Wed, Feb 3, 2021 at 11:15 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le mer. 3 févr. 2021 à 17:10, Mark Thomas <ma...@apache.org> a écrit : > > > 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. > > > > So you mean the application uses tomcat internals (like casting the > Response/Request) but does not work on Tomcat? :s > > Otherwise there is no real way a filter and wrapper breaks a "broken" > application since the application will take the wrapped instance as a > standard servlet instance - as tomcat already do with its facade layer. The > only constraint is to ensure the filter is first which can require another > solution than @WebFilter but web.xml solves it. > > > > > > > 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 > > > > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow
