httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Riggs <apache-li...@riggs.me>
Subject Re: *Match, RewriteRule POLA violation?
Date Thu, 30 Apr 2015 12:57:52 GMT
> On 28 Apr 2015, at 17:55, Yann Ylavic <ylavic.dev@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-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.
>> 
>> 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    |
>> +-------------------+--------------+--------------+--------------+
>> 


Mime
View raw message