httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Edmundsson <>
Subject Re: mod_limitipconn for httpd 2.2 and mod_cache
Date Fri, 22 Aug 2008 15:28:58 GMT
On Fri, 22 Aug 2008, William A. Rowe, Jr. wrote:

> I don't quite understand...
> Niklas Edmundsson wrote:
>> The main problem with mod_limitipconn-0.22 was that since mod_cache runs as 
>> a quick handler, mod_limitipconn also must run as a quick handler with all 
>> those benefits and drawbacks.
> ... MIME types exempt from limit checking ...
> hashes are still in the config code.  This gets resolved how, exactly,
> at the quick-handler phase?
> Without that code (and knowing it goes before quick handler) it seems like
> connection oriented hooks make more sense.  It's nice (for performance)
> that it runs earlier than the hooks, but doesn't help to the extent that
> the server is still waiting on all the headers to be received.
> We might not be able to do much about that anyways but it should probably
> be documented that it doesn't limit connections or assist in preventing
> DoS attacks.

For added confusion, I think that you're reading my old changelog 
before David merged my patch and fixed things. is more correct on describing 
how it currently works.

>> * Count connections in closing and logging state too, we don't want to
>>    be DOS'd by clients behind buggy firewalls and so on.
> It isn't counting 'reading' connections, so no point in this IMHO.  If the
> user-perceived experience is that they are limited to two connection
> streams, they should not be penalized while closing or at close_wait.
> That's a matter of using correct KeepaliveTimeout values.

Our main use is for which is a file archive.

The problem is the following (yes, moronic download agents):
- Client connects from some kind of broken firewall or something.
- Client gets hit by connection limit.
- Client drops connection, but firewall causes it to get stuck in
   closing state.
- Client immediately retries, causing one more connection to get stuck
   in closing state.

We've seen clients using up close to a thousand of slots this way.

In real-life use we have set a limit of 10 connections per IP, and 
haven't heard of any complaints. We have no real problems with our 
servers running out of connections, so we're happy.

And yes, connection oriented hooks are probably better in the quick 
handler case. But at least this works for now, and people having this 
problem are probably more content with this for now than having to 
wait for someone committing the Perfect<tm> solution to httpd :)

  Niklas Edmundsson, Admin @ {acc,hpc2n}      |
  It takes a lot of RAM to make your floppy spin...

View raw message