Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <51E07867.5020207@ice-sa.com>
Date: Fri, 12 Jul 2013 23:43:03 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: HTTP connection timout
References: 
 <CAKJnvaN+ota3SyssaysE0wQoz4N=QuB1BGymtKDuutGq4rz-TA@mail.gmail.com>
 <51DFBB4A.4090103@ice-sa.com> <51E05C03.8090809@christopherschultz.net>
In-Reply-To: <51E05C03.8090809@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> André,
> 
> On 7/12/13 4:16 AM, André Warnier wrote:
>> Harsimranjit singh Kler wrote:
>>> Using tomcat 6.I Always confused with
>>>
>>> connectionTimeout
>>>
>>> The number of milliseconds this *Connector* will wait, after
>>> accepting a connection, for the request URI line to be presented.
>>> The default value is 60000 (i.e. 60 seconds).
>>>
>>> Helpful if anyone can explain.?
>>>
>>> Is there any connector parameter where i can set request
>>> timeout.?Rather than at application level timeout i want tomcat
>>> to timeout after certain period if request taking long time..
>>>
>> The Connector's are "shared" by all Hosts and all applications. So
>> the connectionTimeout is already global for all requests that come
>> in on the corresponding Connector port.
>>
>> This parameter is there specifically to fight one type of 
>> Denial-Of-Service attack, whereby some malicious client(s) create a
>> TCP connection to the server (which has the effect of reserving
>> some resources on the server for handling this connection), and
>> then just sit there without sending any HTTP request on that
>> connection. By making this delay shorter, you shorten the time
>> during which the server resources are allocated, to serve a request
>> that will never come. This has to be balanced against legitimate
>> clients which may be slow in sending the request line.  But 60
>> seconds is a really long time to wait for such legitimate client
>> requests nowadays. You can probably lower that to 5000 (= 5 s.)
>> without any ill effect on the legitimate clients.
> 
> FWIW, it's trivial to change a TCP-connect attack to a Slowloris
> attack[1], which Tomcat cannot really mitigate very well.
> 
> [1] http://en.wikipedia.org/wiki/Slowloris
> 
>> Note that as soon as the HTTP request line has been received, this 
>> timeout plays no role anymore. So it is not usable to limit the
>> time that an application requires to process and respond to the
>> request.  As far as I know, there is no standard parameter
>> available in Tomcat to do that.  Which is also rather
>> understandable, because Tomcat has no idea what kind of delay makes
>> sense for any particular application with any particular request
>> parameters.  Only you would know that, on a call-by-call base.
> 
> Try looking at "socket.soTimeout" if using the NIO implementation.
> There doesn't seem to be a reason why the blocking-connector couldn't
> also specify the read timeout, but I don't see an option for that
> connector.
> 
As per the cited Wikipedia article (thanks Chris), it looks like this may be a legitimate 
case for using a httpd front-end with the mod_reqtimeout module added-in.
https://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html
(against SlowLoris I mean).
I can also imagine that when using mod_jk as the Apache-Tomcat connector, there may be 
some mod_jk parameter which allows to limit the time that the back-end Tomcat can use to 
respond. Haven't checked this with the mod_jk docs though (but they are here : 
http://tomcat.apache.org/connectors-doc/reference/workers.html).
I still think that this is something better controlled at application level though, maybe 
in a servlet filter ? (messy though : start/stop a timer etc..).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org