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.
This is a summary of the changes made: * Configuration directives are now set per VHost (Directory/Location are available after the Quick Handler has been run). This means that any <Location> containers has to be deleted in existing configs. * Fixed configuration merging, so per-vhost settings use defaults set at the server level. * By running as a Quick Handler we don't go through the entire lookup phase (resolve path, stat file, etc) before we get the possibility to block a request. This gives a clear performance enhancement. * Don't do subrequest to lookup MIME type if we don't have mime-type specific config.
So as mentioned above, there's only mime type to use if using the usual handler chain. Since we aren't there's no point in retaining this at all.
* 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.
