oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Apache Web-Serving with Mac OS X, Part 6
Pages: 1, 2, 3

Aliasing Directories

The following lines load this module:

    LoadModule alias_module       libexec/httpd/
     AddModule mod_alias.c

Remember when we were talking about turning on CGIs waaaay back in Part 2? If you do, you may recall that we described ScriptAlias as a "way to map a URL to a location on our hard drive." mod_alias is the magical module that offers this ability, as well as the Redirect and RedirectMatch examples we saw in Part 4.

You can read more about the other capabilities of mod_alias at the Apache Web site, but there's nothing that will surprise you -- just different ways of doing similar tasks. Here's an example of making /Users/aku/Pictures/ accessible as

    Alias /~aku/pictures/ "/Users/aku/Pictures/"

When creating aliases like this, you want to be careful about "permissions." Mac users have never had to deal with permissions before so they can be an interesting thing to muddle through. We won't get into a detailed description here, but in a simplified nutshell:

  • User directories like Pictures, Library, Music, and so forth are not normally viewable by the Apache Web server -- the permissions are too restrictive.
  • Simply creating an Alias will probably not work. Sure, you're telling Apache to serve files from that location, but that directory is still protected from other users (one of which being www, which Apache runs as). Again, the permissions are still too restrictive.
  • In this case, to give Apache permission to access the /Users/aku/Pictures/ directory, we need to say chmod 755 /Users/aku/Pictures in our Terminal. This loosens the permissions, and allows Apache to "read" (but not "write") files from that directory.

Here's another example of aliasing, only more powerful:

    <Directory "/Developer/Documentation/">
        Options FollowSymLinks Indexes

    AliasMatch ^/~penfold/docs/(.*) "/Developer/Documentation/"

Here we're taking every file and directory accessed under /Users/penfold/docs, and instead serving them from /Developer/Documentation. Accessing would serve /Developer/Documentation/Carbon/carbon.html -- likewise, would get you an index of the entire /Developer/Documentation/Carbon/ directory.

Directory Indexes

The following lines load this module:

   LoadModule dir_module         libexec/httpd/
    AddModule mod_dir.c

mod_dir controls DirectoryIndex, which we talked about two installments ago. Briefly, it controls what files should be displayed by default when a directory listing is requested. There's nothing more to add here besides the clarification that CGI scripts (index.cgi, for example) can be used as well. Move along, please.

Directory AutoIndexes

The following lines load this module:

    LoadModule autoindex_module   libexec/httpd/
     AddModule mod_autoindex.c

mod_autoindex controls the generated directory listings we talked of in Part 4. There's a lot more power behind this module than we've discussed. For instance, you can control the initial sorting order, the descriptions of the files shown, and even include headers or footers (in HTML with optional server side includes, or plain text).

Take the following example. This will add a descriptive element to all our JPEG images and a different description to all our PHP files. When Apache auto generates the index, it'll display our blurbage for each matching file.

    <Directory "/Users/mummra/Sites/">
       Options Includes Indexes Multiviews
       AllowOverride All

       IndexOptions FancyIndexing
       AddDescription "This is a short description" *.jpg
       AddDescription "This is a description of questionable quality." *.php

There's one problem, however, and that's length. With the look and feel of Apache's auto index, the description is either cut off arbitrarily, or else the browser will scroll the data off screen. A wee voice pops in your head (not a Keanu Reeves sort of voice -- more scary godmotherish): "If only we could add some HTML and make things smaller!"

Ahhh, but we can, young grasshopper, and that's where HeaderName and ReadmeName come in. These directives tell Apache what files to use as the header (controlled by HeaderName) and footer (controlled by ReadmeName) of a directory listing. By default, these files are HEADER.txt (or .html) and README.txt (or .html).

With that in mind, I'll create HEADER.html:

       <style type="text/css"><!--
          pre { font-size: 14px; font-family: times, serif; }
    <h1>Smurferific Directory Listings</h1>

I'll also tweak our configuration a little:

    <Directory "/Users/mummra/Sites/">
       Options Includes Indexes Multiviews
       AllowOverride All

       IndexOptions FancyIndexing SuppressHTMLPreamble DescriptionWidth=*
       AddDescription "This is a <u>short</u> description" *.jpg
       AddDescription "This is a description of questionable quality." *.php

Besides the fact that we've now added our own HTML header that makes the font smaller (via HEADER.html), we've also told Apache not to spit out its normal header code (with SuppressHTMLPreamble). Our descriptions will no longer be truncated since we've given ourselves unlimited length via DescriptionWidth (they may still scroll off the end of the browser window, though).

You may also notice that we've added an underline to one of our descriptions. Including HTML within the AddDescription comes with no restrictions, but you do want to be careful about truncating. If you're not, the HTML code could be cut in half, distorting the rest of your page (above, there's nothing to worry about since we've turned off truncating with DescriptionWidth).

There are many other options available. With a little ingenuity, a user wanting to offer a large collection of downloadable files could have a complete Web site in ten minutes. Think of it -- thousands of MP3s sorted and described, using only two HTML files and some AddDescription lines. Need to add a new song? Just stick it in the directory, add a description, and you're done. No muss, no fuss, and you didn't need any database or programming knowledge.

Of course, you may not like the idea that millions of anonymous Internet users could leech your MP3 collection. With the tips described soon in the "Username-Based Access Control" section, you'll have no speed bumps in your world-conquesting travels (narf!).

Pages: 1, 2, 3

Next Pagearrow