WASD VMS Web Services - Features and Facilities

2 - Package Overview

2.1 - Server Behaviour
2.2 - VMS Versions
2.3 - TCP/IP Packages
2.4 - International Features
[next] [previous] [contents] [full-page]

The most fundamental component of the WASD VMS Web Services environment is the HTTP server (HyperText Transport Protocol Daemon, or HTTPd). WASD has a single-process, multi-threaded, asynchronous I/O design.

The following bullet-points summarise the features and facilities, many of which are described in significant detail in following chapters.

General

Scripting

Access Control

Administration

2.1 - Server Behaviour

The technical aspects of server design and behaviour are described in WASD_ROOT:[SRC.HTTPD]READMORE.TXT

2.2 - VMS Versions

The WASD server is supported on any VMS version from V6.0 upwards, on Alpha, Itanium and VAX architectures. The current version (as of late 2009), V8.3 Alpha and Itanium, as is commonly the case on VMS platforms, required nothing more than relinking. Obviously no guarantees can be made for yet-to-be-released versions but at a worst-case these should only require the same.

Non-server account scripting requires a minimum VMS V6.2, to provide the $PERSONA services required for this functionality. Equivalent functionality on earlier versions of VAX VMS (i.e. 6.0 and 6.1) is available using the PERSONA_MACRO build option (see "WASD VMS Web Services - Install and Config"; 2.12 - VMS 6.0 and 6.1 ).

The WASD distribution and package organisation fully supports mixed-architecture clusters (Alpha, Itanium and/or VAX in the one cluster) as one integrated installation.

2.3 - TCP/IP Packages

The WASD server uses the Compaq TCP/IP Services (UCX) BG $QIO interface. The following packages support this interface and may be used.

To deploy IPv6 services this package must support IPv6.

2.4 - International Features

WASD provides a number of features that assist in the support of non-English and multi-language sites. These "international" features only apply to the server, not necessarily to any scripts!


[next] [previous] [contents] [full-page] orization is performed on both script and path components. First script access is checked for any authorization, then the path component is independently authorized. Either may result in an authorization challenge/failure. This behaviour can be disabled using a path SETting rule, see 14.4.5 - SET Rule.

The authentication source name is refered to as the realm, and refers to a collection of usernames and passwords. It can be the system's SYSUAF database.

The authorization source is refered to as the group, and refers to a collection of usernames and associated permissions.


16.1 - Rule Interpretation

The configuration file rules are scanned from first towards last, until a matching rule is encountered. Generally a rule has a trailing wildcard to indicate that all sub-paths are subject to the same authorization requirements.


String Matching

Rule matching is string pattern matching, comparing the request specified path, and optionally other components of the request when using configuration conditionals (9 - Conditional Configuration), to a series of patterns, until one of the patterns matches, at which stage the authorization characteristics are applied to the request and authentication processing is undertaken. If a ma