# WASD Features and Facilities

# 2.Package Overview

2.1 Server Behaviour
2.2 VMS Versions
2.3 TCP/IP Packages
2.4 International Features

↩︎ | ↖︎ | ↑︎ | ↘︎ | ↪︎

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

- concurrent, multi-threaded client support
- HTTP/2 compliant (RFC 7540, RFC 7541)
- HTTP/1.1 compliant (RFC 2616, RFC 7230 and family)
- HTTP/1.0 compliant (RFC 1954)
- WebDAV 1,2 support (RFC 4918)
- Cross-Origin Resource Sharing (CORS)
- virtual services (servers)
- IPv4 and IPv6 support (requires underlying TCP/IP support)
- requests above a configurable limit can be queued ("throttling")
- enhanced privacy using Transport Layer Security technology (TLS), aka. Secure Sockets Layer (SSL) including

  - OpenSSL Toolkit
  - WASD OpenSSL
  - VSI SSL product
- serves ODS-2 and ODS-5 (EFS) volumes, as well as file names encoded using schemas

  - PATHWORKS 4/5
  - Advanced Server (PATHWORKS 6) and
  - SRI (MultiNet NFS, etc.)
- versatile directory listing (generic and VMS-style)
- Server-Side Includes (SSI HTML pre-processing)
- configurable cache, with time-based and forced revalidation (reload)
- byte-range support with 206 partial responses (useful for PDF and restarting file download by modern browsers)
- proxy serving, with local file-system caching, plus the CONNECT method (also allowing a number of esoteric SSL tunnelling configurations), along with FTP proxy
- gatewaying between Web protocols (HTTP-to-SSL, SSL-to-HTTP, HTTP-to-FTP)
- gatewaying between IP protocols (IPv4-to-IPv6, IPv6-to-IPv4)

##### Scripting

- CGI 1.1 compliant scripting (RFC 3875)
- non-server and user account scripting
- "CGIplus" scripting (offering reduced latency, increased throughput and reduced system impact)
- "Persistent" scripting, Run-Time Environments (RTEs) that provide for simple persistent scripting
- WebSocket scripting environment; a capability introduced with HTML5, providing an asynchronous, bidirectional, full-duplex connection.
- "RawSocket" scripting environment; providing an protocol-agnostic asynchronous, bidirectional, full-duplex connection.
- "ISAPI" extensions/scripting (also offering reduced latency, increased throughput and reduced system impact)
- DECnet-based CGI scripting (with connection reuse)
- OSU (DECthreads server) scripting emulation, with connection reuse (as per OSU 3.3a), allowing many OSU scripts to be employed unmodified
- script processor (e.g. PERL, PHP, Python) configurable on file type (suffix)
- configurable, automatic, MIME content-type initiated scripting ("presentation" scripting)

##### Access Control

- host-level, on per-host or per-domain
- "Basic" and "Digest" user authentication and path/group-based authorization
- WASD-specific user databases
- SYSUAF-authentication and VMS user security profile based file access control
- ACME service authentication (on applicable platforms)
- X.509 client certificate authentication (for SSL transactions)
- RFC 1413 (ident daemon) "authentication"
- Example LDAP authenticators

##### Administration

- multiple instances (server processes) executing on the one system allow continuous availability via rolling restarts and "fail-through" processing
- "one-button" control of multiple instances on both single systems and across clusters
- online server configuration, including reports on requests, loaded configuration, mapping rules, authorization information and graphical activity displays
- online, live server processing event report (WATCH)
- Web-standard, "common" and "combined" access log formats (allowing processing by most log-analysis tools), along with a user-definition capability allowing custom log formats
- logging periods, where log files automatically change on a daily, weekly or monthly basis (keeps log files ordered and at a managable size)
- customizable message database (capable of supporting non-English and concurrent, multiple languages)

## 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 V7.0 upwards, on Alpha, Itanium and x86-64 architectures. The current version (as of 2025), V8.4 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.

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

## 2.3 TCP/IP Packages

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

- VSI TCP/IP Services for OpenVMS (VMS Software Inc.)
- TCP/IP Services for OpenVMS (Hewlett Packard whatever) **
- Digital TCP/IP Services for OpenVMS (aka UCX) ***
- MultiNet for OpenVMS (Process Software Corporation) **

  ** any not unreasonably ancient version
  *** this might be becoming a bit of a stretch

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!

- Language Variants

  A directory may contain language-specific variants of a basic document. When requesting the basic document name these variants are automatically and transparently provided as the response if one matches preferences expresses in the request's "Accept-Language:" request header field. Both text and non-text documents (e.g. images) may be provided using this mechanism.

  Configuration information is provided in section Language Variants of WASD Configuration.

- Character Sets

  Generally the default character set for documents on the Web is ISO-8859-1 (Latin-1). The server allows the specification of any character set as a default for text document responses (plain and HTML). In addition, text document file types may be modified or additional ones specified that have a different character set associated with that type. Furthermore, specific character sets may be associated with mapping paths. A site can therefore relatively easily support multiple character set document resources.

  In addition the server may be configured to dynamically convert one character set to another during request processing. This is supported using the VMS standard NCS character set conversion library.

  For further information see [CharsetDefault], [CharsetConvert] and [AddType] in Alphabetic Listing of WASD Configuration.

- Server Messages

  The server uses an administrator-customizable database of messages that can contain multiple language instances of some or all messages, using the Latin-1 character set (ISO8859-1). Although the base English messages can be completely changed and/or translated to provide any message text required or desired, a more convenient approach is to supplement this base set with a language-specific one.

  One language is designated the prefered language. This would most commonly be the language appropriate to the geographical location and/or clientele of the server. Another language is designated the base language. This must have a complete set of messages and is a fall-back for any messages not configured for the additional language. Of course this base language would most commonly be the original English version.

  More than just two languages can be supported. If the browser has prefered languages set the server will attempt to match a message with a language in this preference list. If not, then the server-prefered and then the base language message would be issued, in that order. In this way it would be possible to simultaneously provide for English, French, German and Swedish audiences, just for example.

  For message configuration information see Message Configuration of WASD Configuration.

- Server Dates

  Dates appearing in server-generated, non-administrative content (e.g. directory listings, not META-tags, which use Web-standard time formats) will use the natural language specified by any SYS$LANGUAGE environment in use on the system or specifically created for the server.

- Virtual Services

  Virtual-server-associated mapping, authorization and character-sets allow for easy multiple language and environment sites. Further per-request tailoring may be deployed using conditional rule mapping described below. Single server can support multi-homed (host name) and multiple port services.

  For virtual services information see Configuration Considerations of WASD Configuration.

- Conditional Rule Mapping

  Mapping rules map requested URL paths to physical or other paths (see Request Processing Configuration of WASD Configuration). Conditional rules are only applied if the request matches criteria such as prefered language, host address (hence geographical location to a certain extent), etc. This allows requests for generic documents (e.g. home pages) to be mapped to language versions appropriate to the above criteria.

  For conditional mapping information see Conditional Configuration of WASD Configuration.

↩︎ | ↖︎ | ↑︎ | ↘︎ | ↪︎