I wrote yesterday that Apache HTTPd's <Directory > directive doesn't quite work on case-insensitive filesystems such as HFS+. Here I offer a couple of work-arounds.
This is only a problem for files sub-directories that are exposed to the URI space by the server navigating through the filesystem. You can protect your entire document root through a RedirectMatch directive rule, for example. This works because / on your server's URI space is explicitly mapped to a location in the filesystem (ok, also because there are no case variants of /). However, it wouldn't work for a <Location /foo> rule if foo is a file or directory in your document root, because other URIs (eg. /Foo) can be used to get to that file or directory, and you only specified one.
(This almost makes me suggest that we need a <CaseInsensitiveLocation > tag, but fundamentally, this issue is about the filesystem, and we don't want to add a new tag for every possible semantic of all possible resource stores, so no, I'm not going to suggest that.)
The good news is that until this gets fixed, we can come up with a couple of work-arounds.
The first is pretty straighforward. If you want to change the configuration for a directory in your doc root, stick a .htaccess file in there. No matter what URI was used to get to the directory, the server will always find the .htaccess file and read it. There are a few drawbacks here, but they may be insignificant for many users:
-
You have to enable the use of .htaccess files on your server and allow overrides for the configuration directives you want to use in them. This may be a problem if people you don't trust to use those directives have access to those files, which isn't an uncommon arrangement.
-
If you edit your web site using WebDAV, you may not be able to edit .htaccess files via DAV, as access to those files is disables in the default config. If you use a different virtual host for DAV access (you pretty much have to if you are going to have any kind of processing done on served files, such as server-side includes, php, etc.), so you may choose to disable access to .htaccess files on the main server and allow it via DAV. That rules out using .htaccess for configuring the DAV server, however, so if you want per-directory config on DAV also, this won't work.
-
There is a small performance penalty, as the server has to open and handle the extra file. This is probably insignificant unless you have a very high-volume site.
Another option, the one I am using, is to move the directory in question out of your server's URI space (i.e. out of document root) and use an alias. For example, we'd move /path/to/docroot/foo to /path/not/in/docroot/foo and add some config options:
RedirectMatch Permanent "^/foo$" http://myservername/foo/
Alias /foo/ /path/not/in/docroot/foo/
<Location /foo>
...options...
</Location>
This involves a bit more cofiguration, but solves the problem nicely. Because foo is no longer in your document root, the only URI that will get you to it is /foo/. You can use <Location /foo> as well as <Directory /path/not/in/docroot/foo> here because now that /foo is the only URI that will get you there, this should be sufficient.
The RedirectMatch directive isn't strictly necessary, but it emulates that the server normally does when you access a directory without the trailing slash, and redirects you to the URI with the trailing slash. You can let the server do this for you by omitting the trailing slashes in the arguments to the Alias directive, but then you have a potential conflict if you have another URI /foobar on your server; this avoids that.