httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo ...@perlig.de>
Subject Re: *Match, RewriteRule POLA violation?
Date Mon, 04 May 2015 11:43:30 GMT
* Jim Riggs wrote:

> > On 1 May 2015, at 10:52, André 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: "For
> example, <LocationMatch \"^/abc\"> would match the request URL /abc but not
> 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 
as-is for RewriteRule (and document it better), because we may want to give 
the swiss-knife-user something to work on.

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

Mime
View raw message