Format of rules file
The server configurations file (a.k.a rules file) is a text file that the
server reads at program startup. It contains commands (rules) that
customize the server operation for a particular environment.
Directory:
-
-
Select link to jump directly to section of interest.
- Translation Rules
-
exec, fail,
map, pass,
redirect,
userdir
- Data Mapping Rules
-
suffix,
presentation
- Protection Rules
-
authenticator,
defprot,
hostprot,
protect
- Miscellaneous Rules
-
# (comment),
accesslog,
dnslookup,
htbin,
include,
search,
tracelevel
- Operation
Translation Rules
-
Translation rules screen and direct processing of request based upon
its URL.
- exec dir-template
[node::["obj-spec"]]script-directory
- If URL matches dir-template, invoke script in corresponding
script directory specified by script-directory. Note that
dir-template must be in unix format (/dir/dir...) and
script-directory must be in VMS format (disk[dir]). If the
script-directory is prefixed with a DECnet node, the
script task will be started on that node instead of the default
(0:: or node part of WWWEXEC logical),
- fail template
- Prohibit access to addresses matching template.
- map template result
- If address matches template, use result string for future rules. Template
and result must be in unix file specification format (/device/dir/dir/...).
- pass template [result]
- if address matches the template, use it as is. If result argument
is present, perform map operation and use translation.
- redirect template url
- If address matches template, a redirect will be sent to the client
redirecting it to the specified URL. The URL must be in absolute
format (include scheme and host). Local redirects are redundant
since they can be handled by map directives.
- userdir sub-dir
- if address matches template /~username/xxx, replace with
/device/directory/sub-dir/xxx where device and directory are specified
username's default device and directory. Note that sub-dir string must
not have a leading slash. (e.g.
userdir web
).
Data Mapping Rules
-
The data mapping rules, suffix and
presentation, control how the server reads and presents the
contents of the files it serves.
- suffix [.sfx|*|*.*]
data-type encoding [quality]
- Bind data-type to file suffix. Special values for suffix fields are
* (match any file that hasn't matched another suffix) and *.* (
(match file with suffix that hasn't matched another suffix).
The data-type field is the MIME content-type.
Data encodings:
BASE64 QUOTED_PRINTABLE 8BIT 7BIT BINARY
x-token
.
- presentation
data-type [node::["obj-spec"]]converter-script
- If data-type of document matches data-type, use converter
script specified by converter-script to convert document,
returning result to client instead of original document. Note that
converter-script must be in VMS format, the default
directory for the converter script is WWW_ROOT:[000000]. If the
converter-script is prefixed with a DECnet node, the
script task will be started on that node instead of the default
(0:: or node part of WWWEXEC logical),
Protection Rules
-
The protection rules restrict access to the server resources based upon
who the user is.
- authenticator image
- The authenticator rule specifies the name of the authenticator image
used to validate accesses to files protected with
protect rule. This image is run by a sub process
created by the server at initialization. If an authenticator is not
present, any attempts to access files protected by protect
rules will automatically fail.
- defprot dir-template
protection-setup-file
- Sets default protection setup file for protect and
hostprot directives.
- hostprot template
[protection-setup-file]
- Same as protect command below except that
simpler (level 1)
protection checks take place. Only groupmask directives in setup
file are processed and only items without usernames (i.e.
@xxx.xxx.xxx.xxx) are checked. Note that authenticator does
not have be run in order to use hostprot.
- protect dir-template
[protection-setup-file]
- If address matches dir-template, validate access against
that granted by corresponding protection setup file. The setup file
may be sepcified in either UNIX or VMS format.
Miscellaneous Rules
-
Other rules.
- # comment
- A comment line is denoted by beginning the line with the # character.
Comment lines are ignored by the server.
- accesslog logfile
- Enables logging of client accesses to specified log file using
'common' Web server log file format. The specified file (VMS or
UNIX format) is opened for append or created if it does not
exist.
- dnslookup [on|off]
- Enables/Disables Domain Name Server lookups of the host names for
remote clients. If disabled (the default), the log file reports the
host by IP address.
- htbin directory (obsolete)
- Superceded by exec directory, for compatibility this directive is
mapped internally to "exec /htbin/* directory".
- include config-file
- Read specified file and process records as if they were being read
from original file at the point of the include statement. Includes
may be nested to 20 levels (who would do that?).
- search dummy
- Enables general search function. The dummy arugment is
ignored. General search is currently handled invoking the WWWEXEC
DECnet task with the SEARCH sub-function.
- tracelevel level [tracefile]
- Set trace level and trace file for debugging. You may specify
level
as either a numeric constant or an environment variable (DCL symbol)
name. The trace level has the same meaning as the environment
variable http_log_level and will override it. The optional tracefile
parameter specifies a separate file to record the trace, if missing
trace entries will go to the standard error log file.
-
-
-
-
Operation
At server startup, rules file is read sequentially, skipping comments.
The presence and/or values of any 'search', 'authenticator', 'suffix', and
'presentation' commands is noted/saved. All other rules are tokenized and
saved in a table for processing in the same order that they occur in the rules
file.
The ident portion of a URL is translated by making a unescaped copy of it in
a work area and testing the work area copy against each entry in the tokenized
rule list. A rule that matches against the translation in the work area
may rewrite the translation (see map rule), subsequent
tests for
triggering rules will be made against the new translation.
The data from suffix rules is kept in a different data structure optimized
for finding highest quality representation supported by a client request.