> On 28 Apr 2015, at 17:55, Yann Ylavic <ylavic....@gmail.com> wrote:
>
> It seems that while <Location> is compared to ap_no2slash(r->uri),
> <LocationMatch> is matched against r->uri directly.
> That's probably the "issue".
>
> A possible fix (untested) could be:
>
> Index: server/request.c
> ===================================================================
> --- server/request.c (revision 1674695)
> +++ server/request.c (working copy)
> @@ -1446,7 +1446,7 @@
> pmatch = apr_palloc(rxpool, nmatch*sizeof(ap_regmatch_t));
> }
>
> - if (ap_regexec(entry_core->r, r->uri, nmatch, pmatch, 0)) {
> + if (ap_regexec(entry_core->r, entry_uri, nmatch, pmatch, 0))
> {
> continue;
> }
>
> @@ -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-li...@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.
>>
>> Consider:
>>
>> <Location "/slash/foo">
>> ...
>> </Location>
>>
>> vs.
>>
>> <LocationMatch "^/slash/foo">
>> ...
>> </LocationMatch>
>>
>>
>> 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?
>>
>> +-------------------+--------------+--------------+--------------+
>> | 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 |
>> +-------------------+--------------+--------------+--------------+
>>
