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:
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:
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, attached to standard input/output streams, provides a versatile,
extensible, powerful scripting environment. Any DCL procedure or image
executing within the subprocess can behave 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.
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
http://www.madgoat.com/netlib.html
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 HTTPd 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!
Aspects
The international features only apply to the server, not to scripts!
The server uses an administrator-customizable database of messages that can contain multiple language instances of some or all messages. 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 7 - Message Configuration.
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.
Mapping rules map requested URL paths to physical or other paths (see 8 - Mapping Rules). 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 example, requests originating with a language preference of "en, fr" from ".au" can receive an English version, whilst requests prefering "de, se, en" from ".de" and ".se" receive German and Swedish versions respectively.
For conditional mapping information see 8.5 - Conditional Mapping.