Return-Path: 
 <dev-return-69484-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 7161 invoked from network); 20 Sep 2010 17:27:50 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 20 Sep 2010 17:27:50 -0000
Received: (qmail 37279 invoked by uid 500); 20 Sep 2010 17:27:49 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 37160 invoked by uid 500); 20 Sep 2010 17:27:49 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 37152 invoked by uid 99); 20 Sep 2010 17:27:49 -0000
Received: from Unknown (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Sep 2010 17:27:49 +0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of gstein@gmail.com designates
 209.85.214.45 as permitted sender)
Received: from [209.85.214.45] (HELO mail-bw0-f45.google.com) (209.85.214.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Sep 2010 17:27:27 +0000
Received: by bwz4 with SMTP id 4so6072836bwz.18
        for <dev@httpd.apache.org>; Mon, 20 Sep 2010 10:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=f/iMgi/mLKD4Mall9dukM3ctNp5M9yHrftDzzUCMuus=;
        b=hBKVyUdS4rGwlfokWNVGh779yR+CMmL3DlLhQ7TXzz8AmvCv+VBwu8kXIHOtGu7/mW
         q35b+WnFpp9V7EXez6RR4rYX+AXKpz3vY1Ao0yO3g0IdN+UfUcUAoIK9GAhvUB2zoM2F
         JmlA6wdfmM9TAlC/dw1ERsTZJOVejWvj+MThw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=VdsqkXHFqnbQP+NjdeaY1sTPbTsxaYR76T4UnCOR1YOR3CzZR2+zIyZHUJ3Qyk1/IJ
         vMVB3t9ZWOtFRBHVmZKpv+8gHM+AQi224ERREUjpVppfjpMGai6yipfkkO+rZJvMFTLK
         zgp59F2rBfpvXyuWjt6wtdC4Ov/zLq5MPBTig=
MIME-Version: 1.0
Received: by 10.204.35.5 with SMTP id n5mr6926061bkd.155.1285003627508; Mon,
 20 Sep 2010 10:27:07 -0700 (PDT)
Received: by 10.204.79.73 with HTTP; Mon, 20 Sep 2010 10:27:07 -0700 (PDT)
In-Reply-To: <201009190045.40875.sf@sfritsch.de>
References: <bug-49927-7868@https.issues.apache.org/bugzilla/>
	<201009181038.o8IAcai8027660@thor.apache.org>
	<201009190045.40875.sf@sfritsch.de>
Date: Mon, 20 Sep 2010 13:27:07 -0400
Message-ID: <AANLkTike=Z-tUtWm-s8T3pZtRDcNKtQx_vmj_CG0P4Rh@mail.gmail.com>
Subject: Re: Remove <Limit> and <LimitExcept> ?
From: Greg Stein <gstein@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

The Limit/LimitExcept directives are *very* handy and important when
mod_dav is being used. In fact, LimitExcept was created specifically
in order to avoid listing every new method that might come along via
DAV specs and such.

As long as an alternative is available, then I don't care. But the
functionality is very important.

Cheers,
-g

On Sat, Sep 18, 2010 at 18:45, Stefan Fritsch <sf@sfritsch.de> wrote:
> This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=3D49927
>
> 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. =A0We 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
>> =A0 =A0"... 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.
>