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.
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
