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 09:10:58 GMT
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"
>>> 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.

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

View raw message