httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: mod_limitipconn for httpd 2.2 and mod_cache
Date Fri, 22 Aug 2008 15:00:32 GMT
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.



Mime
View raw message