Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 95B1410148 for ; Mon, 10 Jun 2013 17:57:51 +0000 (UTC) Received: (qmail 59003 invoked by uid 500); 10 Jun 2013 17:57:50 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 58864 invoked by uid 500); 10 Jun 2013 17:57:47 -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: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 58856 invoked by uid 99); 10 Jun 2013 17:57:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Jun 2013 17:57:46 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rainer.jung@kippdata.de designates 195.227.30.149 as permitted sender) Received: from [195.227.30.149] (HELO mailserver.kippdata.de) (195.227.30.149) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Jun 2013 17:57:40 +0000 Received: from [10.0.110.6] ([192.168.1.191]) by mailserver.kippdata.de (8.13.5/8.13.5) with ESMTP id r5AHvJpC025177 for ; Mon, 10 Jun 2013 19:57:19 +0200 (CEST) Message-ID: <51B61377.1000002@kippdata.de> Date: Mon, 10 Jun 2013 19:57:11 +0200 From: Rainer Jung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Location walk after directory walk? References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 10.06.2013 15:37, Eric Covener wrote: > Is there some historical or other reason that the location has higher > precedence that directory/files? I think the other way is much more > intuitive Don't know about th real motivation, but after having learned that from the explicit description in the docs I got very used to it. Changing it would have major implications for existing configs. One nice thing i saw yesterday is an explicit recipe in our docs to put additional control on .htaccess stuff you don't want to happen by enforcing your policy ("fixing" problematic .htaccess) with a that merges later. Regards, Rainer