[0001] [0002] [0003] [0004] [0005] [0006] [0007] [0008] [0009] [0010] [0011] [0012] [0013] [0014] [0015] [0016] [0017] [0018] [0019] [0020] [0021] [0022] [0023] [0024] [0025] [0026] [0027] [0028] [0029] [0030] [0031] [0032] [0033] [0034] [0035] [0036] [0037] [0038] [0039] [0040] [0041] [0042] [0043] [0044] [0045] [0046] [0047] [0048] [0049] [0050] [0051] [0052] [0053] [0054] [0055] [0056] [0057] [0058] [0059] [0060] [0061] [0062] [0063] [0064] [0065] [0066] [0067] [0068] [0069] [0070] [0071] [0072] [0073] [0074] [0075] [0076] [0077] [0078] [0079] [0080] [0081] [0082] [0083] [0084] [0085] [0086] [0087] [0088] [0089] [0090] [0091] [0092] [0093] [0094] [0095] [0096] [0097] [0098] [0099] [0100] [0101] [0102] [0103] [0104] [0105] [0106] [0107] [0108] [0109] [0110] [0111] [0112] [0113] [0114] [0115] [0116] [0117] [0118] [0119] [0120] [0121] [0122] [0123] [0124] [0125] [0126] [0127] [0128] [0129] [0130] [0131] [0132] [0133] [0134] [0135] [0136] [0137] [0138] [0139] [0140] [0141] [0142] [0143] [0144] [0145] [0146] [0147] [0148] [0149] [0150] [0151] [0152] [0153] [0154] [0155] [0156] [0157]
|1Introduction| |^ With the installation, update and detailed configuration of the WASD Web Services package provided in |link%|../config/|WASD Web Services - Install and Config| why have an introduction in this subsequent document? After getting the basics up and running (often the first thing we want to do) it's time to stop and consider the tool and what we're trying to accomplish with it. So this section provides an overview of the package's design philosophy, history and significant features and capabilities by topic. |^ The document |*assumes| a basic understanding of Web technologies and uses terms without explaining them (e.g. HTTP, HTML, URL, CGI, SSI, etc.) The reader is refered to documents specifically on these topics. |0Objectives| |^ WASD Web Services originated from a 1993 decision by Wide Area Surveillance Division (WASD) management (then High Frequency Radar Division, HFRD) to make as much information as possible, both administrative and research, available online to a burgeoning personal desktop workstation and PC environment (to use the current term |...| an |/intranet||) using the then emerging Web technologies. |^ It then became the objective of this author to make |/all| of our systems' VMS-related resources available via HTTP and HTML, regardless of the underlying data or storage format. An examination of the WASD package will show that this objective is substantially achieved. |0Reasons For Yet Another Web Package| |^ Reasons for developing (remember; back in 1994!) a local HTTP server were few but compelling: |bullet| |item| It was prefered to support this environment on a VMS platform; at the time the most widely used and accessible environment within WASD. |item| At that time servers (and even then there were quite a few variations) were largely Unix based, although it was being supported (to a greater or lesses extent) across a wide range of platforms. Ports to VMS, if they existed, were often in-progress or half-baked, employing |/Unix||isms that don't translate elegantly to the VMS environment. |item| The VMS version of the CERN server (3.0-6) was evaluated during mid-1994: |bullet| |item| It was (still is) not multi-threaded under VMS (i.e. cannot support concurrent clients). For example, a lengthy search may delay other clients for unacceptable periods. |item| The performance was good with document transfers, but became poor when running a |/script||. |item| It is acknowleged in the release notes that it cannot handle a client cancelling a data transfer (a not-uncommon action). This was confirmed experimentally. |!bullet| |item| An early version of the OSU server was evaluated via documentation mid-1994. The author considered that the DECthreads of the time to have limitations (including frequent, show-stopping bugs) and OSU had a number of implementation idiosyncracies (e.g. DECnet based scripting). |item| HTTP, in the then standard implementation (HTTP/1.0, RFC1945), was relatively simple to implement to the level required to support intra-Divisional requirements. |item| Since that time |...| |bullet| |item| |*As of December 1995| the server has worked extremely well and has a number of facilities tailored for the VMS environment. It can continue to be utilized until there are overwhelming reasons for implementing something else. |item| |*June 1997| the server and associated software continues to evolve and provide a stable and effective VMS Web environment, even with the advent of a small number of commercial VMS Web products. |item| |*October 1999| the package is beginning to mature as an HTTP/1.0 solution, providing not only a fast and stable server but an increasingly extensive collection of applications and tools. |item| |*July 2002| it continues to be refined and extended. A greater emphasis on "commercial" functionality has occured over the past couple of years. |item| |*December 2004| it now complies with the HTTP/1.1 specification (RFC2616) and provides a very respectable range of functionality and the fastest and most efficient serving environment for VMS. |item| |*A decade on (2014)| it continues to be adopted by sites wanting fast, efficient, capable and often philosophically VMS infrastructure. WASD continues to be enhanced and bug-fixed |_two decades| after its initial, tentative steps into the World-Wide information Web. |item| |*May 2016| brings HTTP/2 (RFC 7540, RFC 7541) to WASD. A replacement for how HTTP is expressed "on the wire", it is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same. The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. |item| |*June 2019| occasions WASD's twenty-fifth anniversary! |^- |*For a quarter-century and more |-| the only web environment implemented expressly for VMS||. |item| |*Late 2021| ta-da! WASD on x86-64 |!bullet| |!bullet| |2Troubleshooting?| |^ When initially installing or configuring WASD, and sometimes later where something breaks spectacularly, it is most useful to be able to gain insight into what the server is up to. |^ The |/go-to| tool is\ |"<span style=\"font-size:110%\">WATCH</span>||\ (yes, all capitals, and for no other reason than it makes it stand out). |^ WATCH is described in detail in |link|WATCH Facility| of this document. |^ For most circumstances WATCH can be made available for troubleshooting even if the configuration is significantly broken. This is done by using a skeleton-key to authorise special access into the server. |^ The skeleton-key is described in detail in |link|Skeleton-Key Authentication||, also in this document. |^ |*TL;DR| |^ Enable at the command-line with the username anything beginning with an underscore and at least 8 characters, same for the password length. |code| $ HTTPD /DO=AUTH=SKELKEY=_|/username||:|/password|| |!code| |^ Then using a browser access any available service, entering the above username (including underscore) and password when prompted. |block| |link%|/httpd/-/admin/report/WATCH|https://\<i\>the.host.name:port\</i\>\ /httpd/-/admin/report/WATCH| |!block| |^ The service administration facilities (of which WATCH is one) are also available and useful. |block| |link%|/httpd/-/admin/|https://\<i\>the.host.name:port\</i\>\ /httpd/-/admin/| |!block|