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
