Am 2021-02-04 um 17:36 schrieb Rémy Maucherat:
On Thu, Feb 4, 2021 at 5:31 PM Michael Osipov <micha...@apache.org> wrote:
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?
Probably it's: Customer X using library Y, says there's no possible way he
could ever update library Y with a fixed version. Thankfully, getting
Tomcat devs to work around the library issue instead is easy to do.
Solution !
This doesn't count because with the same counter-argument we have
rejected to reintroduce reason phrases in 9/10. Explanation: fix the
client, not us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
