WASD's HTTPd configuration was originally a subset based on the CERN HTTPd. It has now evolved considerably. By default, the system-table logical name HTTPD$CONFIG locates a common configuration file, unless an individual configuration file is specified using a job-table logical name. Simple editing of this file changes the configuration. Comment lines may be included by prefixing them with the hash "#" character. Configuration file directives are not case-sensitive. Any changes to the configuration file can only be enabled by restarting the HTTPd process using the following command on the server system:
$ HTTPD /DO=RESTART
A server's currently loaded configuration can be interrogated. See
10 - Server Administration for further information.
6.2 - Current Directives
NOTE: The format of the configuration file has been changed between version 3 and version 4. This was to support on-line server configuration and administration (see 10 - Server Administration). The version 3 format will still be read by the HTTPd but the first time the configuration is updated on-line it is saved in the version 4 format, described below.
The example configuration file for the WASD HTTPd server can be viewed.
Some directives take a single parameter, such as an integer, string or boolean value. Other directives can/must have multiple parameters. The version 4 configuration requires the directive to be placed on a line by itself and each separate parameter on a separate line following it. All parameter lines apply to the most recently encountered directive.
Note that all boolean directives are disabled (OFF) by default. This is done so that there can be no confusion about what is enabled and disabled by default. To use directive controlled facility it must be explicitly enabled.
One or more (comma-separated if on the same line) internet host/domain names, with "*" wildcarding for host/subdomain matching, to be explicitly allowed access. Also see the Reject directive. Reject directives have precedence over Accept directives. The Accept directive may be used multiple times. Also see DNSLookup directive.
Examples:
[Accept] *.remote.dsto.gov.au *.wasd.dsto.gov.au
Specifies the number of days to record activity statistics, available in report form from the server administration menu (see 10.1 - HTTPd Server Reports). Zero disables this data collection. The maximum is 28 days. 11520 bytes per day, and 80640 per week, is required to store the per-minute data.
Binds a file suffix (extension, type) to a mime content type.
The script name is used to auto-script (see 16.6 - Auto-Scripting)
a specified file type. The description is used as documentation for
directory listings.
Examples:
[AddType] .html text/html - HyperText Markup Language .txt text/plain - plain text .gif image/gif - image (GIF) .hlb text/x-script /Conan VMS Help library .decw$book text/x-script /HyperReader Bookreader book
(Versions prior to 3.2 used this configuration directive for the MIME content-type to determine whether a file was transfered record-by-record or in binary. This is no longer required and should be removed from existing configuration files.)
Specifies a directory listing icon and alternative text for the mime
content type specified in the template.
Examples:
[AddIcon] /icon/-/doc.gif [HTM] text/html /icon/-/text.gif [TXT] text/plain /icon/-/image.gif [IMG] image/gif
[AddBlankIcon] /icon/-/blank.gif [AddDirIcon] /icon/-/dir.gif [DIR] [AddParentIcon] /icon/-/back.gif [<--] [AddUnknownIcon] /icon/-/unknown.gif [???]
Enables or disables BASIC username authentication. See 9 - Authentication and Authorization.
The number of minutes authentication information is cached before being revalidated from the authentication source. Zero disables caching (with a resultant impact on performance as each request requiring authentication is validated directly from the source).
Enables or disables Digest username authentication. See 9 - Authentication and Authorization.
The number of seconds a digest nonce for a GET request (read) can be used before becoming stale.
The number of seconds a digest nonce for a PUT (/POST/DELETE ... write) request can be used before becoming stale.
The number of unsuccessful attempts at authentication before the username is disabled. Once disabled any subsequent attempt is automatically refused without further reference to the authentication source. A disabled username can be reenabled by simply purging the cache.
The maximum number of concurrent client connections before a "server too busy right now ... try again shortly" error is returned to the client.
Granularity of memory blocks allocated to file data, in kilobytes.
Maximum number of files loaded into the cache before entries are reused removing the original contents from the cache.
Maximum size of a file before it is not a candidate for being cached, in kilobytes.
Minimum, total number of hits an entry must sustain before being a candidate for [CacheFrequentSeconds] assessment.
If a file has been hit at least [CacheFrequentHits] times in total and the last was within the number of seconds here specified it will not be a candidate for reuse. See 12 - Cache.
Size of the hash table.
Maximum memory allocated to the cache, in kilobytes.
The interval after which a cache entry's original, content revision time is revalidated against the file's current revision time. If not the same the contents are declared invalid and reloaded.
Includes, as META information, the software ID of the server and any relevant VMS file specification for directory listings, etc.
This value represents time in minutes. If this value is zero CGIplus subprocess may persist indefinitely (excluding explicit and proactive server purging). If non-zero the CGIplus subprocess is terminated the specified number of minutes after it last processed a request. This helps prevent sporadically used scripts from clogging up a system.
Versions of the server prior to 4.3 supplied the full request (header then body) to the script. This was not fully CGI-compliant. Versions 4.3 and following supply only the body, although the previous behaviour may be explicitly selected by enabling this configuration parameter.
The maximum number of DCL/CGI script processing subprocesses that may ever exist concurrently (works in conjunction with [DclSoftLimit].
One or more file type (extension) specification and scripting verb pairs. See 11.3 - Script Run-Time.
The number of DCL/CGI script processing subprocesses after which idle subprocesses are deleted to make room for new ones. The [DclHardLimit] should be approximately 25% more than the [DclSoftLimit]. The margin exists to allow for occasional slow run-down of deleted/finishing subprocesses. If these limits are not set (i.e. zero) they are calculated with [Busy] using "[DclSoftLimit] = [Busy]" and "[DclHardLimit] = [DclSoftLimit] + [DclSoftLimit] / 4".
By default, when a DCL/scripting subprocess is spawned it inherits the server's currently enabled privileges, which are none, not even TMPMBX or NETMBX. If this parameter is enabled the subprocess is created with the server account's SYSUAF-authorized privileges (which should never be other than NETMBX and TMPMBX). Use with caution.
This value represents time in minutes. If this value is zero the use of persistant DCL subprocesses is disabled. If non-zero the zombie subprocess is terminated the specified number of minutes after it last processed a request. This helps prevent zombie processes from clogging up a system. See 11 - Scripting.
Controls directory listings. SELECTIVE allows access only to those directories containing a file .WWW_BROWSABLE. The WASD HTTPd directory access facility always ignores directories containing a file named .WWW_HIDDEN. Also see the DirWildcard directive.
Enables HTML file descriptions during listings. Generating HTML descriptions involves opening each HTML file and searching for <TITLE>...</TITLE> and <H1>...</H1> text to generate the description. This is an obviously resource-intensive activity and on busy servers or systems may be disabled.
Allows specification of the directory listing layout. This is a short string that specifies the included fields, relative placement and optionally the width of the fields in a directory listing. Each field is controlled by a single letter and optional leading decimal number specifying its width. If a width is not specified an appropriate default applies. An underscore is used to indicate a single space and is used to separate the fields (two consecutive works well).
As illustrated in the following examples:
[DirLayout] I__15L__S__D [DirLayout] UI__15L__S__D [DirLayout] 15L__9R__S [DirLayout] 15N_9C_9R_S
To prevent browsing through directories (perhaps due to inadvertant mapping) that have file permissions allowing no WORLD access the server stops listing and reports the error the first time a protection violation occurs. This behaviour may be changed to ignore the violation, listing only those files to which it has access.
Allows specification and display of the RMS file owner information.
Directory listings and trees may be pre-expired. That is, the listing is reloaded each time the page is referenced. This is convenient in some environments where directory contents change frequently, but adds considerable over-head and so is disabled by default. Individual directory listings may have the default behaviour over-ridden using syntax similar to the following examples:
/dir1/dir2/*.*?httpd=index?expired=yes /dir1/dir2/*.*?httpd=index?expired=no /tree/dir1/dir2/?httpd=index?expired=yes /tree/dir1/dir2/?httpd=index?expired=no
If any of the files provided using the DirReadMeFile directive are located in the directory the contents are included at the top or bottom of the listing (or not at all). Plain-text are included as plain-text, HTML are included as HTML allowing markup tags to be employed.
Specifies the names and order in which a directory is checked for read-me files. This can be enabled or disabled using the DirReadme directive. Plain-text are included as plain-text, HTML are included as HTML allowing markup tags to be employed.
Examples:
[DirReadMeFile] readme.html readme.htm readme. readme.txt readme.1st
This enables the facility to force the server to provide a directory listing by providing a wildcard file specification, even if there is a home (welcome) document in the directory. This should not be confused with the DirAccess directive which controls directory listing itself.
Enables or disables connection request host name resolution. This functionality may be expensive (in terms of processing overhead) and make serving granularity coarser if DNS is involved. If not enabled and logging is, the entry is logged against the numeric internet address. If not enabled any accept or reject directive must be expressed as numeric addresses.
This functionality significantly slows request processing. See 13 - Server Performance.
NOTE: From version 4.4 the HTTPd processes initial client connection at AST delivery level. Some NETLIB-supported TCP/IP packages cannot perform host name resolution at this level and will "hang". If using NETLIB with [DNSlookup] enabled and this seems to occur disable it (NETLIB DNSlookup certainly does work with Digital TCP/IP).
Provides a short message recommending action when reporting an error to a client. For example, if a document cannot be found it may say:
(document, or bookmark, requires revision)
When an error message is generated META information is included showing the server version with source code module and line reporting the error. This is useful information during development and often during general use. Only disable if this concerns you.
Number of minutes to allow a connection request to be in progress without submitting a complete request header before terminating it.
Enables or disables the request log. Logging can slow down request processing and adds overhead. The log file name must be specified using the /LOG qualifier or HTTPD$LOG logical name (see Logical Names.
Specifies one of three pre-defined formats, or a user definable format. See 6.4.1 - Log Format.
Specifies a period at which the log file is changed. See 6.4.2 - Log Period.
Allows monitoring via the HTTPDMON utility. Adds slight request processing overhead.
Number of minutes to allow a request to be output before terminating it.
IP port number for server to bind to.
Maximum size of an HTTP POST or PUT method request in Kilobytes.
File created using the POST or PUT methods have the specified version limit applied.
One or more (comma-separated if on the same line) internet host/domain names, with "*" wildcarding for host/subdomain matching, to be explicitly denied access. Also see the Accept directive. Reject directives have precedence of Accept directives. The Reject directive may be used multiple times. Also see DNSLookup directive.
Example:
[Reject] *.remote.dsto.gov.au *.wasd.dsto.gov.au
The server can keep a list of the most recent requests accessable from the server administration menu. This value determines the number kept. Zero disables the facility. Each retained request consumes 256 bytes and adds a small amount of extra processing overhead.
Specifies the physical path to the default query-string keyword search script.
Examples:
Search /ht_root/script/query
This parameter allows multi-homed hosts and multiple port serving to be specified, see 6.3 - Multi-Homed and Multi-Port Services.
Enables or disables Server Side Includes (HTML pre-processing).
Enables or disables Server Side Includes (HTML pre-processing) file access counter.
Enables or disables Server Side Includes (HTML pre-processing) DCL execution functionality.
Enables or disables automatic conversion of VARIABLE record format documents (files) to STREAM-LF, which are much more efficient with this server. The integer is the maximum size of a file in Kilobytes that the server will attempt to convert. Zero disables the conversion.
Specifies the names and order in which a directory is checked for home page files. If no home page is found a directory listing is generated.
Examples:
[Welcome] home.html home.htm home.menu home.mnu
By default the server is defined by the local host name and port specified by either [port] or /PORT. The WASD server is capable of concurrently supporting a number of services on different port numbers and, if the system is configured to be multi-homed (see 5.4 - Multi-Homed Hosts With Digital TCP/IP), more than one host name. Using the [Service] configuration parameter or the /SERVICE qualifier the server creates an HTTP service for each specified. If the host name is omitted it defaults to the local host name. If the port is omitted it defaults to 80.
This rather contrived example show a server configured to provide four services over two host names.
[Service] alpha.wasd.dsto.defence.gov.au 8080 beta.wasd.dsto.defence.gov.au beta.wasd.dsto.defence.gov.au:8000
This capability combined with conditional rule mapping (see
8.5 - Conditional Mapping) offers versatile and powerful service
provision. The first port specified in the service list becomes the
"official" port of the server, using the local host name.
6.4 - Access Logging
WASD provides a versatile access log, allowing data to be collected in
Web-standard common and combined formats, as well as
allowing customization of the log record format. It is also possible to
specify a log period. If this is done log files are automatically changed
according to the period specified.
6.4.1 - Log Format
The configuration parameter [LogFormat] and the server qualifier /FORMAT specifies one of three pre-defined formats, or a user definable format. Most log analysis tools can process the three pre-defined formats. There is a small performance impost when using the user-defined format, as the log entry must be specially formatted for each request.
The user defined format allows customised log formats to be specified using a selection of commonly required data. The specification must begin with a character that is used as a substitute when a particular field is empty (use "\0" for no substitute, as in the "windows log format" example below).
Two different "escape" characters introduce the following parameters:
A "!" followed by
A "\" followed by
Any other character is directly inserted into the log entry.
Note on "PA" and "RQ"
The "PA" and "RQ" have distinct roles. In general the
"RQ" (request) directive will always be used as this is the full
request string; script component (if any), path string and query string
component (if any). The "PA" directive is merely the path string after
any script and query string components have been removed.
Examples
-!CN - !AU [!TC] \q!RQ\q !RS !BY
-!CN - !AU [!TC] \q!RQ\q !RS !BY \q!RF\q \q!UA\q
\0!TC\t!CA\t!SN\t!AR\t!AU\t!ME\t!PA\t!RQ\t!EM\t!UA\t!RS\t!BB\t
-!CN - !AU [!TC] \q!RQ\q !RS !BY !ES
The access log file may have a period specified against it, producing an automatic generation of log file based on that period. This allows logs to be systematically named, ordered and kept to a managable size. The period specified can be one of
The log file changes on the first request after midnight of the new period. When using a weekly period the new log file comes into effect on the first request following midnight on the specified day.
When using a periodic log file, the file name specified by HTTPD$LOG or the configuration parameter [LogFileName] is partially ignored, only partially because the directory component of it is used to located the generated file name. The periodic log file name generated comprises
HT_LOGS:WASD_80_19971013_ACCESS.LOG
For the daily period the date represents the request date. For the weekly period it is the date of the previous (or current) day specified. That is, if the request occurs on the Wednesday for a weekly period specified by Monday the log date show the last Monday's. For the monthly period it uses the first.