Map- Map URLs to actual files
Pass- Accept a request
Fail- Fail a request
Redirect- Redirect a request
Protect- Set up protection
DefProt- Default protection setup
Exec- Executable server scripts
Fail.The server uses the top rule first, then each successive rule unless told otherwise by a
*. (Versions earlier than 3.0 support only a single wildcard.) The result string may have wildcards only if the template has them. In this case they expand to matched strings in respective order.
Whitespace, (literal) asterisks and backslashes are allowed in templates if they are preceded by a backslash.
The tilde character (see user-supported directories) just after a slash (in other words in the beginning of a directory name) has to be explicitly matched, i.e. wildcard does not match it.
Maptemplate exactly, the result string is used instead of the original string and applied to successive rules.
Maptemplate with wildcard, then the text of the request which matches the wildcard is inserted in place of the wildcard in the result string to form the translated request. If the result string has no wildcard, it is used as it is.
Mapsubstitution takes place, the rule scan continues with the next rule using the new string in place of the request. This is not the case if a
Failis matched: they terminate the rule scan.
Redirectrule to tell
httpdto redirect the request to another server. If the client program is smart enough user won't even notice that the document is retrieved from a different server.
http:and the host name).
Redirect /hypertext/WWW/* http://www.cern.ch/WebDocs/*This redirects everything starting with
www.cern.chinto virtual directory
/WebDocs. For example,
/hypertext/WWW/would be redirected to
DefProtrules. Their syntax is the following:
Protectrule. If that
Protectrule doesn't specify setup-file, the one from the latest
DefProtrule is used.
If setup-file is not specified the one from previous
DefProt rule will be used. If none have
matched access to the file is forbidden.
Setup file can be omitted from
Protect rule, but it is
DefProt rule. If setup file is omitted it
is not possible to give the uid.gid part, either.
uid.gid are the Unix user id and group id (either by name or by
number, separated by a dot) to which the server should change when
serving the request. These are only meaningful when the server is
root. If they are missing they default to
Note: Uid and gid are inherited from
DefProt rule to
only when the setup-file is also inherited.
If setup-file is specified for
Protect rule but
uid.gid is not, they default to nobody.nogroup
regardless of the previous
This is to avoid accidentally running the server under wrong user id
with wrong setup file. This information should logically go into the
protection setup file, but for safety reasons it cannot be done,
because a non-trustworthy collaboration could specify it to be
root. This way only the main
control user and group ids.
Exec template scriptIn both template and script there must be a
*wildcard, that matches everything starting from the script filename. This is to enable
httpdto know what is the script name and what is the extra path information to be passed to the script.
/your/url/doitto execute the script
/usr/etc/www/htbin/doit.You do this by saying:
Exec /your/url/* /usr/etc/www/htbin/*Here asterisk matches the script name
doit(and everything else that follows it). Usually people use some fixed keyword in front of the pathname in URL to point out that the document is actually a script call. Often this keyword is
/htbin. That is, usually your
Execrule looks like this:
Exec /htbin/* /usr/etc/www/htbin/*and all the URLs pointing to the scripts start with
/htbin, for example
/htbin/doitin the previous example.
/htbinthat mapped them to scripts in a directory specified via
HTBin /your/htbin/directoryThis is still handled automatically by
httpd, by translating it to its equivalent
Exec /htbin/* /your/htbin/directory/*Always use
Execinstead -- it is more general.