Site powered by WASD and VMS   Updating?  Beware!
When updating from previously installed versions this document points out obvious "gotchas" or other known implications. Of course it is often difficult to anticipate all potential interactions with localized installations.

The procedure [INSTALL]UPDATE_CLEANUP.COM attempts to clean up any files known to exist in previous versions and that are no longer required.  Execute it after an update.

Be sure to read about significant changes (although this is not exhaustive), the revised Install and Config, and to a lesser extent the Features and Facilities documents.  Specific server bug-fixes are described in the code modules.

Version 12.1 to 12.2

  • Existing users of [Accept] and [Reject] global directives should carefully evaluate the significant v12.2 changes.
  • WASD v12.2 changes global section data structures. Statistical data will be zeroed at first startup.

Version 12.0 to 12.1

  • The pre-v10.0.0 logical names (e.g. HT_ROOT, HTTPD$MAP) are now obsolete.

Version 11.5 to 12.0

Well, where do we start?
  • VAX has gone.
  • Most extensive modifications in several major versions supporting native 64 bit data storage.
    There may be obscure gremlins laying in wait.
  • It is becoming more fraught upgrading from v10.n to 12.0, and downright perilous from pre-v10.n.
    From v10.n a fresh installation is strongly recommended.
  • Reinterating Significant Changes document, the pre-v10.0.0 logical names (e.g. HT_ROOT, HTTPD$MAP) are now deprecated and will be obsoleted in a future version. The server process log issues warnings such as  %HTTPD-W-DEPRECATED, change HTTPD$MAP to WASD_CONFIG_MAP (soon!)  for any it finds during startup.

Version 11.4 to 11.5

  • Before UNZIPing the v11.5 package when updating an existing v9.3 or earlier installation ...
    ... see all of the requirements of the v9.3 to v10.0 update listed below.
  • WASD v11.5 and later uses a 64 bit Expat library unsuitable for VAX. After UNZIP of the main package and before build/update the Expat directory requires replacement with an earlier 32 bit package. Details in the Installation documentation.
  • With OpenSSL EOLing v1.0.n at the end of 2019 object modules for OpenSSL v1.0.n are no longer provided.
  • VAX object modules for OpenSSL are no longer provided.

Version 11.3 to 11.4

  • none

Version 11.2 to 11.3

  • WASD v11.3 changes global section data structures. Statistical data will be zeroed at first startup.

Version 11.1 to 11.2

  • Due to changes in the locking schema, all clustered instances of WASD need to be operating with v11.2.0 or later. Mixed version behaviour is undefined.
  • WASD v11.2 changes global section data structures. Statistical data will be zeroed at first startup.

Version 11.0 to 11.1

  • Requires a minimum of OpenSSL v1.0.0. No longer supports HP SSL (based on OpenSSL 0.9.8n); requires HP SSL1.
  • TLS/SSL default configuration (cipher list and options) maximises security and is compatible with most modern agents. Ciphers require "Forward Secrecy" and presence of [LOCAL]DH_PARAM_nnnn.PEM safe prime files. To support legacy environments the configuration must be downgraded.
  • WASD v11.1 changes global section data structures. Statistical data will be zeroed at first startup.

Version 10.n to 11.0

  • HTTP/2 uses SNI and ALPN TLS extensions of OpenSSL 1.0.2 or later.
  • HTTP/2 has the potential to load many more requests per network connection than HTTP/1.n.
  • The default HTTP/2 frame size is 16384 octets and this becomes the default network read buffer and scripting HTTP$INPUT mailbox size.
  • Before enabling HTTP/2 check related documentation carefully.
  • WASD v11.0 changes global section data structures. Statistical data will be zeroed at first startup.
  • Ancient and no longer relevant functionality represented by the FILEDOT.C, ISMAP.C, MENU.C and TRACK.C server modules has been removed along with the code.
  • At the risk of counter-productive repetition;  this release (undoubtedly) introduced a number of server bugs along with the significant code refactoring required. Seriously! This should be considered a classic point-zero release and carefully evaluated for production environments.

Version 10.3 to 10.4

  • Secure Sockets Layer now supports the TLS protocols by default. The deprecated SSLv3 and obsolete SSLv2 can be reenabled using a command-line parameter if required. Some older clients employing SSL(v3) may fail. Symptoms are dropped connection establishment and WATCH [x]SSL showing "SSL routines SSL3_GET_RECORD wrong version number", "SSL routines SSLn_GET_CLIENT_HELLO unknown protocol", possibly others.
  • WebDAV metadata for directories has been moved from the parent directory (containing the name.DIR file) to the directory itself. This presents a small risk of lost directory metadata or locks. A directory search for *.DIR__wasdav; files would indicate whether this is a potential issue.
  • WASD v10.4 changes global section data structures. Statistical data will be zeroed at first startup.

