On Sun, Sep 19, 2010 at 8:40 AM, Ruediger Pluem <[email protected]> wrote: > > > On 09/19/2010 12:45 AM, Stefan Fritsch wrote: >> This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927 >> >> On Saturday 18 September 2010, [email protected] wrote: >>> --- Comment #3 from Nick Kew <[email protected]> 2010-09-18 >>> 06:38:34 EDT --- >>> >>>> No, the current documentation is correct. The semantics of >>>> Limit/LimitExcept is just insane. We should relly get rid if it >>>> in 2.4 and improve the docs for 2.2. Maybe the "unprotected" >>>> should be big, red, and blinking ;-) >>> Agreed. We can even document it as superseded by >>> <If "$request-method ..."> >>> having of course checked the expression parser, which probably >>> needs updating to support things like >>> "... in GET,HEAD,OPTIONS,TRACE" >>> without some nasty great OR expression. >> >> What do other people think about removing <Limit> and <LimitExcept> >> and adding mod_allowmethods from the sandbox to easily forbid some >> methods? Or would this create too much trouble when upgrading >> configurations? >> >> >> BTW, we could also add an authz provider to allow things like >> >> Require method GET,HEAD,... >> >> Though this would be slower than mod_allowmethods because authz >> providers have to parse the require line on every request. > > Hm. I don't like it to be removed until be have an agreed alternative > in trunk. And the question is whether we should still do this after > we had a first beta release.
This is the module that infrastructure uses (and I wrote) to replace use of limits on *.apache.org: <https://svn.apache.org/repos/infra/infrastructure/trunk/projects/mod_allowmethods/mod_allowmethods.c> It was written after the last attack on our servers in which the attackers uploaded CGI scripts; We have some specific use cases where we want to allow CGI in some places, but all of them have very limited methods they should accept. Trying to configure <Limit for our use case and diverse set of vhosts would of meant duplicating the config in hundreds of places. I don't think the module is really great as an alternative, but it is one path to consider, and is working for at least one use case :)
