RPM Technical Information

WARNING: OUT OF DATE INFO!

Supporting Broken Browsers

Perhaps 75% of the world uses Netscape, and perhaps we will decide that Netscape is also the best to run at the summit, so we really don't need to support any other browsers. There is still, however, a 25% chance that someone will load a demo copy of a form into Mosaic or some other browser that can't do all the fancy stuff that Netscape can. RPM makes supporting them relatively easy, since all browsers identify their name and version when they first connect. At this stage, RPM can set flags like "no_tables" or even "text_only" which the affected macros would have to look for and deal with appropriately.

Currently only two such cases will be supported:

"Dynamic" screens like status displays will only auto-update in netscape, because this is a special netscape-ism.
Tables will be turned off if the connecting client is NCSA Mosaic, since hypertext within tables causes that browser to gobble up anything inside the table!

There are probably many other small things that could be tweaked according to browsers and versions, but typically things look pretty good, and we can count on being able to choose what to run at the summit, and tweak the displays mainly for that browser. Supporting other browsers it not a major prioty.

Source Files

Look in the corresponding .hh header files for comments on how to interface to each of these modules. Names starting with a capital letter are C++ classes. Others are function calls. Modules that have `util' in their names may contain a collection of related functions

LogStream.hh
A C++ iostream object which you can use like any other stream, except whatever you put on it goes into HTML formatted text and/or calls cfht_log().

SignalCatcher.hh
A general object that rpm initializes at startup to trap most of the trap-able signals. When one is caught, it logs the occurance as a potential problem, and attempts to exit gracefully.

RpmShow.hh
Stack-like class for dealing with {IF} tags

http_*.hh
Code for supporting HTTP protocol features live here.

http_KeepAlive.hh -- Handles ``Connection: Keep-Alive'' used by the latest browsers.
http_date_util.hh -- Handles "Date:", "Last-Modified:", and "If-Modified-Since:"
http_messages.hh -- A few defines for http message response headers.

dtd_*.hh
Code for dealing with the DTD (the Hform DTD, in this case)

dtd_intro.hh -- groks just the most supeficial info about the Hform. This amounts to reading everything up to the {/Window} (is it dynamic? what are the title? width? height?) It is just designed to get the stuff needed by hform out of the file.
dtd_conditional.hh -- a class to handle {If}{/If} type tags
dtd_global.hh -- groks tags that are valid in both the Head and the Body sections (just {Include ...} at the moment.)
dtd_head.hh -- groks everything in the {Head}{/Head} section in order to

Allocate variable tables and other data
Validate client's posted values (if JavaScript didn't already do it for us)
Merge client's posted values into the data structures

dtd_body.hh -- groks everything in the {Body}{/Body} section and actually generates the HTML to send to the browser.

rpm_syntax.hh
Information on escape characters and delimiter characters used in rpm

rpm_parser.hh
the main parser loop

rpm_logger.hh
At startup, rpm forks this guy. Operation is pretty simple: It reads characters over standard input (which is hooked into the parent process's standard error) and prints them into one of two predefined (by the main process) log files, depending on whether strings are terminated with NUL+S or NUL+E (for Summary/Extended log.)

rpm_config.hh
Handles reading the rpm global configuration file (usually /etc/rpm.conf). The information in this file is read into three (string) arrays:

secure_rpm[] -- the list of users which rpm can execute stuff as
mime_type[] -- a list of MIME types by file extension
config[] -- other general configuration parameters

rpm_find_file.hh
Code for looking up files (par files, html files, rpm files, whatever.)

rpm_find_variable.hh
Code for reading data files into (string) arrays. Right now, this just includes CFHT par files, but support to read in the headers from a fits file is also planned.

rpm.cc
Contains the main code of the server. It is linked with all of the above files to create the rpm `httpserver'

hform.cc
Contains Netscape "netscape-remote" program with a few changes for Hforms. It is linked with logstream, rpm_config, rpm_find_file, and dtd_intro.

Flow of Information (HTTP)

Files

Client uses first part of URL to figure out how to reach the server (http://www.cfht.hawaii.edu:80).
Client passes the rest of the URL the server in the following format:
Client says "GET /index.html HTTP/1.0\n\n"
Then the client sends "Mime headers" of the same format used in e-mail. The headers tell things like which version browser is being used, and what type of file formats it knows about. Most servers don't really do anything useful with this whole section.
Then the server sends its "Mime headers" back to the client. In this set of headers is one called "Content-type" which the server determines from its own mapping of file extensions-to-mime types. Typically
Server says "Content-type: text/html\n"
The server opens the requested file, and blindly copies it back to the client (where all of the tags get interpreted, in the case of html.) This includes tags specifying images. The client is responsible for making a separate http connection for each of them, and inserting them where they're needed.

Scripts

Client uses first part of URL to figure out how to reach the server (http://www.cfht.hawaii.edu:80).
Client passes the rest of the URL the server in the following format:
Client says "POST /script.cgi HTTP/1.0\n\n"
Then the client sends "Mime headers" of the same format used in e-mail. The headers tell things like which version browser is being used, and what type of file formats it knows about. Most servers don't really do anything useful with this whole section.
The POST means that the server should expect one more bit of info after the mime headers: the values that the user filled into the blanks of the form.
POST only tells the server to expect values from the client, but the .cgi is the way it knows to execute the file and send its standard-out to the client, instead of sending the file itself.