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 !
Rémy
>
> M
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
