Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: message received from 54.76.25.247 which
 is an MX secondary for dev@httpd.apache.org)
From: =?iso-8859-1?q?Andr=E9_Malo?= <nd@perlig.de>
Organization: TIMTOWTDI
To: dev@httpd.apache.org
Subject: Re: *Match, RewriteRule POLA violation?
Date: Mon, 4 May 2015 13:43:30 +0200
User-Agent: KMail/1.9.10
References: <CB72B91C-7F3D-4C34-81C3-108EB323EA94@riggs.me>
 <201505011752.45430@news.perlig.de>
 <0D8C09F0-28DF-4ADF-8771-D941BA096172@riggs.me>
In-Reply-To: <0D8C09F0-28DF-4ADF-8771-D941BA096172@riggs.me>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201505041343.30965@news.perlig.de>

* Jim Riggs wrote:

> > On 1 May 2015, at 10:52, Andr=E9 Malo <nd@perlig.de> wrote:
> >
> > * Niklas Edmundsson wrote:
> >> On Thu, 30 Apr 2015, Yann Ylavic wrote:
> >>> On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs <apache-lists@riggs.me>
> >
> > wrote:
> >>>> Thanks, Yann. I remember looking at this code before. The question
> >>>> remains, though: Is it currently "wrong"? Does it need to be "fixed",
> >>>> or was this distinction made intentionally? Is there a specific use
> >>>> case that requires the regex-matching directives to not get
> >>>> slash-normalized URIs?
> >>>
> >>> I would like it to be fixed, non leading "/+" is equivalent to "/",
> >>> this would break very few (if any) cases IMHO, and may even unbreak
> >>> more ones .
> >>
> >> +1
> >>
> >> I would expect Location and LocationMatch using the same uri for
> >> comparison.
> >
> > Hmm, that assumption is wrong by definition. Location always matches a
> > prefix (a part of a parsed/unparsed url), while LocationMatch always
> > matches the complete URL.
>
> We need to be careful on that phrasing. LocationMatch *can* match the
> complete URL if it is anchored at both ends. By default, though, it will
> match anywhere in the URL if it is unanchored, and it can (with the '/+' =
we
> are discussing here) behave just like Location and match a prefix if it is
> only anchored at the beginning.

Well, yes, careful. It's actually the regex which is anchored, not the URL =
;-)


> However, that documentation is actually not correct. This is not true: "F=
or
> example, <LocationMatch \"^/abc\"> would match the request URL /abc but n=
ot
> the request URL //abc." Based on all of my tests, the leading slash *is*
> collapsed in the *Match and RewriteRule directives. Subsequent slashes
> after the first are not.

It's probably too old.

> So, it is documented, but is there a compelling use case for this? When
> would someone actually need to match against the multiple slashes (unless
> it's some really strange hack someone has implemented)? The only thing I
> can think of is that maybe you want to force a redirect to remove multiple
> slashes, but couldn't a directive in mod_alias(?) maybe handle that if
> deemed necessary?

As said, I'd concur for fixing LocationMatch, but we might consider leaving=
 it=20
as-is for RewriteRule (and document it better), because we may want to give=
=20
the swiss-knife-user something to work on.

Cheers,
nd
=2D-=20
$_=3Dq?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=3Dsplit/\s\s+#/;$_=3D(join''=3D>map{chr(ord(  #             Andr=E9 Malo=
 ;
$_)-1)}split//=3D>$_[0]).$_[1];s s.*s$_see;  #  http://pub.perlig.de/ ;