Version 10.2 to 10.3

Nothing significant.

Version 10.1 to 10.2

  • Secure Sockets Layer now supports SSLv3 and TLSv1 by default. The deprecated and vulnerable SSLv2 can be reenabled using a command-line parameter if required. Some older clients employing SSL(v2) may fail. Symptoms are dropped connection establishment and WATCH [x]SSL showing "SSL routines SSL3_GET_RECORD wrong version number".

Version 10.0 to 10.1

  • WASD now requires a minimum of VMS V7.0 to to build and execute.
  • WASD v10.1 changed global section data structures and their names (basically it catches up from v8.0). There is the potential to orphan a couple of global sections and several hundred global pages. The recommended sequence before update: 
      $ HTTPD/DO=EXIT=NOW
  $ HTTPD/GBLSEC=DELETE

Version 9.3 to 10.0

  • Before UNZIPing the v10 package and when updating an existing v9.3 or earlier installation the current root directory must be renamed from HT_ROOT.DIR to WASD_ROOT.DIR. The v10 package uses [WASD_ROOT] as its top-level directory in line with the other naming schema changes employing "WASD". Remember to modify local startup procedures in-line with this new top-level directory name. Also note that the v10 package is not suitable for updating from an existing v8.0 or earlier installation.
  • WASD_CONFIG_MAP (HTTPD$MAP) must be modified to map /wasd_root/ instead of, or additional to, /ht_root/.
  • @WASD_FILE_DEV needs to be executed for every process requiring access to WASD-specific logical names (see below).
  • WASD v10.0 changes global section data structures. Statistical and activity data will be zeroed at first startup.
  • The logical naming schema has changed significantly and any local customisation may need to be updated.
  • To use the private WASD logical name table all processes needing to access non-SYSTEM defined WASD logical names (e.g. the HT_EXE: used to activate the server image at the command-line) are required to perform an @WASD_FILE_DEV first.
  • Server and scripting process names now begin "WASD". This will automatically create a new set of scripting process rights identifiers.
  • WASD v9.3 enforced ACME for SYSUAF authentication on Alpha and Itanic, VMS V7.3 and later. This inadvertantly disabled WASD_NIL_ACCESS. This has been restored but requires the server image to be INSTALLed with SECURITY privilege (a $ACM requirement). v10 standard startup procedures do this but customised local startup might need to be updated.
  • When using proxy serving the default fail rule is now enforced (as with general rule mapping) and so explicit PASS rule(s) are required. From my test-bench: 
    pass http://* http://* report=detailed
pass ftp://* ftp://* report=detailed response=gzip=all
pass /*/-/* /wasd_root/runtime/*/*
if (request-method:CONNECT) pass *
pass * "403 Uh-ah"

Version 9.2 to 9.3

  • WASD v9.3 changes the primary global section data structure. Statistical data will be zeroed upon starting v9.3.

Version 9.1 to 9.2

  • WASD v9.2 changes the primary global section data structure. Statistical and activity data will be zeroed upon starting v9.2.
  • The cleanup procedure deletes any existing PostScript documents previously supplied in the [DOC.HTD], [DOC.ENV], [DOC.SCRIPTING] and [DOC.SDM2HTM] directories.

Version 9.0 to 9.1

  • Nothing significant. If moving from v8.1..v8.5 directly to v9.1 then check the "8.5 to 9.0" notes below.
  • Some new command-line /DO= commands require the 64 byte lock value block provided by VMS V8.2. If this is available, or not available anywhere in a mixed version/architecture cluster, there are some restrictions (basically the new v9.1 functionality is not available).
  • WASD v9.1 changes the primary global section data structure. Statistical data will be zeroed upon starting v9.1.

Version 8.5 to 9.0

  • CGILIB support for the "#include <cgilib.c>" has been obsoleted. Source code using the approach must be modified to build against the CGILIB object library. See the CGILIB.C descriptive prologue or any one of a number of WASD build procedures for detail on how to accomplish this.
  • Proxy caching has changed file handling. Cache files from prior to v9.0 (actually tagged as v6.0) cannot be used by v9.0 and later. When encountered they are automatically deleted and the content reloaded. This means proxy cache responsiveness will be very low to start with and increasingly improve as it becomes populated with v9.0 format files.
  • The v9.0 HTTPd will not use the v8.0 message file. Sections that have been modified; [auth] message 14 added; [general] has two new messages 14 and 15; [http] has had a number of revisions and additions; [proxy] message 21 added; [upd] has had 18 added and the rest shuffled up. Please update localized files with reference to HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF.
  • WASD v9.0 changes the accounting structure. Statistical data will be zeroed upon starting v9.0.

