You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/08/22 17:00:32 UTC
Re: mod_limitipconn for httpd 2.2 and mod_cache
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.
Re: mod_limitipconn for httpd 2.2 and mod_cache
Posted by Arturo 'Buanzo' Busleiman <bu...@buanzo.com.ar>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
William A. Rowe, Jr. wrote:
> I'm pointing out this isn't a connection limit, it's a request limit, and
> we should probably commit it with an appropriate module name :)
mod_req_limit or another variant thereof?
- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIrt4nAlpOsGhXcE0RCvdLAJ9mgkt1aFQwLUluU1O3UHgzwI2pUACfYLrj
gvtLZvI1O10SgL3kJGaesn4=
=uFsd
-----END PGP SIGNATURE-----
Re: mod_limitipconn for httpd 2.2 and mod_cache
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niklas Edmundsson wrote:
>
> [...] are probably more content with this for now than having to wait
> for someone committing the Perfect<tm> solution to httpd :)
Right; I'm not saying don't commit it (things can be fixed in trunk, that's
the point), but as you mentioned you want to get the naming right on the
first try.
Must as I objected that the earlier mod_sed (now _substitute) wasn't 'sed',
I'm pointing out this isn't a connection limit, it's a request limit, and
we should probably commit it with an appropriate module name :)
Bill
Re: mod_limitipconn for httpd 2.2 and mod_cache
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
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.
http://dominia.org/djao/limit/ChangeLog 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 http://ftp.acc.umu.se/ 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 :)
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
It takes a lot of RAM to make your floppy spin...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: mod_limitipconn for httpd 2.2 and mod_cache
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Arturo 'Buanzo' Busleiman wrote:
> William A. Rowe, Jr. wrote:
>> 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.
>
> Are you talking about mod_limitipconn? If you are, then rename it to something entirely different
> like mod_null.
If our understanding is correct, these are one in the same, and
mod_limitipconn before submission to httpd behaved the same way
(worse, in that before Niklas' patch there was not only no DoS
protection from opening connections, but also no regular checking
of cached content.)
Sarcasm aside, it does seem that MaxConnPerIP and mod_limitipconn
are slightly misnomers. These are limits on concurrent requests
(as was the original mod_limitipconn).
Bill
Re: mod_limitipconn for httpd 2.2 and mod_cache
Posted by Arturo 'Buanzo' Busleiman <bu...@buanzo.com.ar>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
William A. Rowe, Jr. wrote:
> 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.
Are you talking about mod_limitipconn? If you are, then rename it to something entirely different
like mod_null.
- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIrtd/AlpOsGhXcE0RCi3AAJ4nKe4J3Dt30G9M89RZVrD8p2VqswCeMR2b
eSbN1pVwDqvqfkQycQ0eQPc=
=faX2
-----END PGP SIGNATURE-----