A more powerful example of using maps is the ipfilter module. Its arguments are a regular expression, a module name, and the arguments for that module. The addresses of the host issuing a request is matched against the regular expression - similar to authhost - and the named module is invoked with the given arguments if the match succeeds. ipfilter can be combined with the userdir module to allow user directories that are only visible from the local net:
map /home/ ipfilter #?.local.net userdir local_html map /home/ userdir public_html
In this example, requests from machines on local.net will be
searched for in local_html. If a match is found, it will
be sent. Otherwise - for a request from outside of local.net or for
one not found in local_html, the users public_html
directory will be checked.
An obvious thing to want to do (and a featuer that some commercial servers don't provide) is the ability to do either host authentication or basic authentication. That is, if the request comes from a trusted host, allow it. Otherwise, if the user has an appropriate username and password, allow it. If neither is true, deny the request. The modules seen so far allow this, like so:
map /semi_private/ ipfilter ~(#?.trusted.net) authbasic roamers map /semi_private/ directory data:semi_private_html/
In this example, if the request does not come from a machine on
trusted.net, ipfilter invokes the authbasic module for the realm
"roamers". That either returns an authentication failure or will do
nothing. If ipfilter does not invoke authbasic, or authbasic does
nothing, the next map is used, which tries to resolve the request in
the data:directory/semi_private_html.
As another example, the headerfilter module takes the name of an http header, a regular expression against which to match the value of the header, and the name of a module to run. The omnipresence server is used this ability to route different versions of a browser to the home pages appropriate for that browser.
Finally, several of the web servers I am familiar with can be configured to check the identity of the remote user via the IDENTD protocol. However, these servers either check for all requests or for none. Since most sites on the internet do not run the IDENTD server, doing an IDENTD check for every request just causes unwanted delays. Similarly, if you are only interested in identity checking for a small set of files, these servers identity check requests for all files on the server, which is undesirable.
An IDENTD module is nearly identical to IDENTD code in any server. The module accepts a request, does an IDENTD check on the socket associated with the request, adds a notation to the request indicating the results of that check, and then continues. However, by being part of the map/module system, the user automatically gains the ability to apply identity checking to selected parts of the document tree, or to filter requests based on ip address - or other things - to prevent unwanted IDENTD requests.