I think we're mixing three issues 1) Prevent Starvation.
protecting a server from server side/machine starvation (i.e. running
out of file descriptors, sockets, mbuf's, whatever).
So here you are in the domain where there is no argument in terms of
protocol violation/bad citizens; there simply
is no resource - some something gotta give.
So in this case - having hard cap's on certain things is helpful. And
if for certain setups the current MaxXXX are
not good enough (e.g. to keep a slowlaris in check as per normal modus
operandi) - then that needs to be fixed.
IMHO this is something dear to me, as a developer. And it should be
fixed 'by default'. I.e. a normal configured
apache should behave sensible in situations like this.
And this is 'alway' the case.
There is a special case of this - and that is of sites which to some
extend have shot themselves in the foot
with a 'bad' architecture; where somehow some application/language
environment has a tendency to
eat rather a lot of resources; and leave (too little) to the httpd
daemon.
2) Dealing with Noise
Generally observing that on a quiet server some 30-60% (speaking for
myself here) of your 'load' is caused
by dubious/robotic stuff which does not benefit 'you' as the site owner
with a desire to be found/public directly
or even indirectly (e.g. like a webcrawler of a search engine would do).
And this then begs the question - what can I, as a site owner (rather
than a developer) configure - even if
that means that I 'break the internet' a bit.
And this is something you decide on a per server basis; for long
periods of time.
3) Dealing with Attacks.
Dealing with specific attempts to overload a server one way or the
other; with the intention to lock
other users out.
For most of us, and unlike above two examples, a specific situation;
and one which probably last
relatively short (days, weeks).
And for which you are willing to do fairly draconian things - even if
that significantly breaks normal
internet standard behaviour.
Would be useful to discuss each separately. As I do agree with some of the
posters that apache is (no longer)
that strong* in area 1 and 3. And some modernisation may do wonders,
Thanks,
Dw
*: i.e. meaning that one tends to do highly specific things when dealing with
issues like that; and while
generally (very) effective - they are not part of core apache lore & default
config.
smime.p7s
Description: S/MIME cryptographic signature
