On 23/02/2011 11:47, Tim Funk wrote: > Sorry - I meant to say - since the existing setSocketOptions() is in the > try/catch block as accept(). Is it possible for a network client to send > an ip packet to cause a failure and throw a SocketException while > internally tomcat is setting each of the socket options? So the net > effect is - the errorDelay value is set causing which makes endPoint > fall asleep. Which could be a client induced DOS attack.
No problem, that is what I thought you meant :) Mark > > So in the context above: user/client is someone on the network end, not > the admin of the box. If the admin puts a config option in which causes > setSocketOptions() to fail ... that is their problem. > > -Tim > > > On 2/23/2011 5:48 AM, Mark Thomas wrote: >> On 21/02/2011 17:33, Tim Funk wrote: >>> Do you want to limit the try/catch scope to just >>> serverSocketFactory.acceptSocket since setSocketOptions() can also throw >>> IOException? >> >> A couple of people have mentioned this and while the current code would >> be OK with a broader try/catch I like the idea of a limited try/catch >> since that makes it obvious what the code is doing. >> >>> Is there a case where a client can induce an exception while >>> setSocketOptions() is processing? >> >> I don't think so but let's not give them the opportunity. >> >> In terms of making this configurable, I'm minded not to initially. We >> can always add configuration options if users request them later. > > --------------------------------------------------------------------- > 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
