(if it helps) From what I saw which was close to that it was due to the current microservice erea where it is very common to have poor man proxies coded in java/tomcat and forwarding all headers of a HTTP request, this is not uncommon and will even work on some containers (and always in bad tests ;)) but nothing a filter can't fix trivially. So helping is clearly interesting, I'm not 100% sure it belongs to tomcat but a configurable filter wouldnt hurt or impact other users while not active by default I think and it will help for these cases.
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 jeu. 4 févr. 2021 à 17:31, Michael Osipov <micha...@apache.org> a écrit : > Am 2021-02-03 um 13:03 schrieb Mark Thomas: > > 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? > > Re-reading the PR and your description, I do not really understand why > the container should handle and automagically fix bad application code? > Doing non-sense in appication code shall lead to undefined behavior. > Autofixing means that devs will never fix the real cause and Tomcat will > handle the symptom. > > Can you explain why the problems at work cannot be fixed in the webapp > itself? > > M > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
