Return-Path: 
 <dev-return-82521-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 42D0C172F8
	for <apmail-httpd-dev-archive@www.apache.org>;
 Thu, 30 Apr 2015 12:59:13 +0000 (UTC)
Received: (qmail 69354 invoked by uid 500); 30 Apr 2015 12:59:12 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 69291 invoked by uid 500); 30 Apr 2015 12:59:12 -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 69281 invoked by uid 99); 30 Apr 2015 12:59:12 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Apr 2015 12:59:12 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for dev@httpd.apache.org)
Received: from [54.191.145.13] (HELO mx1-us-west.apache.org) (54.191.145.13)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Apr 2015 12:59:07 +0000
Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com
 [209.85.213.44])
	by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with
 ESMTPS id E656F2620A
	for <dev@httpd.apache.org>; Thu, 30 Apr 2015 12:58:46 +0000 (UTC)
Received: by yhcb70 with SMTP id b70so12835523yhc.0
        for <dev@httpd.apache.org>; Thu, 30 Apr 2015 05:57:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:content-type:mime-version:subject:from
         :in-reply-to:date:content-transfer-encoding:message-id:references:to;
        bh=CSkekE2tI9Jk8WAnqkP1TLYKURtTmZaPXz00p5tsIBA=;
        b=EcwKrhG96cqdvBqOUTpH1jxurPcnPwoLsgfdMLWaLDP0gPRwR+KZ/vbeo8VVJhzF14
         9ePo2ovaUMFw3Nu8eYFEExHJfVkbU0RpUo87oiOW3NBvWfjumOokqb5/v5dfpmwRtkiP
         M2sKyugmHdLRZeQiDMMUd469Hl+hRshhsiwk0PrT0kOaMXt86wZTIT0P52t5n4GKa15s
         WJHwDT0Nop+ms4e+8VacgoZUZ6lr71ltEF4b6YdcBgI7qmczV6oNzEx7QX+jL4G2JZFF
         VKAIgJZvo78f60hISS7Yjh9bXabBTG+K0GWw3XupwPI8/fT95ihGlA7mEFpVq6NHxIVl
         E12g==
X-Gm-Message-State: 
 ALoCoQmEVcKhdxdwdajQnEXyr5+wJXYEBmyrOWUIJX+Nu8vdMoy/rZ1Bz9c9i2fvOr+n2wLjEX9D
X-Received: by 10.170.194.9 with SMTP id l9mr3580869yke.28.1430398675150;
        Thu, 30 Apr 2015 05:57:55 -0700 (PDT)
Received: from jhriggs.office.rusticisoftware.com ([50.252.68.50])
        by mx.google.com with ESMTPSA id
 a11sm2032941yha.15.2015.04.30.05.57.53
        for <dev@httpd.apache.org>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Thu, 30 Apr 2015 05:57:53 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: *Match, RewriteRule POLA violation?
From: Jim Riggs <apache-lists@riggs.me>
In-Reply-To: 
 <CAKQ1sVNAsWvjhow=5FMY7Q3aQY2_9w5xcz+aV7QdjtpMC17jbg@mail.gmail.com>
Date: Thu, 30 Apr 2015 07:57:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6954384F-97E6-4590-A89D-6BE0B633FFE3@riggs.me>
References: <CB72B91C-7F3D-4C34-81C3-108EB323EA94@riggs.me>
 <CAKQ1sVNAsWvjhow=5FMY7Q3aQY2_9w5xcz+aV7QdjtpMC17jbg@mail.gmail.com>
To: dev@httpd.apache.org
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Checked: Checked by ClamAV on apache.org

> On 28 Apr 2015, at 17:55, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>=20
> It seems that while <Location> is compared to ap_no2slash(r->uri),
> <LocationMatch> is matched against r->uri directly.
> That's probably the "issue".
>=20
> A possible fix (untested) could be:
>=20
> Index: server/request.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- server/request.c    (revision 1674695)
> +++ server/request.c    (working copy)
> @@ -1446,7 +1446,7 @@
>                     pmatch =3D apr_palloc(rxpool, =
nmatch*sizeof(ap_regmatch_t));
>                 }
>=20
> -                if (ap_regexec(entry_core->r, r->uri, nmatch, pmatch, =
0)) {
> +                if (ap_regexec(entry_core->r, entry_uri, nmatch, =
pmatch, 0)) {
>                     continue;
>                 }
>=20
> @@ -1456,7 +1456,7 @@
>                         apr_table_setn(r->subprocess_env,
>                                        ((const char
> **)entry_core->refs->elts)[i],
>                                        apr_pstrndup(r->pool,
> -                                       r->uri + pmatch[i].rm_so,
> +                                       entry_uri + pmatch[i].rm_so,
>                                        pmatch[i].rm_eo - =
pmatch[i].rm_so));
>                     }
>                 }

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?


> On Mon, Apr 27, 2015 at 10:52 PM, Jim Riggs <apache-lists@riggs.me> =
wrote:
>> This came up at ApacheCon a couple of weeks ago. I just took this =
knowledge for granted, as I have always accounted for it, but both Rich =
and Trawick were surprised. As I thought about it some more, it seems =
this may be a POLA violation. Thoughts? If we agree it should be fixed, =
I can make the bugz and make a patch.
>>=20
>> Consider:
>>=20
>> <Location "/slash/foo">
>> ...
>> </Location>
>>=20
>> vs.
>>=20
>> <LocationMatch "^/slash/foo">
>> ...
>> </LocationMatch>
>>=20
>>=20
>> These do not behave the same if multiple slashes are used. The =
leading slashes are always coalesced, so "^/..." is fine; however, any =
intermediate slashes are not. So, in order for the LocationMatch =
directive above to behave the same as the Location, it has to be =
specified as "^/slash/+foo". Like I said, I have always accounted for =
this in my regexps, but it doesn't seem "right". Should the URL be =
normalized before being passed to regex-matching directives, or is there =
a specific reason that is not done?
>>=20
>> +-------------------+--------------+--------------+--------------+
>> | Path              |   Non-Regex  |    *Match,   |    *Match,   |
>> |                   |  Directive:  | RewriteRule: | RewriteRule: |
>> |                   |  /slash/foo  |  ^/slash/foo | ^/slash/+foo |
>> +-------------------+--------------+--------------+--------------+
>> | /slash/foo        |     Match    |     Match    |     Match    |
>> +-------------------+--------------+--------------+--------------+
>> | ////slash/foo     |     Match    |     Match    |     Match    |
>> +-------------------+--------------+--------------+--------------+
>> | /slash///foo      |     Match    |      XXX     |     Match    |
>> +-------------------+--------------+--------------+--------------+
>> | ////slash///foo// |     Match    |      XXX     |     Match    |
>> +-------------------+--------------+--------------+--------------+
>>=20