30 Sept 2002

                    Upgraders Notes for SRE2003


This file contains miscellaneous notes that may be of
interest to sites upgrading from GoServe to  the 
SRE2003 Internet Interface.

** A note on converting GoServe "filters and addons" to SRE2003. **

  The GOS2SRE.CMD program, included with SRE2003, can be used to
  automatically convert filters and addons written for GoServe.  
  While not guaranteed to make all the necessary conversions,
  it should catch many of the necessary conversions.

  However, if you have used the SREF_GOS functions, you'll need
  to change these "by hand".

  GOS2SRE should  be run directly from an OS/2 prompt.

  GOS2SRE.CMD has a number of options -- it can convert multiple
  files, it can automatically convert, it can ask you to approve
  each conversion, and it can create a list of conversion is a
  log file. Especially for complicated code, use of the log file
  is highly recommended.

  We note that in our experience, upgrading from SREHTTP2 to SREHTTP/2 (the
  filter and associated addons), we did NOT use GOS2SRE. Instead, we
  systematically edited the SREHTTP versions, adding and modifying code
  as needed. Although more time consuming, the efficiency and capability
  improvments from fully using the SRE2003 tools and procedures warranted 
  the extra effort.

                -------------------------
                

** Major Changes:

* SRE2003, like GoServe, uses  "filters" to implement a web server.
  Three filters are availalbe:
        SIMPLE : a simple (but fast) filter that comes with SRE2003
       SRE2LITE: a fairly simple filter (available from srehttp2.srehttp.org)
       SREHTTP2: the full-featured replacement for SREHTTP (available from 
                 srehttp2.srehttp.org)


* Using SRE_COMMAND to specify completion codes 

  SRE2003 does NOT support the  "stand alone" style of completion
  codes used by GoServe -- such as 'FILE xxx ' and 'VAR xxx'. 
  Instead, completion codes (and their arguments)
  are now invoked through the SRE_COMMAND procedure. 


* The parameters sent to the filter have been augmented.
  They now include:
     SOURCE,REQUEST,SEL,HOST_STUFF,ID_INFO,REQNUM,AUTHH,ISALIVE
  where SOURCE, REQUEST, and SEL are the same as what GoServe
  sends. The remaining arguments are described in section 5a
  of SRE2003.HTM.

* Audit and status features have changed -- see SRE2003.HTM
  for the details.

* SRE2003 versions of GoServe functions.
  Several GoServe functions are supported with slightly different names.
  These include:

    GoServe Name             SRE2003 Name
    =========================================
   DATADIR                    SRE_DATADIR                                     
   PACKUR                     SRE_PACKUR                     
   COMPLETED                  SRE_COMPLETED                  
   STILL_ALIVE                SRE_STILL_ALIVE                
   CLIENTNAME                 SRE_CLIENTNAME                 
   EXTRACT                    SRE_EXTRACT                    
   CACHED                     SRE_CACHED                     
   GMTOFFSET                  SRE_GMTOFFSET                  
   PACK64                     SRE_PACK64                     
   PACK64_MAKE                SRE_PACK64_MAKE                
   SERVER                     SRE_SERVER                     
   SERVERNAME                 SRE_SERVERNAME                 

  For those with many GoServe procedures, you can load a "GoServe compliant library",
  thereby avoiding the need for changing the above function names. See the
  goserve_compatability parameter in SRE2003.CMD for the details.

 * SAY should NOT be used in filters or addons. Instead, use
   PMPRINTF (or, better yet, the SRE_PMPRINTF procedure).

   Or, the SRE_WRITE_MESSAGE function can be used to write to the "message
   area" of the SRE2003 status screen.

* New Features:

 * GZIP, as a transfer-encoding, can be done on-the-fly

 * The CHUNKED transfer-encoding method can be used (on a 
   request specific basis).

 * http/1.1 compliant range extraction will automatically take place
   (you can suppress this on a request specific basis)

 * Built in support for Instance Manipulation. In particular, support for 
   Delta-Encoding.

 * http/1.1 compliant conditional gets, such as 301 responses,
   are now resolved automatically (you can suppress this on a request
   specific basis)

 * Support for maintained connections (multiple requests per
   connection). This can be disabled on a request specific basis 
   (that is, the connection can be closed after request resolution).

 * A moderately advanced, http/1.1 compliant, proxy-like request cache 
   is now part of SRE2003. For the details, see Appendix 1 in SRE2003.HTM

 * SRE2003 includes MD5 computation procedures. This can be used,
   for example, to automatically generate a Content-MD5 response headers.

 * Generic procedures to implement daemons, and data structures
   (such as small permanent databases, lists, and caches), are built into 
   SRE2003. See SREAPI.TXT for the details.

 * A large number of new procedures are available: see SRE2PRC.HTM
   for the details. These include procedures for automatically sending
   file-moved responses, authorization requests, and error
   conditions (such 404s).

 * Tracking of request status is now supported  (it can be
   disabled). See Appendix 5 for the details.

 * SRE2003 can be given a list of IP addresses (or address ranges)
   for whom access is automatically disallowed. 
   See BADIPS.IN for details.

 * A "fast filter" can be specified. The fast filter should be 
   a simple and fast filter -- it will be called before the
   normal filter. If the fast filter fails to respond to the
   request, then the normal filter is called. This can help
   speed up throughput when many requests to your server are
   simple (i.e.; are for publically available static files
   for which logging is not important).

 * Support for multiple-hosts is built into SRE2003.
   See INITHOST.RXX and  HOSTINFO.CFG file for details.
   Note that SREhttp/2, the primary filter for SRE2003, supports
   its own method of specifying multiple hosts.

 * A set of custom written initialization procedure can  be run when
   SRE2003 first starts. See INITHOST.RXX for an example.

 * Several caches, in addition to the request cache, are built into
   SRE2003.  These include a clientname cache and an MD5 (for files)
   cache. All of these caches can be disabled.

 * Transaction specific limits.

   You can now set several "transaction specific" limits. Specifically,
         LIMITTIMEINACTIVE
         LIMITTIMEWAIT
         LIMITTIMETOTAL
         LIMITBODY
         DATADIR
   can now be set by transaction. See the description of the SET mode
   of SRE_COMMAND.



