> On 1 May 2015, at 10:52, André Malo <n...@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-li...@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. >> I would actually go so far as the current state might >> warrant a CVE for being a hidden security risk that might cause >> inadvertent information exposure. > > It *is* documented right here, btw: > http://httpd.apache.org/docs/2.4/mod/core.html#location > > (found it, eventually...) Yay! I knew I had read it somewhere. Good find! 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. 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? Also, yes it is documented, but when I brought it up at a hackathon table full of long-time committers at ApacheCon, no one knew about it, and I had to make an example. This says to me says that maybe it's unexpected behavior and a potential security risk as both Niklas and Ruggeri have suggested. That's why I brought it up in the first place. And so the questions still remain: Right or wrong? Change it or leave it? Expected or unexpected? Security risk or user/configuration error? The world may never know... ;-) I may go ahead and write up a patch this weekend to change them all (*Match and RewriteRule) and then we can all debate it over on bugz too!
