httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: svn commit: r1032431 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_rewrite.c
Date Fri, 05 Oct 2012 02:50:32 GMT
On Thu, Oct 4, 2012 at 7:18 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 04 Oct 2012, at 9:18 PM, André 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 added <Location /foo/bar> to
their config or not. Until someone has explicitly 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 directive such
as RewriteRule to a Location that previously had only inherited RewriteRules suddenly makes
the RewriteBase vanish completely without warning.

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.

Mime
View raw message