httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: Remove <Limit> and <LimitExcept> ?
Date Sun, 19 Sep 2010 18:35:21 GMT
On Sun, Sep 19, 2010 at 8:40 AM, Ruediger Pluem <rpluem@apache.org> 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, bugzilla@apache.org wrote:
>>> --- Comment #3 from Nick Kew <nick@webthing.com> 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 :)

Mime
View raw message