Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 8347 invoked by uid 500); 3 Oct 2002 00:43:22 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 8334 invoked from network); 3 Oct 2002 00:43:21 -0000 Date: Wed, 2 Oct 2002 17:43:29 -0700 (PDT) From: Joshua Slive X-X-Sender: To: Subject: Re: Authentication In-Reply-To: <3D9B8FA4.3000605@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 2 Oct 2002, Jerry Baker wrote: > Joshua Slive says: > > This has the effect of leaving GET unrestricted, according to the bug > > report. Is this correct behavior? It seems like, since the other methods > > are not change by the , the require should still apply to > > them. > > I agree. The LimitExcept directive implies that the limit will apply to > everything with the exception of what follows (POST, HEAD, GET, etc.). > "Except" is negative in nature - meaning exclusion. It implies that > nothing will be done to those requests since the directive says they are > to be excluded. Since Apache uses the LimitExcept directive to apply > some sort of context to the HTTP requests in that directive, it's not > really excluding those requests from the directive. It's semantics, but > important ones. > > Users get clues about how config directives work by the meaning of the > words used. In this case, "except" is misleading. It should be changed > to . There is a difference. No. should be corrected not to touch the other methods. Otherwise, things like this wouldn't work: require valid-user order deny,allow deny from badguy.com Joshua.