On Wed, Feb 3, 2021 at 1:03 PM Mark Thomas <ma...@apache.org> 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?
>
There has been some debate about this before, and you did add quite a bit
of code to catch things that would break the protocol. So it seems this
would go above and beyond, and attempt to catch *anything* that could make
a response non compliant with the underlying protocol ?
Rémy
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
