On 14/05/2019 21:57, Christopher Schultz wrote: > Mark, > > On 5/14/19 15:47, Mark Thomas wrote: >> On 14/05/2019 20:38, Igal @ Lucee.org wrote: >>> On 5/14/2019 12:15 PM, Christopher Schultz wrote: > >> <snip/> > >>>>> Then, Tomcat observes that the servlet or filter wants to put >>>>> the response into the penalty box and, instead of flushing >>>>> the response and (possibly) closing the connection, it just >>>>> sits-around for a while, keeping the connection open. >>> >>> Wouldn't that punish Tomcat by keeping the connection open? Open >>> the door for DDoS attacks? > >> I don't think so. > >> An open connection alone isn't going to be enough to trigger a DoS >> (on a reasonable configured server). > >> It won't make an existing DoS any worse. You'd still need DoS >> protection. > >> If you do it right, the client will just think the server is being >> slow. > >>> I would think that a better way to do it is to flush and close >>> the request immediately, and then block the IP address for X >>> seconds. > >> I'd suggest putting the request into async mode with a predefined >> timeout and a listener to handle the timeout. > >> That way, no extra Tomcat plumbing is required - and your solution >> is portable across Servlet containers. > > That is interesting, but I'd want to trigger it on authentication > failure. If using Tomcat's authentication, I don't think the > application has an opportunity to intercept, does it? > > I guess a Filter could work, but the Filter needs to know that the > authentication failed. Can a Filter switch a connection from "normal" > more to async mode?
Use a custom error page. Have that be a servlet. Put the request in async mode. On timeout have the listener dispatch to a servlet/JSP/static file that displays the error message. Should work with any authentication scheme, any realm, Tomcat provided or otherwise as long as it uses the error page mechanism (which it should). And yes, a filter can put a request into async mode but that should not be necessary. One caveat - I haven't tested any of this. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
