Return-Path: 
 <dev-return-76212-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
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 D375ED74E
	for <apmail-httpd-dev-archive@www.apache.org>;
 Fri,  5 Oct 2012 02:50:59 +0000 (UTC)
Received: (qmail 460 invoked by uid 500); 5 Oct 2012 02:50:59 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 398 invoked by uid 500); 5 Oct 2012 02:50:59 -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 390 invoked by uid 99); 5 Oct 2012 02:50:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Oct 2012 02:50:58 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of covener@gmail.com designates
 209.85.215.45 as permitted sender)
Received: from [209.85.215.45] (HELO mail-la0-f45.google.com) (209.85.215.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Oct 2012 02:50:54 +0000
Received: by mail-la0-f45.google.com with SMTP id m13so746948lah.18
        for <dev@httpd.apache.org>; Thu, 04 Oct 2012 19:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=1Ss5jdG4q5kLny9qJGN/NdeSK1xqBzEC/AXLcXjoqQk=;
        b=sd1jYzJkP8MNuqQQ7JsfmfcNAZ1LZim1NN9lanAVkl4+yREQpwUkSLc6BA8SugZj7V
         LwkrCzjAO1OmJ7vM3ZihQfl3yCrofxQs54bre0uIWM+QC209+naYu6SBT59Bz5cyKSZL
         RvORKLRViW93s25dKAHt0lG4o6aN8uViT3rylDpX7B6tYhFoa0GMLCNHElF7xSHeTHvS
         SLhLm4KRsHlqNpc0+BOSmhvbnOzTNSEH5M9k0j3mnNJKiCTqwu6rdAz8/PGrX4JM5M1F
         4z25ofOMDuv6qOn+ivgZHk4TEPA9KRWqS3xo7e9hjx6xTh3wzxVTetRWtXMocMUzLznu
         Kgzg==
MIME-Version: 1.0
Received: by 10.152.105.236 with SMTP id gp12mr5726036lab.35.1349405432501;
 Thu, 04 Oct 2012 19:50:32 -0700 (PDT)
Received: by 10.112.3.169 with HTTP; Thu, 4 Oct 2012 19:50:32 -0700 (PDT)
In-Reply-To: <76F7CFE1-E980-4596-B79B-8409AFCD0EC8@sharp.fm>
References: <20101108004136.5C28A23888EC@eris.apache.org>
	<C660021B-7072-4495-BE88-322996C73243@sharp.fm>
	<CALK=YjO5_g0nh_Yd7v_JnhQF9Op_uvsFqTG3J+J3udcCwzD8xQ@mail.gmail.com>
	<201210042118.42577@news.perlig.de>
	<76F7CFE1-E980-4596-B79B-8409AFCD0EC8@sharp.fm>
Date: Thu, 4 Oct 2012 22:50:32 -0400
Message-ID: 
 <CALK=YjORi89TDJ9n_wHk9XtkdMEWbD+134Jygc=4NuSQ5Ly7Zw@mail.gmail.com>
Subject: Re: svn commit: r1032431 - in /httpd/httpd/trunk: CHANGES
 modules/mappers/mod_rewrite.c
From: Eric Covener <covener@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

On Thu, Oct 4, 2012 at 7:18 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 04 Oct 2012, at 9:18 PM, Andr=E9 Malo <nd@perlig.de> wrote:
>
>> Hmm. The very sole concept of RewriteBase is "base for this location and
>> this location only".
>

> Exactly, which is why merging is the only sensible behaviour. "/foo/bar" =
is below location "/foo" at all times, regardless of whether someone has ad=
ded <Location /foo/bar> to their config or not. Until someone has explicitl=
y stated otherwise, /foo/bar should have the same RewriteBase as /foo.

No, it's not sensible.  The default base URL has always been relative
to the context the rules appear in and can be overridden by the
directive. The directive should not always be set and should not be
copied from higher scopes. The copying breaks that even for containers
of Location /foo/ and Location /foo/bar/, much less traditional
Directory and htacess where RewtiteBase is generally more useful.

> Not merging properly means that the addition of a completely unrelated di=
rective such as RewriteRule to a Location that previously had only inherite=
d RewriteRules suddenly makes the RewriteBase vanish completely without war=
ning.

With this particular directive, no RewriteBase is better than a bad
guess, because the default prefix of relative substitution tracks to
the context the rule is defined in.