The maintainer #defines the variable TILDE_USER_PWFILE in the configuration file config.h, then chooses "/~" to be the special string and the server consults the system password file and changes the root data directory to "/home/john/public_html" (assuming /home/john is john's home directory) and simultaneously deletes the "/~john". Thus the URL becomes http://hostname/foo.html with rootdir "/home/john/public_html" so the file accessed is /home/john/public_html/foo.html. Both the string "/~" and the subdirectory "public_html" are configurable by changing values in config.h. They are called TILDE_USER_STRING and PUB_HTML respectively. Thus to avoid the problematic character '~' a maintainer might set TILDE_USER_STRING to "/people/" and might set PUB_HTML to "wwwstuff". Then the URL "http://hostname/people/john/foo.html" would result in the equivalent of a URL request for "/foo.html" with a data root of "/home/john/wwwstuff". Note that TILDE_USER_STRING must be everything before the user name at the beginning of the URL. Thus it needs to be "/people/" and not "/people".
As a security measure the maintainer can set a variable LEAST_UID (with default value 100) in config.h and any attempt to use "/~user/" will fail if the user id of "user" is less than this value.
#define TILDE_TABLE /usr/local/etc/wn.dir.tableand the file wn.dir.table contains lines like
john:/home/john/public_htmlthen the URL http://hostname/~bob/foo.html will be translated to a request for /foo.html with the data root directory set to /home/bob/public_html. The file consulted should have lines consisting of a name followed by a ':' followed by the full system path of the desired root data directory. Of course, the name need not be the name of a user. One difference with this method is that the PUB_HTML value from config.h is not used and if you want it to be part of the path it should be in the path part of each entry in your table.
bob:/home/bob/public_html
etc.
This method of changing hierarchies uses the TILDE_USER_STRING in precisely the same way that the pasword file method does. In other words, if TILDE_USER_STRING is #defined to be "/people/" instead of "/~" then http://hostname/people/john/foo.html will be translated to a request for /foo.html with root data directory /home/john/public_html.
More precisely when the TILDE_USER_STRING is at the start of the URI it is deleted and everything after it up to the next '/' is taken to be the name to be looked up in the table or password file. This name is also discarded and the remainder of the URI is taken to be the path of the desired document relative to the new data hierarchy root.
When you use the table lookup method to retarget data root directories of user hierarchies, you can specify a directory that is not even on the local server host. To do this, specify a lookup table entry consisting of a name, a double colon (rather than a single colon), and the URL to the user's data root directory. For example, if user jim has a data root that is accessed as ~jim on otherhost, you can specify the lookup table entry like this:
jim::http://otherhost/~jimThen when a client sends a request like http://hostname/people/jim/path/file.html to your server, the server will return a redirect to the client for http://otherhost/~jim/path/file.html.
The ability to specify non-local user hierarchies is useful when you run a primary web server (e.g., www.your.site.edu) and want all your users to be able to advertise home page URLs that begin with http://www.your.site.edu/ whether or not their accounts are actually on that host.