tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Sat, 20 Apr 2013 11:29:37 GMT
André Warnier wrote:
> Mark H. Wood wrote:
>> On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
>>>> From: Leo Donahue - RDSA IT [] 
>>>> Subject: RE: Tomcat access log reveals hack attempt: "HEAD 
>>>> /manager/html HTTP/1.0" 404
>>>> So you are saying it could be possible to know in advance that 
>>>> certain requests are for repeated requests of nothing or being made 
>>>> by a bot, versus regular legitimate requests, in order to move those 
>>>> bot requests
>>>> off to another thread?
>>> Nothing of the sort.  You simply put each 404 response on queue, and 
>>> have an existing timer thread send it out when the appropriate delay 
>>> has been achieved.  No threads are tied up during the delaying action.
>> However, sockets *are* tied up.  We don't get this benefit for free;
>> it costs both kernel and application memory.  Even if the limits on
>> these are infinitely adjustable, we might not want to adjust them that
>> high because they are doing another job for us.
> True, but returning a 404 is something that needs to be done anyway, for 
> legitimate requests as well as for the bots.
> As a matter of fact, returning any of the 4xx or 5xx error codes, which 
> are fairly "standard" things (by which I mean that in most cases, the 
> returned message is the same, no matter which application sends it and 
> no matter what the request was).
> So why tie up a really valuable application thread to do that ?
> If any application, once it is determined that such an error message has 
> to be sent back, could offload the actual work of doing it to some 
> less-valuable process/logic, might this not be of general benefit to the 
> server ?
> In such a case, the special handling of a 404 with an additional delay 
> (or not), would only be a marginal thing.
> It is dangerous to make assumptions like this without actually testing 
> it in the real world, with a real server submitted to a real load.  And 
> I understand that this would require someone to actually make the 
> changes in the server code (I don't have the skills to do that). On the 
> other hand, without actually testing it, we will never know.

Addendum : actually, as far as 4xx codes go, a bit more discrimination is needed. A 401 
response (Auth required) for example, should not be slowed down, as it is part of a normal

authentication cycle. There may be others like that.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message