Mark, On 2/3/21 07:03, Mark Thomas 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?
Hmm. How hard would it be to allow the application to '/instruct/ Tomcat to chunk the response by setting this header?
On second thought, there is a better way to do that: flush the output stream explicitly, right?
I think this should be done in a Valve that is enabled by default, but can be disabled, rendering zero penalty for "well-behaved" applications. The Valve can simply wrap the response with a wrapper that either prints an error to the log (maybe first migration path, enabled now) or throws an exception (second migration path, in the future).
Making it possible to check for various combinations of header names and values doesn't seem worth the effort at the moment, but perhaps naming the valve something generic so it could be expanded in the future would be a good idea.
-chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
