15 May 1998: The SREPROXY "proxy-like" front end for SRE-http.

1) Abstract: 

SREPROXY is a "proxy-like" front end for SRE-http. More precisely, SREPROXY
is a mini filter that provides caching services for SRE-http -- it
is NOT an http compliant "proxy".

The major advantage of using SREPROXY is that it is smalll
(approximately 10k, as compared to 100k for SREFILTR.80), and doesn't try
to do a lot. Thus, when it is applicable (more on that below)
it can be significantly faster then the standard filter (SREFILTR.80).
Most importantly, SREPROXY achieves this performance boost without 
sacrificing any functionality

2) Usage:

To use SREPROXY, just set it to be your "GoServe" filter.  That is,
instead of using SREFILTR.80, use SREPROXY.80.

There are no other requirements--- but do note that if you switch from
SREFILTR.80 to SREPROXY.80, you'll have to restart GoServe. Note that
the parameters in SREFILTR.80 are still used, even though SREFILTR.80 is 
not the primary filter.


Advanced users may wish to modify a few parameters in SREPROXY.RXX, and
one parameter in SREPROXY.80.  However, these are quite minor parameters,
and can be safely ignored.


3) Description

SREPROXY works by comparing all requests against a special
cache (a caching daemon is used). If SREPROXY finds a match to 
a requested resource (in this daemon mediated cache), then the
matching file (and matching http/1.1 compliant headers) are returned.
If no match is found, then the main filter (SREFILTR.80) is called
(as an external rexx procedure). 

Basically, SREPROXY is a replacment for the GoServe cache.  Although the
GoServe cache can be used,  it is (currently) not http/1.1 compliant. Thus,
its use is not generally recommended (for details on using the GoServe
cache with sre-http, see the discussion of the CACHE* permission in 
SREHTTP.HTM).

When using SREPROXY it's a good idea to try and "render cachable"
as many resources as possible (actually, in the http/1.1 world this is
always a good strategy). SREPROXY eases this by providing services that
a normal "proxy server" could not provide. These include:

  a) SREPROXY will "postfilter" all requests -- including requests that it
     resolves. Thus, accurate counts (say, in the COMMON.LOG file) can 
     be maintained.

  b) SREPROXY will resolve a set of "semi-dynamic" SSIs. These include 
     several time and date SSIs, as well as "current" URL SSIs (see
     SREPROXY.SHT for a list of these semi-dynamic SSIs").
     
  c) SREPROXY will check for username/passwords, use them to lookup privileges,
     and compare against the privileges associated with a cached resource.  

There are a few drawbacks associated with the use of SREPROXY

   a) If you have few cachable resources, use of SREPROXY will diminish throughput
      (since the net effect is to add useless work by SREPROXY prior to the invocation
       of SREFILTR).
   b) In some cases, SREPROXY will use be slow about updating its cache after changes
      to an underlying resource (i.e.; if you rapidly & repeatedly change a document).


4) Notes

 *  The SREPROXY "cache" should not be confused with the SSI or !DIR cache.  The
    SREPROXY cache does not lead to the creation of a new file. Rather, it
    consists of a database that relates a request selector to a file, response 
    headers, and other information. This file may be a permanent file (say, a .GIF
    image), or may be a transient "SSI-cached" file (that is, the result of 
    applying static SSI's to an HTML document). In no case does the database contain
    actual content --  there must be some kind of file somewhere for it to return. 
    Thus, truely temporary output can not be cached by SREPROXY.


  * The CACHING.DOC file contains a discussion of other forms of caches that may
    handle requests sent to your server (such as proxy caches, the GoServe cache,
    and the SSI cache).

    
    the