Version 8.4 to 8.5

  • Nothing significant. If moving to 8.5 directly from 8.0 or earlier, those noted in "8.0 to 8.1" below.
    I'll quit this warning as soon as WASD hits version 9!
  • WASD v8.5 changes the accounting structure and lock resource names. Make doubly sure any existing version is shut down before beginning the update. Statistical data will be zeroed upon starting v8.5.

Version 8.3 to 8.4

  • Again, nothing really significant. If moving to 8.4 directly from 8.0 or earlier, those noted in "8.0 to 8.1" below.
  • The IA64 support is somewhat tentative running as it does on the pre-production HP OpenVMS Industry Standard 64 Evaluation Release Version 8.1.

Version 8.2 to 8.3

  • Nothing really significant again. If moving to 8.3 directly from 8.0 or earlier, those noted in "8.0 to 8.1" below.

Version 8.1 to 8.2

  • Nothing obvious, except if moving to 8.2 directly from 8.0 or earlier, those noted in "8.0 to 8.1" below.

Version 8.0 to 8.1

  • Versions prior to 8.1 have been shown to have some security issues with directory tree structure and permissions, and a too-liberal default ([EXAMPLE]) configuration. Problematic server functionality has also been addressed. Whether updating or installing from scratch, please (re)read the [doc.misc]wasd_advisory_020925.txt and the revised Technical Overview section 6.1 Securing The Site.
  • For scripting using DECnet you may need to add a proxy entry to allow for HTTP$SERVER access to the new HTTP$NOBODY account. Just reproduce whatever you have provided for the HTTP$SERVER account. For example 
      $ SET DEFAULT SYS$SYSTEM
  $ MCR AUTHORIZE
  UAF> ADD /PROXY 0::HTTP$SERVER HTTP$NOBODY /DEFAULT
  • The qdLogStats utility CGI interface may now require to be installed with READALL privilege. Some layout changes and additional functionality.
  • Remember that when installing or modifying scripts they need to be copied into [CGI-BIN] and [AXP-BIN or [VAX-BIN] (convenience logical CGI_EXE:) to make them accessable to the server.

Version 7.2 to 8.0

  • The configuration of multiple instances on a single node will require an additional global section for the shared authentication cache and another additional global section for the shared session cache if the Secure Sockets Layer (SSL) image is used, plus an variable number of additional global pages depending on the configured size of each of these. One more (making a total of three or four) is used to store the activity statistics. This also now requires 816 global pages.
  • On sites that use authentication extensively the size of the shared authentication cache may require explicit adjustment via the [AuthCacheEntiresMax] configuration directive.
  • Sites that use the /PROFILE functionality and have accounts with a large number of rights identifiers may need to increase [AuthCacheEntrySize].
  • The service directives [ServiceSSLclientVerify] and [ServiceSSLclientVerifyCAfile] have been changed to [ServiceSSLverifyPeer] and [ServiceSSLverifyPeerCAfile] respectively (previous versions continue to be available for backward compatibility). This was done to try and avoid confusion with the [ServiceSSLclient..] directives that provide configuration for outgoing SSL connections.
  • The v8.0 HTTPd will not use the v7.0 message file. Sections that have been modified; [htadmin] message 09 has an additional component; [proxy] has three new messages 17, 18 and 19; [put] has message 01 added and all the rest shuffled up by one number (sorry, wasn't thinking :^)  Please update localized files with reference to HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF.

Version 7.1 to 7.2

  • "Monitor" data and "control" directives (/DO=) now communicate via shared memory in a global section. This is significantly more efficient and versatile. Server images must now be installed with PRMGBL, SHMEM (VAX only) and SHRGBL. Failure to provide these privileges will make it impossible to use HTTPDMON and provide CLI control directives.
  • For the reason described immediately above WASD now consumes one global section as well as 16 global page(let)s on Alpha and 4 global pages on VAX, per server process.

Version 7.0 to 7.1

  • Changes to the CGI environment can make scripting buffer space marginal. Scripts may report "Mailbox is full ... SYS$COMMAND" or "Mailbox is full ... CGIPLUSIN". Increase [BufferSizeDclCommand] and [BufferSizeDclCgiPlusIn] appropriately.
  • 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. Versions 4.4-7.0 provided a [DclFullRequest] configuration directive which allowed backward compatibility behaviour. This has been removed. Backward compatibility may still be enabled by defining the system-wide logical HTTPD_DCL_FULL_REQUEST. The obsolete [DclFullRequest] directive may be removed from configuration files.

Version 6.n to 7.0

  • .HTA and .HTL authentication databases require renaming to .$HTA and .$HTL. This has become necessary as Microsoft begin to use the file type .HTA for one of it's client-based processing technologies and the WASD server flatly refuses to serve files with an .HTA type (for the obvious reason that you don't want to be exporting your authentication database to any one requesting it!)
  • The v7.0 HTTPd will not use the v6.1 message file. The entirely new [http] section provides descriptions of common HTTP responses (and used when generating error and success response pages). The [status] section has undergone minor revision with the 6.1 messages 03 and 15 being removed, with a new 14 being the new response format and 15 a revised "additional information"
  • The server is now more careful when using BYTLM for scripting subprocesses. It may be necessary to increase the server account's quota to allow the same number of scripts to be concurrently in use.
  • Command-line control directives (i.e. HTTPD/DO=) can now report process information of the originator. To enable this facility existing installations will need to add WORLD privilege to the INSTALL ADD in STARTUP.COM.
  • Previous versions allowed a proxy service certificate to be specified following the service name using something like ";HT_ROOT:[LOCAL]MYCERT.PEM". This must now be prefixed with cert= as follows ";cert=HT_ROOT:[LOCAL]MYCERT.PEM".
  • The [LogPerService] directive now generates longer log file names.

Version 6.0 to 6.1

  • The v6.1 HTTPd will not use the v6.0 message file. Messages 10, 11, 12 and 13 have been added to the [auth] section, and the [version] of the file is now 6.1. Please update localized files with reference to HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF.
  • The authorization environment underwent some considerable revision for agent support. Please check your authorization environment carefully to ensure nothing has been overlooked.
  • The /PROFILE qualifier and associated behaviours have been bug-fixed and modified slightly. If in use please check your authorization environment carefully.
  • DCL scripting now requires greater BYTLM quota. If a site supports many concurrent DCL scripting subprocesses please review the server account's BYTLM quota and increase by approximately 25% if necessary.
  • Proxy caching now requires an HTTPD$CONFIG directive to be enabled, regardless of what is configured against an service(s). Please add "[ProxyCache] enabled" to this file if using proxy caching.
  • A new HT_ROOT:[EXAMPLE]STARTUP.COM is available reflecting the demise of NETLIB support. Sites previously using NETLIB versions of the server should check the new startup environment.

Version 5.n to 6.0

  • The v6.0 HTTPd will not use the v5.n message file. A new file has been necessary to support the proxy serving messages. One new section, "[proxy]", one additional "[status]" message (number 17), and one additional "[script]" message (number 9) are included. Please update localized files with reference to HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF.
  • When implementing proxy services it may be necessary to update "[status]" message 16 to include the local host name into each of the error code informational links.
  • Changes in support of SSL and in the example server and CA certificates may mean certificates loaded into browsers need to be deleted, and/or browsers shutdown and restarted before correct behaviour occurs. Typical is Netscape reporting I/O errors when communicating via "https:".
  • Authorization and authentication has changed significantly. This is all designed to be backwardly compatible (possibly with some HTTPd startup qualifier change, /SYSUAF=ID to /SYSUAF=WASD_ID) ... hopefully.  Please check carefully!
  • The HTTPD$CONFIG [Service] directive behaviour has changed slightly. If a fully qualified host name is provided that becomes the service name, regardless! This allows an alias to be used as the server's official name. An absent or unqualified host name adopts the host's interface name.
  • Administration menu paths have some changes. Bookmarks may have been invalidated.
  • If using the MadGoat NETLIB package it is necessary to have at least NETLIB022 installed. NETLIB021 has a problem processing socket shutdown ASTs.

Version 5.2 to 5.3

  • Variable-length to stream-LF file conversion requiring [StreamLFpaths] configuration in v5.2 is now superceded by the mapping SET rule. There is no backward compatibility.
  • The STARTUP.COM procedure has been changed to support the new STARTUP_SERVER.COM procedure. It provides backward compatibility, executing [HTTP$SERVER]HTTPD_BATCH.COM and as a result HTTPD80.COM if the v5.3 procedure(s) are not present. There are advantages in moving to the new environment.
  • The rule mapping check facility has been superceded by the WATCH facility.

Version 5.1 to 5.2

  • Variable-length to stream-LF file conversion now requires specific paths to be enabled using the [StreamLFpaths] directive. Any site using this functionality MUST provide paths.
  • Users unused to being challenged after the initial entering of authentication information may become annoyed at the requirement to reenter it after an idle period. This may be disabled by setting [AuthRevailidateUserMinutes] to zero but this is discouraged due to the additional security such a mechanism provides.

Version 5.0 to 5.1

  • The package's build support and distribution format has undergone a significant overhaul. Executables are no longer provided! All installations and updates will require a link prior to any other activity.
  • The v5.1 HTTPd will not use the v5.0 message file. [SSI] section messages 18, 19 and 20 were needed to support the new SSI functionality. Add these from the HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF example message file. Sorry for any inconvenience.
  • Some changes in the appearance of script output may be initially disconcerting. In short time however the advantages of the consistent look-and-feel and customizable colour schemes will become obvious (I hope ;^)
  • The Conan and HyperShelf scripts were extensively reworked to disengage them from dependencies on the WASD HTTPd. They should now be vanilla CGI scripts (if such a thing, other than a "hello world", exists). Hopefully this does not break any installations out there.

Version 4.n to 5.0

  • There is one changed configuration directive, [DirDescription], a boolean has been modified to be an integer, [DirDescriptionLines], the number of lines an HTML file is searched for a directory description. Backward compatibility is maintained.
  • There is a new HTTPd qualifier, /SSL=, and a new configuration logical name, HTTP$SSL_CERT to support the optional SSL functionality. If this is not in use then they are of no consequence.
  • The example startup file has been extensively modified to (hopefully) ease startup configuration and to support the optional SSL functionality. You might like to check these out in the HT_ROOT:[EXAMPLE] directory.
  • The v5.0 HTTPd will not use the v4.4 message file. Please copy the HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF to where-ever this is located for your local site. If you have customized it then you will need to carefully compare the two and migrate one into the other somehow. The [dir], [general], [ssi], and [upd] sections have changed. Sorry for any inconvenience.
  • For sites using DTSS the HTTPD$GMT logical is no longer required. WASD will calculate the GMT offset using the SYS$TIMEZONE_DIFFERENTIAL logical (and thus automatically detect changes involving daylight saving).

Version 4.4 to 4.5

  • Checking against HT_ROOT:[EXAMPLE]HTTPD$MAP.CONF, change your v4.4 HTTPD$MAP to provide revised mappings for "/echo*", "/tree*" and "/xray*"
  • Additional configuration parameters can be supplied to control cache behaviour, logging and scripting environments.
  • The caching module has only been extensively exercised during testing. WASD intranet sites are not busy sites, so the cache is essentially untried with a real-world load and data profile! Should it be suspected of giving problems disable it immediately and contact the author.
  • Message file version number 4.4 is compatible with v4.4 and v4.5 servers!
  • Muhammad Muquit's WWW Counter has been unbundled from v4.5, but is obtainable as a separate WASD-ready package.

Version 4.n to 4.4

  • Due to changes in connection request processing some NETLIB supporting TCP/IP packages can no longer provide DNS lookup (it now occurs at AST level, see the NETLIB documentation).
  • This version has a separate, configurable message database capable of supporting multiple, concurrent languages. A logical name, HTTPD$MSG, needs to be provided to locate it for the server. A default file may be copied from HT_ROOT:[EXAMPLE]HTTPD$MSG.CONF to wherever the site places configuration files.
  • The configuration directives "ErrorInfo", "ErrorSysAdmin" and "AuthVMS" have been retired, and the following introduced, "DirDescription", "DirNoPrivIgnore", "ErrorSourceInfo", "LogFormat" and "Service".
  • SYSUAF-authentication (previously "AuthVMS") is now controlled using the server qualifier /SYSUAF. The qualifiers /PROFILE and /SERVICE have been introduced.
  • Minor changes to configuration (including mapping for the echo and Xray facilities) and startup files can be checked in the HT_ROOT:[EXAMPLE] directory.

Version 3.n to 4.n

  • There are some significant changes in configuration file format and server startup (as well as functional and performance improvements for that price :^)
  • If at all possible, restoring the new version 4 tree, reviewing the new configuration and mapping files, etc., adjusting startups, and then migrating any local applications into it, might be the cleanest approach.