WASD Hypertext Services - Technical Overview

[next] [previous] [contents] [full-page]

2 - HyperText Transport Protocol Daemon - Overview

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

2.1 - Server Features

The package provides a complete implementation of a basic HTTP/1.0 server, including:

2.2 - Server Behaviour

The HTTPd executes permanently on the server host, listening for client connection requests on TCP/IP port 80 (by default). It provides concurrent services for a (technically) unlimitted number of clients (constrained only by the server resources). When a client connects the server performs the following tasks:

  1. creates a thread for this request
  2. reads and analyzes the HTTP request sent,
    depending on the nature of the request ...
  3. closes the connection to the client and disposes of the thread data structures

For I/O intensive activities like file transfer and directory listing, the AST-driven code provides an efficient, multi-threaded environment for the concurrent serving of multiple clients.

For scripts, the technique of using multi-threaded, concurrent, spawned subprocesses or network processes, attached to standard input/output streams, provides a versatile, extensible, powerful scripting environment. Any DCL procedure or image executing within the process can behave essentially as an HTTP server. This capability is employed to easily extend the basic services provided by the core daemon code. An HTTP script/server for this environment does not need to concern itself with network activities, it merely reads and writes from the standard I/O streams.

2.3 - TCP/IP Packages

The WASD server supports Digital TCP/IP Services (UCX) with a native image.

The "UCX" version is also known to work under TCPware v5.n (UCX compatibility emulation) from Process Software Corporation.

Using the excellent freeware NETLIB package from MadGoat Software (Matthew Madison), this server can also (potentially) support

NETLIB requires VAX/VMS v5.2 or later, or OpenVMS Alpha v1.5 or later.

NETLIB must be obtained and installed separately. This is not a difficult undertaking for there is a familiar VMSINSTAL-driven installation and configuration.

The WASD NETLIB support was developed using v2.1, which may be obtained from



NETLIB support within the WASD server is tested in-house using the Digital TCP/IP Services package. Other TCP/IP packages may or may not perform as tested.

2.4 - International Features

As of version 4.4 the HTTP server has undergone a limited degree of internationalization. The impetus for this development was the use of the package in some European countries where English is not the first language.

As this was not within the original critera while building the server it has meant an extensive rewrite of some functionality within the code (I hope it's appreciated ;^) The objective is to provide users of the server with a more familiar and therefore more comfortable environment. Unfortunately the server administrators are still confronted by an English-language interface and documentation, but then the package doesn't pretend to be international software!


The international features only apply to the server, not to scripts!

2.5 - HTTP Methods Usage

This section describes WASD-specific characteristics of the available HTTP/1.0 request methods.

2.5.1 - GET

Of course, the GET method is used to access documents supplied by the server. There is nothing WASD server-specific about this method.

2.5.2 - POST & PUT

The WASD HTTPd does not differentiate between POST and PUT methods, both are handled identically.

Script Handling

The "normal" usage of the POST method is to return data from a <FORM>..</FORM> construct to a script running on the server. In this regard WASD is no different to other any web server; the form data is delivered to the script's standard input as a stream of URL-encoded text. For example:


Note that WWW_CONTENT_LENGTH will be the length of the form data. See 12 - Scripting for further information.

File Creation/Upload

If the client sends data back to the server using either the POST or the PUT methods, without a script being mapped to be executed in response to that data, the WASD HTTPd will create a file corresponding to the specified path. The data stream may be text or binary.

Of course, for the server to accept POST and PUT data in this manner, authentication and authorization must be enabled and allow such access to the request path.

The data stream is processed according to MIME content-type:

Directory Creation

A directory will be created by the HTTPd if a directory path is provided with the POST or PUT methods. For example:


File Deletion

A file will be deleted by the HTTPd if the file path ending with a wildard version specification is provided with the POST or PUT methods. For example:


Directory Deletion

A directory will be deleted by the HTTPd if a directory path ending with a wildard version specification is provided with the POST or PUT methods. For example:


2.5.3 - DELETE

The DELETE method should delete the file or directory corresponding to the supplied path.

[next] [previous] [contents] [full-page]