Converting from CERN to OSU Web Server

Apart from some differences in system configuration, the OSU VMS DECthreads HTTPD Server behaves in a similar way to the VMS version of the CERN HTTPD Server, though the OSU server has some addition features (eg. server-side HTML pre-processor) and is much faster.

There are however a few differences that users will see, the most important being that CGI scripts will need some changes.

CGI Script Changes

For simple CGI command procedures, the following changes are required.

  1. By default records must be explicitly terminated (eg. with a <CR><LF>, or f$fao("!/")). Alternatively, record mode can be enabled with
    $ write net_link "<DNETRECMODE>"
    This must come before the CGI_SYMBOLS/Set_DCL_Env.
  2. Instead of the WWW_OUT logical name, the output stream is accessed via the NET_LINK logical. The CERN Server also reassigned SYS$OUTPUT to this, which the OSU Server does not do.
  3. The CGI_SYMBOLS or Set_DCL_Env command must be given to complete the CGI protocol and fill symbols (unless this is done by hand).
    CGI_SYMBOLS
    defines a different (but more convenient) method for passing POSTed form values. CGI_SYMBOLS is a foreign command defined for the script by WWWEXEC.COM, which assumes that it is installed in the same directory.
    Set_DCL_Env
    defines symbols for POSTed FORM values similar to the CERN Server (especially if the WWW_APPEND_EQUAL_SIGN environment variable (string symbol or logical name) is defined). Set_DCL_Env is part of the VMSindex package. It should be executed using
    RUN WWW_ROOT:[BIN]Set_DCL_Env
    (assuming that is where the executable was stored).
  4. CGI_SYMBOLS and Set_DCL_Env create local symbols, while the CERN HTTPD Server provided global symbols. This shouldn't make much difference.

Converting Scripts

A quick way to modify a command procedure to take into account points 1-3 is to add the following at the start of the procedure:-

$ if f$type(CGI_SYMBOLS).nes.""       ! OSU HTTPD server?
$ then
$     write net_link "<DNETRECMODE>"  ! Set implied carriage control
$     CGI_SYMBOLS WWW_ FORM_          ! prefix=WWW_ form_prefix=FORM_
$     define/nolog www_out net_link   ! Make it look like the CERN server
$     define/nolog sys$output www_out ! Make it look like the CERN server
$ endif
or, if forms are used and the procedure won't be converted to use CGI_SYMBOLS's method of value passing:-
$ if f$type(CGI_SYMBOLS).nes.""       ! OSU HTTPD server?
$ then
$     write net_link "<DNETRECMODE>"  ! Set implied carriage control
$     WWW_APPEND_EQUAL_SIGN:= true    ! Make Set_DCL_Env more CERN-like
$     RUN WWW_ROOT:[BIN]Set_DCL_Env   ! Set WWW_* symbols
$     define/nolog www_out net_link   ! Make it look like the CERN server
$     define/nolog sys$output www_out ! Make it look like the CERN server
$ endif

Either of these headers should allow a simple procedure to work with both the CERN and OSU HTTPD servers. I did experiment with getting WWWEXEC.COM to automatically perform this setup. This worked, but I decided in the end that it would be more transparent to modify the script code.

Further documentation and examples are provided with the OSU server.

CGI Symbols for Forms

In order to see the symbols that are set in each case, here is a form, linked to each of four possible script/server combinations. After filling out the form, the resulting DCL symbols are shown by the script.

CERN Server (2.16-1beta/VAX)
form -> example output (NB. a bug in this server often sets an incorrect final WWW_KEY_*).
CERN Server (3.0pre6vms3/Alpha)
form -> example output
OSU Server (2.0a/Alpha) with script using CGI_SYMBOLS
form -> example output
OSU Server (2.0a/Alpha) with script using Set_DCL_Env
form -> example output
OSU Server (2.0a/Alpha) with script using script_info
form -> example output
In the example output, the same options were specified in each case. The output was reordered slightly for clarity.

Other Differences

Here are a few other differences I've noticed, along with some unanswered questions. The OSU server has many advantages, and these are all minor disadvantages. As described below, in most cases 1 and 3 can be fixed in the server configuration, and 2 (being, as far as I'm aware, undocumented) should not be exploited in any case (I only noticed it because of an incorrect URL).
  1. The OSU Server, by default, sends text in STREAM (records separated by <CR><LF>) rather than the LF_STREAM (just <LF> used) format used by the CERN Server (and other Unix servers).

    This completely screws up the W3C Line Mode Browser, which, while using <LF> as a record separator, interprets the <CR> literally, causing (with most terminals) one line to overwrite the previous one. Thus, for example, Arne Vajhøj's VMS home-page was rendered as

                    WWW INFORMATION ABOUT THE VMS OPERATING SYSTEM
     versioncal][1]
    Introduction:
     VMS isocument contains information about VMS. The official name of
     supports twoOpenVMS. VMS is a product of DIGITAL. VMS currently
     as VMS VAX platforms: VAX and Alpha, and the variants are known
       and VMS Alpha (or OpenVMS VAX and OpenVMS Alpha).
    [...]
    
    and that's not Danish! I've seen this with Line Mode Browser versions 2.12/VMS (WWW Library 2.15) and the latest Unix version, 3.0 (WWW Library 3.0). Is this a bug in the Line Mode Browser or a loophole in the HTTP spec (from the WWW Consortium!)?

    Since we still use the Line Mode browser occasionally (on various different machines), I wanted to fix this in the server. I discovered that the OSU server can be made to use LF_STREAM mode by specifying HTTP_CRLF_NEWLINE=1 (rather than 0) in [.SYSTEM]HTTP_SERVER.COM. Unfortunately this does not seem to affect script output, even when the server is given control of carriage-control with <DNETRECMODE>. Is there any way to fix this?

  2. The CERN server seems to provide some form of filetype defaulting. I couldn't find any documentation for this, but if the URL is specified without a filetype (eg. /Doc1), this is replaced with /Doc1.html (it seems to try various possible filetypes). In fact version 2.16-1beta seems to only do this for certain files (eg. in the root directory), while 3.0pre6vms3 does it for all files. Can this behaviour be easily reproduced in the OSU Server?
  3. The CERN Server allows definitions such as
    AddEncoding _Z x-compress
    which indicates that all files *.*_Z (eg. doc.ps_Z) should be flagged as being compressed so that the client can decompress them automatically. Unfortunately, *.*-GZ (ie. with a dash ("-") as delimiter) doesn't work, so gzipped (x-gzip encoding) files have to use non-standard naming.

    None of this seems possible with the OSU Server, though individual filetypes can be specified as compressed, eg.

    suffix .ps_z application/postscript BINARY/x-compress 1.0
    which allows the common types to be specified explicitly. Is there any way of specifying this for all filetypes (preferably also allowing *.*-GZ)?


Navigation links: [Home] [WWW Information]
HTML 3.2 Checked... Best viewed with ANY browser! http://hepwww.rl.ac.uk/Delphi/Adye/wwwdoc/CERN2OSU.html first created 26th November 1996 by
Tim Adye, <T.J.Adye@rl.ac.uk>