On 18/02/2020 19:47, Michael Osipov wrote: > Am 2020-02-18 um 20:28 schrieb Mark Thomas:
<snip/> >> Got it - I think. Let me re-phrase to see if I understand correctly. >> >> You have a code fragment that issues a redirect. >> >> The app submits a request with an header "Expect: 100-continue" >> >> With the valve the sequence is: >> - request >> - redirect >> - request >> - 100 Continue >> - response >> >> With the filter the sequence is: >> - request >> - 100 Continue >> - redirect (and body will be swallowed) >> - request >> - 100 Continue >> - response > > Exactly! > >> The questions is "Why the difference?" as the Filter is less efficient. >> It ends up sending the body twice. >> >> The answer is that Tomcat has to provide the "100 Continue" response >> since there isn't a Servlet API for the app to do so. It does this as >> the final act in the Context's pipeline (valve collection). That means >> it happens after any Engine/Host/Context Valves you have configured but >> before any Filters. >> >> This enhancement request would help: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 >> >> but it would need to be made optional as it will add a delay to the >> request processing in some circumstances. > > Now this makes sense. This basically means that something like this [1] > cannot efficiently implemented w/o using a valve? Yes. > If you say this is also a limitation in the Servlet API, it is worth to > raise that as a clarification point? Sure. It won't happen until at least Servlet 5.1 though. 5.0 is limited to the javax -> jakarta rename and posisble some minor clean-up. > It might be worth adding to docs/config/valve.html when a valve is more > approriate than a filter. This is clearly a pitfall for such a case. Indeed. Mark > > Thanks for the clarification. > > [1] > https://github.com/csviri/bodylimiter/blob/master/src/main/java/com/csviri/security/filter/bodylength/RequestMessageBodyLengthLimitFilter.java > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
