Le mer. 3 févr. 2021 à 17:10, Mark Thomas <ma...@apache.org> a écrit :

> On 03/02/2021 16:06, Romain Manni-Bucau wrote:
> > Hi,
> >
> > Why not just adding a tomcat-application-fixer module (a more ugly name
> can
> > be relevant ;)) application could add in their WEB-INF/lib through web
> > resource definition (ie plain context.xml config or programmatic
> > equivalent) which would have a @WebFilter(/*, asyncSupported=true) which
> > would wrap the response to do the fixes you want for these apps but it
> > wouldnt be seen in the most common case at all (or if there is only this
> > small fix it can be a default filter of tomcat, depends the number of
> fixes
> > and related code IMHO).
>
> Primarily because of the risk that wrapping the request breaks the
> application.
>
> While a well-behaved app should be unaffected by a Filter adding a
> wrapped response, we already know that these applications are not
> well-behaved - else they wouldn't be setting these headers in the first
> place.
>
> Hence I am looking at solutions further down the stack in the Tomcat
> internals.
>

So you mean the application uses tomcat internals (like casting the
Response/Request) but does not work on Tomcat? :s

Otherwise there is no real way a filter and wrapper breaks a "broken"
application since the application will take the wrapped instance as a
standard servlet instance - as tomcat already do with its facade layer. The
only constraint is to ensure the filter is first which can require another
solution than @WebFilter but web.xml solves it.



>
> Mark
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 3 févr. 2021 à 16:50, Rémy Maucherat <r...@apache.org> a écrit :
> >
> >> 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
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to