The <FilesMatch> directive is using the superior directory if the access through the URL is without a / at the end. Here is an example for better understanding: I created in the htdocs directory a new directory and named it test. In this directory have i created a .htaccess with the content: Allow from all <FilesMatch ^test> Deny from all </FilesMatch> And there are two empty files named test.php and another_file.php. Now the following happens: http://localhost/test -> Error 403 forbidden http://localhost/test/ -> Access is allowed and i can see the index http://localhost/test/test.php -> Error 403 forbidden http://localhost/test/another_file.php -> Access is allowed The problem is, that ^test matches of the superior directory if there is no / at the end of the URL and the access is denied. If i delete the .htaccess the following happens: http://localhost/test -> Switches to http://localhost/test/ and the i can see the index http://localhost/test/ -> Access is allowed and i can see the index http://localhost/test/test.php -> Access is allowed http://localhost/test/another_file.php -> Access is allowed
Good detailed problem description, but in the wrong place. Please ask configuration questions on the user's list, don't open bug reports.
I have already read the following documentation: http://httpd.apache.org/docs/2.2/mod/core.html There is nothing what explains this behavior. Just try to make a solution with my example. If this is really a bug, nobody can resolve this without a bugfix.
If you don't think the server is behaving the way you expect it to, you should always ask about it on the users list. Maybe someone will say "yes, that's a bug, please open a bug report" but it's much more likely that someone will explain to you how to configure the server to behave the way you want.
re-opening for some more eyes. Requesting a directory e.g. "/test" without a trailing slash, ap_file_walk applies Files/Filesmatch containers to the "basename" (/test->test) that live in /test/.htaccess Is this as desired or should it be short-circuited (skipped, treated as an empty iflename, ???) if we have the above case? Sounds like a candidate for trunk-only change.
FWIW, I took a look this afternoon. This report needs to move to users@ so we can diagnose the OP's real problem, but playing with a .htaccess showed up a more serious bug. I need to poke about a bit more before reporting/fixing it. I guess none of the devs tend to use .htaccess ...
(In reply to comment #5) > FWIW, I took a look this afternoon. This report needs to move to users@ so we > can diagnose the OP's real problem, but playing with a .htaccess showed up a > more serious bug. I need to poke about a bit more before reporting/fixing it. I take that back: my issue was a <Location /> overriding the .htaccess (I blame the heat). I can confirm the behaviour reported by the OP. Still thinking about it. The least we should do is document more clearly some of the counter-intuitive things that happen on a merge.