Someone just the other day pointed out that the rules file wasn't very well
documented. I then put in a couple of examples.
Here is the example code (its on the web, linked to the
documentation node about the rule file)
Examples of HTTP daemon rule files
RULE FILE EXAMPLES
A basic rule file for the http daemon might look like this:
map / /welcome.html
map /* /u/john/public/*
pass /u/john/public/*
fail *
The first line maps the root document onto a specific document about the
server.
The second line maps all document names onto filenames in a particular
directory.
The third line allows access to all documenst in that directory.
The fouth line disallows access to all other documents. (There won't be in
any in this case because of the mapping, but its wise to put in for later).
Second example
map / /tnotes/welcome.html
map /tnotes/* /u/john/public/*
map /seminars/* /u/jane/seminars/*
pass /u/john/public/*
pass /u/jane/seminars/*.html
fail *
The first line maps the root document onto a specific document about the
server. (See etiquette)
The second line maps all document names starting with /tnote/ onto filenames
in a particular where john maintains the technical notes. If someone else
takes over the technical notes, we can change this. Here we are starting to
distinguish between document names and file names. This can be carried much
further if necessary, but one level of mapping is enough to allow for
changes of administration of different areas.
The third line separately maps the seminar information into Jane's
directory.
The third and forth line enable access to anything in John's "public"
directory, and any .html file in Jane's "seminar" directory tree. Note here
that the * maps to any sequence INCLUDING SLASHES so all files in any
subdirectory of /u/jane/seminars will be enabled so long as they end in
.html.
The bottom line will pick up for example any attempt to use the server to
access non-html files in Jane's seminar directory.