home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / srev13h.zip / SREHTTP.FAQ < prev    next >
Text File  |  2001-03-27  |  58KB  |  1,195 lines
  1. <html><head><title>SRE-http FAQ </title></head><body>
  2. <a name="top">...</a>
  3. <pre>
  4.  
  5. 1 November 1999     SRE-http Frequently Asked Questions
  6.  
  7. Note: This can be viewed as an HTML document by using the following "selector":
  8.                 a href="!sendas_text_html/samples/srehttp.faq"
  9.  
  10.       (assuming that the document resides in the /samples "web directory"
  11.        on an SRE-http server)
  12.  
  13.                      -------------------------------------
  14.  
  15. This document answers the following questions:
  16.  
  17. *   <a href="#WHATIS"> What is SRE-http and GoServe?</a>
  18. *    <a href="#CANDO"> What can SRE-http do?       </a>
  19. *     <a href="#COST"> What does SRE-http cost?  </a>
  20. *   <a href="#CANGET"> Where can I get SRE-http? </a>
  21. *  <a href="#INSTALL"> I downloaded SREV13F.ZIP, how do I install it? </a>
  22. * <a href="#WONTSTART"> SRE-http won't start -- what should I do? </a>
  23. *   <a href="#OBJECT"> Can SRE-http run under Object REXX.  </a>
  24. * <a href="#SLOWRESP"> The response time seems to be very slow....  </a>
  25.  
  26. *<a href="#CONFIGURE"> How do I configure SRE-http?    </a>
  27. *<a href="#CONGFILES"> Can I edit SRE-http's configuration files? </a>
  28.  
  29. *   <a href="#ACCESS"> How can I control access to my site?  </a>
  30. *  <a href="#SELSPEC"> How can I control access to a directory? </a>
  31. *    <a href="#PRIVS"> What are "client privileges" and "resource privileges"?</a>
  32. *   <a href="#REALMS"> What's the difference between REALMS and privileges? </a>
  33. *   <a href="#PRIV2S"> I'm still confused about these privilege things?  </a>
  34. *    <a href="#USERS"> How can I limit the capabilities of different users? </a>
  35.  
  36. * <a href="#STOREIMG"> How can I limit off-site links to our images? </a>
  37. *     <a href="#SSIS"> What are the server side include capabilities of SRE-http? </a>
  38. *  <a href="#COOKIES"> Can I use cookies with GoServe and SRE-http? </a>
  39. *  <a href="#UPLOADS"> I am having trouble with uploads, what should I do? </a>
  40. * <a href="#DEFAULTS"> What about default documents?  </a>
  41. *  <a href="#VIRTDIR"> What are SRE-http's virtual directories? </a>
  42. * <a href="#REDIRECT"> How do I redirect a request?  </a>
  43. *<a href="#CUSTOMIZE"> Can I customize SRE-http responses?  </a>
  44. * <a href="#WILDCARD"> How does SRE-http deal with multiple "wildcard" matches? </a>
  45. * <a href="#THANKYOU"> How can I send a "thank you" note after  a file download? </a>
  46. *     <a href="#HITS"> How can I record the number of hits I get? </a>
  47. *  <a href="#SPEEDUP"> How can I speed up throughput?  </a>
  48. *<a href="#MEDIATYPE"> How do I define new MIME media types?  </a>
  49. *  <a href="#RELOADS"> How can I prevent NetScape from reloading files too frequently? </a>
  50. *   <a href="#ADDONS"> What are the SRE-http addons?  </a>
  51. * <a href="#MULTITHR"> How is SRE-http multi-threaded? </a>
  52.  
  53. To users of Don Meyer's GoHTTP -- where appropriate, this document notes
  54. the similarities between the two filters.  You might want to pay special
  55. attention to:
  56.     What are "client privileges" and "resource privileges"?
  57.     How do I redirect a request?
  58.     What are SRE-http's virtual directories?
  59.     How can I control access to my site?
  60.  
  61.  
  62.                    ------------------------------------------
  63.  
  64.  
  65. *** The basics:
  66.  
  67. * <a name="WHATIS">   What is SRE-http and GoServe?   </a>
  68.  
  69.    SRE-http is an http/1.1 compliant World Wide Web server for OS/2.
  70.    More precisely, SRE-http is a "filter" for the GoServe OS/2 Internet Server.
  71.    GoServe, an IBM EWS "freeware" product, is an HTTP and Gopher server.
  72.    GoServe requires a "filter", written in REXX, to interpret and process
  73.    requests for resources.  SRE-http is one of several such filters.
  74.  
  75. * <a name="CANDO">    What  can SRE-http do?   </a>
  76.  
  77.   In a nutshell:
  78.     SRE-http is a http/1.1 compliant web server OS/2. SRE-http is designed 
  79.     for non-cutting edge, small-to-medium load sites being maintained 
  80.     by non-professionals who want a high degree of functionality in an 
  81.     easily maintained system.  SRE-http is also well suited for REXX proficient
  82.     individuals interested in creating a highly customized site.
  83.  
  84. * <a name="COST">      What does SRE-http cost.  </a>
  85.  
  86.   $0.00.  You may freely distribute SRE-http, and you may dissect, subsect,
  87.   and otherwise utilize its source code.  Please be aware of the standard
  88.   "use at own risk" disclaimer, and the fact that SRE-http is in NO way
  89.   an official or unofficial product of the U.S government.
  90.  
  91. * <a name="CANGET">    Where can I get SRE-http  </a>
  92.  
  93.   The latest version of SRE-http (it's constantly being updated) can be
  94.   found at http://www.srehttp.org/.  SRE-http is also
  95.   available from a number of file repositories: the latest version
  96.   will always be on hobbes (http://hobbes.nmsu.edu/ -- search for SREHTTP)
  97.  
  98. **** Installing SRE-http
  99.  
  100. * <a name="INSTALL">   I downloaded SREV13F.ZIP, how do I install it?  </a>
  101.  
  102.    i) Create a temporary directory somewhere on your hard drive,
  103.   ii) Copy SREV13F.ZIP to this temporary directory
  104.  iii) Using UNZIP, unzip SREV13F.ZIP 
  105.   iv) Read the READ.ME file
  106.    v) Run the INSTALL program (type INSTALL from an OS/2 prompt)
  107.  
  108.   By the way: SRE-http ver 1.3h is designed to work with GoServe 2.52 (and
  109.               above). Earlier versions (2.45 to 2.50) of GoServe will work, 
  110.               but several http/1.1 features can not be supported with versions
  111.               of GoServe prior to 2.52.
  112.  
  113.  
  114. * <a name="WONTSTART"> SRE-http won't start -- what should I do? </a>
  115.  
  116.      *  Are you using GoServe 2.52?  If not, you'll need to download it
  117.         (from http://www2.hursley.ibm.com/goserve)
  118.      *  You must set the Options-Limit-Connection_maintain to some positive
  119.         number (say, 15).
  120.      *  Is the GoServe working directory pointing to the directory you 
  121.         installed SRE-http into?
  122.      *  Is the GoServe data directory (Options-Datadir) pointing to the
  123.         "root of your web tree".
  124.  
  125.      If you still have problems after checking the above, you should obtain
  126.      PMPRINTF.EXE from http://www2.hursley.ibm.com/goserve) and run 
  127.      it before you start GoServe.  PMPRINTF opens a small window into which
  128.      GoServe/SRE-http can write status and error messages  -- often, these
  129.      will indicate what your problem is.
  130.  
  131.      If you are still stuck, feel free to contact Daniel Hellerstein
  132.      (danielh@crosslink.net).
  133.  
  134.      Advanced Users Note:
  135.         If you are willing to sacrfice full compliance with http/1.1, you
  136.         can force SRE-http to ignore some of these prerequisites by
  137.         setting the CHECK_COMPLIANCE parameter in SREFMON.CMD.
  138.  
  139.  
  140. * <a name="OBJECT">      Can SRE-http run under Object REXX?       </a>
  141.  
  142.   SRE-http was designed to run under "classic" REXX (technically, REXXSAA).
  143.   Unfortunately, for several reasons, the current version of SRE-http
  144.   (ver 1.3h) will NOT run object REXX.
  145.  
  146.   If you really want to use SRE-http and Object Rexx, you might
  147.   be interested in obtaining ver 1.2g of SRE-http, and some
  148.   special modifications of ver 1.2g.  However, besides lacking
  149.   many features of the current version, experience has shown that
  150.   this combination (modified 1.2g and Object Rexx) is not very stable.
  151.  
  152.   For details, see the "are you using OBJECT REXX" link on the
  153.   SRE-http home page.
  154.  
  155.   Author's note:  If there is real interest in using SRE-http in an
  156.   Object REXX environment, I might be persuadable ...
  157.  
  158.  
  159. * <a name="SLOWRESP">      The response time is very slow ...     </a>
  160.  
  161.   For unknown reasons, on some Warp 4.0 machines running version 4.0 of TCP/IP,
  162.   SRE-http has horrid response times (many seconds to return simple documents).
  163.   This has been solved by upgrading to TCP/IP version 4.02t
  164.   (you can find fix packs at http://service5.boulder.ibm.com/pspfixpk.nsf
  165.    or ftp://ps.software.ibm.com/ps/products/tcpip/rsu/stack/latestv4.html).
  166.  
  167.  
  168. * <a name="CONFIGURE">    How do I configure SRE-http?      </a>
  169.  
  170.    Most people will probably want to use the built in configurator.
  171.    This configurator is designed to be run via your web brower.
  172.    Assuming you did not make major modifications to SRE-http's
  173.    installation defaults, you can just point your web browser at:
  174.            http://your.browser.wherever/configur.htm
  175.    You will then be given the choice between a "simple-mode",
  176.    "intermediate mode", and "expert mode" configurator.  New users
  177.    will probably like the "simple mode" best.
  178.  
  179.    Both the simple and intermediate modes make heavy use of HTML
  180.    FORMS.  The simple mode has a "one, well-documented, form
  181.    per parameter" philosophy.  The intermediate mode has a
  182.    "one, not-so-well-documented, form for a large set of parameters"
  183.    The advantage of the simple mode is ease of use.  The disadvantage
  184.    is that it does not give you access to some of the more obscure
  185.    SRE-http parameters.
  186.  
  187.     Hint: If SRE-http denies you access to the configurator, you should
  188.           check the OWNERS variable (in INITFILT.80) to make sure it's
  189.           that same as your browser's IP address.  Or, use the
  190.           username/password that the INSTALL procedure asked you to
  191.           supply (or did you skip that part)?
  192.  
  193. * <a name="CONGFILES">    Can I edit SRE-http's configuration files?    </a>
  194.  
  195.   For those who like to make their changes quickly, you may want
  196.   to directly edit the SRE-http configuration files, and not
  197.   bother with the configurator. The configuration files are
  198.   all text (ascii) files, which you can modify with your favorite
  199.   text edtior (such as OS/2's EPM editor).
  200.   The most important configuration files are:
  201.        INITFILT.80, INIT_STA.80, ATTRIBS.CFG, ALIASES.IN, ACCESS.IN, 
  202.        VIRTUAL.IN, PUBURLS.IN, and USERS.in
  203.   All of these files are installed to the CFGS\ subdirectory of your
  204.   GoServe "working" directory (the directory you installed SREFILTR.80 to).
  205.  
  206.   If you plan on editing INITFILT.80 or INIT_STA.80, you should read INITFILT.DOC 
  207.   first. ATTRIBS.CFG and the various .IN files are described in 
  208.   IN_FILES.DOC.
  209.  
  210. *** Some more specific questions:
  211.  
  212. *  <a name="ACCESS">    How can I control access to my site?    </a>
  213.  
  214.    SRE-http contains three levels of access controls:
  215.  
  216.    *) LOGON controls: a "can you get into our site" control.
  217.    *) Directory specific: directory specific controls using  HTACCESS files.
  218.    *) Resource specifc: "SEL-specific" access controls contained in 
  219.       ACCESS.IN and ATTRIBS.CFG.
  220.  
  221.    Logon controls pertain to all requests.  You can tell SRE-http
  222.    to check none, some, or all requests for username/password authorization
  223.    (using the BASIC authorization scheme).
  224.  
  225.    For details on "logon controls", see the description of the CHECKLOG,
  226.    OWNERS, INHOUSEIPS, and UNALLOWEDIPS variables in INITFILT.DOC.
  227.    Or, check out the appropriate sections in the "simple mode" configurator.
  228.  
  229.    Of greater interest are the "directory specific" and "SEL-specific"
  230.    access control methods.  The HTACCESS method (using code graciously
  231.    provided by Don Meyer) uses special "HTACCESS" files located in the
  232.    directory (and in the parent directories) of the requested file.
  233.    This (or these) HTACCESS files contain information on who has access
  234.    rights to files in the directory (and in child directories).
  235.  
  236.    In contrast, "SEL-specific" access controls compare the request selector
  237.    against a list of "selectors".  This list (which may contain wildcarded
  238.    entries) dictates who can access these selectors.  Note that, in contrast
  239.    to HTACCESS files, there is one globally maintained list, rather then
  240.    seperate "HTACCESS file" per directory.
  241.  
  242.         Note that we use the term "SEL-specific" to mean "Selector-specific",
  243.         where the "selector" is the slightly-modified middle portion of
  244.         the client's request string.
  245.         For example, a URL of
  246.               http://foo.bar.net/dir1/redsox.htm
  247.         would generate a request string of
  248.               GET  /dir1/redsox.htm  http/1.0
  249.         which yields a selector of
  250.                    dir1/redsox.htm
  251.         In other words, SEL-specific access controls are
  252.         sensitive to how you code links in your HTML documents.
  253.  
  254.    The choice of method is a matter of taste and convenience -- controlling
  255.    directories is a sure way to prevent access to files, but controlling
  256.    selectors is more flexible.  In fact, these two methods (SEL-specific and
  257.    directory-specific) can be used jointly, which implies multiple checks. But
  258.    be careful when using both methods, it is possible to get stuck in
  259.    authorization loops!
  260.  
  261.    Since "SEL-specific" controls are native to SRE-http, they will tend
  262.    to be faster.  Therefore, our recommendation is to use the SEL-specific
  263.    method. 
  264.  
  265.    Lastly, to allow unhindered access to selected clients, or to a subset of
  266.    your site, you can use INHOUSEIPS. (in INITFILT.80) or the PUBURLS.IN
  267.    file. 
  268.  
  269.     *  You can circumvent access controls for selected server resources by
  270.        by using "PUBLIC_URLS" (in PUBURLS.IN(.  When the client's 
  271.        "request selector" matches a PUBLIC_URLS, access controls are not 
  272.        attempted.
  273.  
  274.     *  INHOUSEIPS. parameters are similar to the IDENT method of
  275.        authorization (but INHOUSEIPS. does not obtain or use
  276.        username@ information).  Basically, if a client's IP address
  277.        matches one of a set of "INHOUSEIPS", she is given access
  278.        to the site (though she may still need resource/directory specific
  279.        privileges).  Note that these INHOUSEIPS entries may contain wildcard
  280.        characters.
  281.  
  282.     *  By the way, the simple mode configurator can be used to create,
  283.        and  INHOUSEIPS. parameters. For information on how to specify
  284.        PUBLIC_URLS, see PUBLURLS.DOC.
  285.  
  286. * <a name="SELSPEC">    How can I use selector specific access controls to 
  287.                         control access to a directory?                  </a>
  288.  
  289.    Since "SEL-specific" can refer to "a set of resources on your server"
  290.    (via the use of the * wildcard), and since selectors typically point
  291.    to directories, "SEL-specific" controls are easily used to control
  292.    access to files in a subdirectory.
  293.  
  294.    A simple example follows:
  295.  
  296.    1) Place an entry in ACCESS.IN of the form
  297.             Relative_DIR_NAME/*    A_Privilege
  298.       For example:
  299.              ROCKETS/*    ROCKETEERS
  300.        (...to access selectors beginning with ROCKETS/, the client 
  301.            must have a  ROCKETEERS  priviliege).
  302.  
  303.    2) Place an entry in the USERS_FILE (e.g.; USERS.IN) of the form:
  304.            username  password  privilege_list
  305.       For example:
  306.            OBRIEN  JORDIX2  ROCKETEERS
  307.        (.. User OBRIEN, with password JORDIX2, has a ROCKETEERS privilege).
  308.  
  309.    3) Set ALLOW_ACCESS="NO" (in INITFILT.80)
  310.       (... SRE-http will check privileges for all requests).
  311.  
  312.    4) you might want to add a
  313.          *  *
  314.      entry to the ACCESS.IN file to signal "all other 
  315.      files/directories are open access".
  316.  
  317.    Summarizing this example:
  318.      When the client asks for anything in (or under) the ROCKETS subdirectory
  319.      (of your GoServe data directory), SRE-http will challenge the user
  320.      for a username and password.  If the client enters a username
  321.      with the correct privileges (such as OBRIEN), he will be allowed entry.
  322.  
  323.    Notes:
  324.       *  If CHECKLOG='ALWAYS', SRE-http will only "re-challenge"
  325.          the client if his initial logon privileges did NOT contain a
  326.          matching privilege.
  327.       *  The simple mode SRE-http configurator can be used to add
  328.          (and remove) both SEL-specific access controls and
  329.          username/password entries.
  330.       * You can also use ATTRIBS.CFG to define "realms", with a realm defined
  331.         as a set of selectors.  One can then assign "required privileges" 
  332.         to each of these realm.
  333.  
  334. * <a name="PRIVS">    What are "client privileges" and "resource privileges" ? </a>
  335.  
  336.     SRE-http uses "privileges" to provide flexibility and brevity
  337.     when assigning (and determining)  access rights.
  338.  
  339.     "Client privileges" are assigned to clients in a variety of
  340.     fashions (typically as part of their username/password
  341.     authentication).  In a sense, "client privileges" can be thought of
  342.     as shorthands for "groups of users".  In fact, one could simply
  343.     define the client's username as a (or as the only) privilege
  344.     (the ADD_USER_NAME variable is used for just that purpose!).
  345.  
  346.     The point is that by allowing multiple privileges per username,
  347.     a given client can be placed in many different groups of users.
  348.  
  349.     "Resource privileges", contained in SEL-specific access
  350.     control entries (in ACCESS.IN) or in "realm definitions" (in ATTRIBS.CFG)
  351.     refers to these "client privileges".  Resource privlieges can be thought 
  352.     of as a list of "groups of users".  In the extreme case of each username
  353.     having a single privilege (equal to her username), the "resource
  354.     privileges" list the acceptable users!
  355.  
  356.    Advanced users note:
  357.         If you start a client privilege with a ? (say, ?PXX12), then
  358.         this will be treated as a "secret privilege". Secret privileges
  359.         are NOT used in access controls, and SRE-http utilities
  360.         should NOT reveal their values.  They are designed to be
  361.         by used by addons, such as the DYN_PWD "dynamic password"
  362.         addon.
  363.  
  364.     In comparison to the HTACCESS method:
  365.        * The PASSWD.LST file is akin  to SRE-http's USERS.IN file
  366.          (albeit one that's directory specific); but with each entry
  367.          (in PASSWD.LST) assigned just an "own name" client privilege.
  368.        * The GROUPS.LST file is akin to a privilege, with each entry
  369.          in GROUPS.LST dictating which users have the "groupname" privilege.
  370.  
  371. * <a name="REALMS">    What's the difference between realms and privileges?   </a>
  372.  
  373.   SRE-http's SEL-specific access control method is based on the notion of  
  374.   "privileges".  Basically,  a "client's privileges" are compared to a 
  375.   "resource's privileges", and if they match (as discussed above), access is granted.
  376.  
  377.   Resource privileges can be assigned directly to selectors using 
  378.   ACCESS.IN. Alternatively, resource priviliges can be defined to a "realm", 
  379.   using the ATTRIBS.CFG.
  380.  
  381.   The "define realms" method corresponds to how most browsers use
  382.   "realms".  Basically, most browsers will store a username and password
  383.    on an IP address and realm specific basis. When a server asks for 
  384.   authorization, it will tell the browser what "realm" the
  385.   resource belongs to.  Assuming that the username (and password) for
  386.   this ip-address/realm combination is available (say, due to  an earlier request
  387.   for another resource), then the browser will return the appropriate
  388.   username and password.
  389.  
  390.   The basic point is that the notion of "realms" is part of the http mindset,
  391.   and SRE-http supports this notion via the ATTRIBS.CFG file. In particular,
  392.   ATTRIBS.CFG defines a realm using "selector matching" rules; one can
  393.   have several (possibly wildcarded) rules defining a given realm.
  394.  
  395.   Note the key point -- realms are defined as collections of selectors --
  396.   a collection that span your hard drives in complicated ways.
  397.   And though use of ATTRIBS.CFG file is now recommended, advanced users may 
  398.   find it easier to use ACCESS.IN to carefully specify access controls on
  399.   a per selector basis.
  400.  
  401.   Advanced users note:
  402.     In ACCESS.IN, you can define "SEL-specific realms" (see IN_FILES.DOC for
  403.     details).  This is a semi-obsolete feature which is NOT THE SAME as the 
  404.     realms defined in  ATTRIBS.CFG.  
  405.  
  406.  
  407. * <a name="PRIV2S">    I'm still confused about these privilege things?    </a>
  408.  
  409. It's actually simpler then it reads, especially if you don't need the
  410. fancier features. Let's sketch out one such "simple" approach:  
  411.  
  412.     1) Use the simple- mode configurator to add a set of users.
  413.        For each user, you provide a username, password, and a
  414.        list of client privileges.
  415.     2) Use the simple-mode configurator to create "SEL-specific"
  416.        access-control entries. For each entry you'll specify the request
  417.        string (perhaps ending with a *), a list of resource
  418.        privileges, and an (optional) realm.  In most cases, you'll only
  419.        need to define one "resource privilege" per selector; and you
  420.        can even use this one resource privilege as the realm name (see
  421.        the description, in INITFILT.DOC, of REALM_1ST_PRIV for details).
  422.  
  423. That's all you have to do -- user's with a "client privilege" that
  424. matches ANY ONE of a "selector's" resource privileges will be granted
  425. access rights to it.  If they haven't entered a username/password
  426. before hitting a protected server resource, the (optional) realm (or,
  427. the 1st resource privilege),  will be displayed on their browser's 
  428. authorization screen.
  429.  
  430. * <a name="USERS">    How can I limit the capabilities of different users 
  431.                       of my server?                                      </a>
  432.    The use of "SEL-specific" permissions allows one to control what
  433.    capabilities of the server are avaiable to different users.
  434.    Of particular interest are the following permissions:
  435.         NO_SSI : All server-side includes will be suppressed
  436.         NO_SSP : All server side processing will be suppressed
  437.         NO_CODE: INTERPRET CODE and SELECT keyphrases will be
  438.                   suppressed (these are "in-document" executable
  439.                   statements).
  440.    Note that these permissions are applied on a "SEL-specific" basis (using
  441.    ACCESS.IN) or on a "sub-realm" basis (using ATTRIBS.CFG).
  442.  
  443.    Thus, a given client may have "server side include" privileges
  444.    on some parts of your web-site, but not on other parts.
  445.  
  446.  
  447. * <a name="STOREIMG">    How can I prevent other web sites from using 
  448.                          images stored on our server?           </a>
  449.  
  450.   If other sites are using your server to "store" files, such as interesting
  451.   .GIFs for use as in-line images, you may find this annoying.  For example,
  452.    you may maintain a publicly accessbile clip-art collection, which you
  453.    are happy to give away.  However, you don't want lazy websters to
  454.    use inline images that point to the files on your server.
  455.  
  456.    To preclude such sneaky tricks, you should use the "additional privileges"
  457.    facility of SRE-http.  Basically, you  issue a short-term
  458.    client privilege to all clients who "visit" your site (say, who
  459.    loads up the welcome screen for your clip-art collection).
  460.    This short-term client privilege is then required for all
  461.    requests for the actual clip-art files.  Thus, a request coming out of
  462.    the blue (with no prior request for  the "welcome" screen) will NOT
  463.    be assigned the short-term privileges, and access will be denied.
  464.  
  465.    The following outlines what you need to  implement the above:
  466.      *) Assume you have a /CLIPART directory, with lots of .GIF files in it.
  467.     **) Assume that your "welcome to clipart" page is called
  468.         /CLIPART/HELLO.HTM
  469.      1) Set SRE-http's variables:
  470.                  CHECK_ADD_PRIVS='YES'
  471.                  ALLOW_ACCESS='NO'
  472.                  ACCESS_FAIL_FILE=1
  473.         (you will have to hand-edit INITFILT.80 to change CHECK_ADD_PRIVS
  474.          and ACCESS_FAIL_FILE. Note that any non-0 value of ACCESS_FAIL_FILE
  475.          will do)
  476.      2 Add the following entries to your ACCESS.IN file
  477.           /CLIPART/HELLO.HTM *
  478.           /CLIPART/*.GIF  !GETCLIP , , , -1
  479.        (the -1 signals "do NOT ask for authorization in event of failure")
  480.      3) Add the following line to /CLIPART/HELLO.HTM
  481.            <!-- INTERPRET FILE ADDPRIVS.RXX  GETCLIP , 30 -->
  482.  
  483.           <!-- If you are reading  this as a text file, the above
  484.                      "url encoded" addition should read as  (but drop the leading !) -->
  485.            <!-- ! INTERPRET FILE ADDPRIVS.RXX  GETCLIP , 30 -->
  486.  
  487.    That's it!  You might want to add a * * line to ACCESS.IN (assuming
  488.    your site is otherwise open access).
  489.  
  490.    For further discussion of "dynamic privileges", see ADDPRIVS.DOC
  491.  
  492. * <a name="SSIS">     What are the server side include capabilities 
  493.                       of SRE-http?                            </a>
  494.  
  495.    A major advantage of SRE-http is the ease with which a variety
  496.    of Server Side Includes  (SSIs) can be invoked-- just by adding special
  497.    keyphrases to your HTML document. Even better, these server side
  498.    includes are processed recursively -- so a server side include
  499.    can invoke further server side includes.
  500.  
  501.    SRE-http supports two classes of server side includes, instances of
  502.    which can be freely intermingled in your documents:
  503.  
  504.        i) The SRE-http syntax.
  505.           The SRE-http syntax supports a variety of server side includes,
  506.           such as:
  507.             a) Inclusion of a file
  508.             b) Inclusion of a set of "dynamic variables" (such as time/date)
  509.             c) Inclusion of user defined "static variables"
  510.             d) Execution of a REXX program, with inclusion of "QUEUED"
  511.                output
  512.             e) SPECIAL Feature: Exclusion of a portion of a document,
  513.                based on the results of user written REXX code
  514.             f) Headers and Footers can be added to all documents.
  515.  
  516.        ii) The NCSA HTTPD syntax.
  517.            The NCSA HTTPD syntax is supported by SRE-http.  It overlaps
  518.            largely with the SRE_Filter syntax, with a few extra file-information
  519.            and time/date display features, and a CGI execution capacity.
  520.            More importantly, it's something of a standard.
  521.            For more information on the NCSA HTTPD server side includes,
  522.            check out http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html
  523.  
  524.       iii) Apache Extensions
  525.            The SET and IF Apache extensions to the NCSA HTTPD syntax are
  526.            also supported.  These can be used for creating conditional 
  527.            html documents.
  528.  
  529. *<a name="SSICACHE">      What is the SSI-Cache?            </a>
  530.  
  531.    To improve performance, SRE-http can "intelligently" cache
  532.    documents that contain server-side includes.  In simple cases,
  533.    these cached entries can be sent to the client "as is" -- relieving
  534.    the server of the need to reprocess the "server side includes".  Needless
  535.    to say, this can yield major performance advantages.
  536.  
  537.    The "intelligently" refers to those not-so-simple cases where the server
  538.    side includes are "dynamic".  "Dynamic" server side includes are items that
  539.    change over time, client, and circumstance.   A few obvious examples
  540.    include the current time, the "number of hits", and the client's IP address.
  541.    Obviously, one can't cache-return dynamic server side includes "as is".
  542.  
  543.    SRE-http solves this dilemna by "partially caching".  Basically, "static"
  544.    includes are performed (such as file INCLUDES), and placemarkers are
  545.    created for the "dynamic" includes.  This can substantially diminish the
  546.    workload, especially in cases where large file include (such as a standard
  547.    menu bar) are combined with minor dynamic includes (such as the current
  548.    "hit"). If you are still curious, SSICACHE.HTM contains a more detailed
  549.    discussion.
  550.  
  551.  
  552. * <a name="COOKIES">     Can I use cookies with GoServe and SRE-http?     </a>
  553.  
  554.    The short answer is YES -- the 'HEADER ' GoServe "return code",
  555.    and the REQFIELD() function can be used to read and write cookies.
  556.  
  557.    SRE-http offers a few conveniences when processing cookies:
  558.         *) The INTERPRET "keyphrase" of SRE-http provides a convenient
  559.            means of reading and creating cookies; and of changing
  560.            the contents of document based the values of the cookies.
  561.         *) SREF_GET_COOKIE, a "macrospace" procedure provided with SRE-http,
  562.            facilitates "cookie extraction".
  563.  
  564.    Notes:
  565.      *  A good description of cookies can be found at:
  566.           http://home.netscape.com/newsref/std/cookie_spec.html
  567.      *  A short example of how SRE-http works with cookies can be found
  568.         in SAMPCOOK.SHT and SAMPCOOK.RXX
  569.  
  570.  
  571. * <a name="UPLOADS">    I am having trouble with uploads, what should I do? </a>
  572.  
  573.  
  574.   SRE-http's implementation of "file uploads" requires
  575.   the use of an HTML document that contains a special type
  576.   of  FORM. This should be constructed as:
  577.  
  578.       <FORM enctype="multipart/form-data" ACTION="/put_file" METHOD="post">
  579.            Some stuff here:
  580.       <INPUT TYPE="file"  name="userfile" value="filename.ext">
  581.            More stuff
  582.       </FORM>
  583.  
  584.   <!-- If you are reading this document as a text document, please
  585.        replace < for < and > for > in the above examples      -->
  586.  
  587.   For an example of such a  document, you can look at the
  588.  "PUT_FILE" portion of the UPLOAD.HTM file that comes with SRE-http.
  589.  
  590.   In addition, an HTML 3.x  aware browser (netscape 2.01 and above),
  591.   that knows how to properly deal with such FORMs, has to upload this
  592.   document.
  593.  
  594.   But before you start, you should check the following variables in
  595.   your INITFILT.80 file (or you can use SRE-http intermediate mode
  596.   configurator).
  597.  
  598.        UPLOAD_DIR :Change this to your desired "upload directory:
  599.             Example: UPLOAD_DIR = 'g:\GOSERV\upload '
  600.  
  601.   These next are automatically set upon installation, and are probably
  602.   okay; but you might want to check them just for fun.
  603.         UPLOAD_MINFREE  : Minimum space (in Kbytes) that must exist on
  604.                           your disk after upload
  605.                  Example: UPLOAD_MINFREE= 20000
  606.  
  607.         UPLOAD_MAXSIZE  : Maximum size of file upload (in Kbytes)
  608.                  Example: UPLOAD_MAXSIZE=1000
  609.  
  610.              UPLOAD_LOG :  Location of a "log" file, a short note on
  611.                            recieved uploads are written here.
  612.                  Example:UPLOAD_LOG = 'g:\GOSERV\UPLOAD\UPLOAD.LOG '
  613.  
  614.   With these setting in place, with your HTML document ready to rock
  615.   (again, see UPLOAD.HTM for an example), and with your client running
  616.   NetScape 2.01; everything should be ready to go!?
  617.       That is, when the client requests this form, Netscape gives
  618.       her a file-browse box. When the form is submitted, Netscape
  619.       appends the file, and SRE-http writes it to a file name
  620.  
  621.   Note that some installations have intermittent problems with 
  622.   uploads.  The latest fix packs (FP5 and above for Warp 4.0) seem
  623.   to help a lot, as does use of GoServe 2.52.
  624.   You may also want to change the limit on body size (say, to 1M if
  625.   you might get large uploads).
  626.  
  627.                       !!!!  Reviewing:   !!!!!
  628.  
  629.   1) Check your INITFILT.80 settings (especially the UPLOAD_DIR parameter)
  630.   2) Create an HTML document with a special FORM element
  631.      (see UPLOAD.HTM for an example)
  632.   3) You might need to change some Goserve settings
  633.   4) Request your html document with netscape 2.01 (other browsers
  634.      might work.  .. but WebEx  1.1d does NOT understand this type of FORM
  635.      element)
  636.  
  637.   By the way, UPLOAD.HTM contains a discussion on how to specify the
  638.   filename that SRE-http should use when saving the file.
  639.   You may also want to look at SREHTTP.HTM for further discussion  of
  640.   the PUT_FILE facility of SRE-http.
  641.  
  642.  
  643. * <a name="DEFAULTS">     What about default documents?          </a>
  644.  
  645.   SRE-http recognizes two types of "default documents" -- those for
  646.   "empty requests", and those for "requests to a directory".
  647.  
  648.       When an empty request arrives, the DEFAULT variable is used to indicate
  649.       what document to return.  For example, if DEFAULT='INDEX.HTML', then
  650.       a request for http://foo.bar.net/ would result in D:\WWW\INDEX.HTML
  651.       being returned (assuming that D:\WWW is your GoServe default data
  652.       directory).
  653.  
  654.       "Requests to a directory" refers to requests that mention a directory
  655.       name, but no file. For examplem, a request for http://foo.bar.net/mule/
  656.       refers to the "default document in the MULE subdirectory".  In order
  657.       to find this "default document", the AUTO_NAME variable is used.
  658.       For example, if AUTO_NAME='INDEX.HTML *.HTM ', then SRE-http
  659.       would first look for MULE/INDEX.HTML, and then look for MULE/MULE.HTM.
  660.  
  661.         Note: depending on the value of the NOEXT_TYPE variable,
  662.               a request for http://foo.bar.net/mule could also
  663.               be interpreted as a "request for the default document
  664.               in the MULE subdirectory"
  665.  
  666.  
  667.   Consider the following examples:
  668.  
  669.       http://foo.bar.net  -- empty request; uses the DEFAULT
  670.       http://foo.bar.net/  -- empty requests, use the DEFAULT
  671.       http://foo.bar.net/index -- depends on the value of NOEXT_TYPE. 
  672.           By default, SRE-http assumes this is a request to the "INDEX" 
  673.           subdirectory, and will try to use look for the AUTO_NAME files
  674.           in this INDEX subdirectory.  In the likely event that there 
  675.           is no INDEX subdirectory, a "could not find resource" error
  676.           message will be returned to the client.
  677.       http://foo.bar.net/index.  --- Looks for INDEX.; which probably does not 
  678.          exist. If it does exist, given the empty extension, SRE-http will 
  679.          transfer it as  a "text/plain" file (you can change this by
  680.          modifying MEDIATYP.RXX).
  681.  
  682.       http://foo.bar.net/index.htm   -- Looks for INDEX.HTM
  683.       http://foo.bar.net/index.html -- Looks for INDEX.HTML
  684.  
  685.   Now let's consider the behavior of the REPLACE HITS server side include.
  686.  
  687.      Because REPLACE HITS records on a "selector specific basis", and because
  688.      it's sort of difficult to indicate an "empty selector", SRE-http records
  689.      "empty requests" using a listing of --DEFAULT--.   Let's suppose that
  690.      DEFAULT='INDEX.HTM'. Now consider an request to INDEX.HTM -- it would be
  691.      recorded under a listing of INDEX.HTM.  Thus, you would need to add up
  692.      the INDEX.HTM and -DEFAULT- entries to find the true total number of
  693.      requests that yielded INDEX.HTM.
  694.  
  695.      If this is a disagreeable notion, you might want to use REPLACE HITS_FILE
  696.      -- it stores entries by fully-qualified file name; in the above example,
  697.      empty requests would be stored under  D:\WWW\INDEX.HTM (assuming that D:\WWW
  698.    is your GoServe default data directory).
  699.  
  700.  
  701. * <a name="VIRTDIR">    What are SRE-http's virtual directories?       </a>
  702.  
  703.     By default, SRE-http will match a request selector to a file in the 
  704.     "GoServe data directory".  While a good security feature (files not in or
  705.     under the GoServe data directory are inaccessible), this can be an 
  706.     inconvenience.
  707.  
  708.     To remedy this inconvenience, one can define "virtual directories"
  709.  
  710.     Basically, SRE-http will compare the starting portion of the client's
  711.     request to see if it matches one of your virtual directory entries. If it
  712.     does, the target directory listed in the matching entry is used
  713.     (instead of the data directory).
  714.  
  715.     Thus, you can make available a wide, but controllable, set of
  716.     directories (on or LAN accessible from) your server.
  717.  
  718.     Furthermore, virtual directories can point to "remote" directories on
  719.     other http servers --  SRE-http will attempt to retrieve the file
  720.     from the remote server, without using a redirection!
  721.  
  722.     For details on the use of the virtual directories, see the 
  723.     description of VIRTUAL.IN in IN_FILES.DOC, or see the
  724.     desciption of the REDIRECT: DIR action in the DEFREALM section
  725.     of IN_FILES.DOC.
  726.  
  727.     Or, you can use the configurator!
  728.  
  729.  
  730.     Note: Compared to Don Meyer's GOHTTP filter:
  731.          * GOHTTP's use of "aliases" corresponds to SRE-http's use of
  732.            "virtual directories",
  733.          * GOHTTP's use of "redirection" (via the REDIRECT.LST files)
  734.            corresponds to  SRE-http's use of "aliases".
  735.  
  736.     An example of the use of virtual directories:
  737.          i) Assume that the Goserve data directory is D:\WWW
  738.         ii) Assume you want to provide access to the following files;
  739.                 D:\WWW\TELLME.HTM, D:\WWW\BIRDS\PARROT.HTM,
  740.                 E:\SOUND\NATURE\CHIRP.WAV, E:\SOUND\NATURE\MORE\TWEET.WAV,
  741.                 E:\PHOTOS\SKY\FLYING.JPG
  742.         iii) Two entries should be included in VIRTUAL.IN
  743.                   NATURE/   E:\SOUND\NATURE*
  744.                   PHOTOS2/   E:\PHOTOS\SKY*
  745.  
  746.          Given i,ii, and iii; the following links can be used
  747.                  HTML anchor      ---> points to --->   file
  748.               href="/TELLME.HTM"              D:\WWW\TELLME.HTM
  749.               href="/BIRDS/PARROT.HTM"        D:\WWW\BIRDS\PARROT.HTM
  750.               href="/NATURE/CHIRP.WAV"         E:\SOUND\NATURE\CHIRP.WAV
  751.               href="/NATURE/MORE/TWEET.WAV"    E:\SOUND\NATURE\MORE\TWEET.WAV
  752.               href="/PHOTOS2/FLYING.JPG"       E:\PHOTOS\SKY\FLYING.JPG
  753.  
  754.  
  755. *<a name="REDIRECT">        How do I redirect a request?       </a>
  756.  
  757.    One of the strengths of SRE-http is the variety of redirection
  758.    mechanisms it offers, where redirection implies "sending the client
  759.    a file that is not a direct mapping of the request selector.  Redirection
  760.    has two general classes: remote and local.
  761.  
  762.     "Remote" redirection, which  is what most of the literature simply
  763.     calls redirection, involves telling the client's browser that
  764.     "the url you have been requested has been moved to xxxx", where xxxx may
  765.     be any URL  -- it need not be on the same server, and it need not have
  766.     the same name.
  767.  
  768.     To do remote redirection, you need to add an entry to the list of aliases
  769.     contained in ALIASES.IN, either by editing with your
  770.     favorite text editor, or by using the configurator. Or, you can include
  771.     a REDIRECT: MOVED action in ATTRIBS.CFG.
  772.  
  773.     For example, an entry (in the alias-file) of
  774.          whatgot  http://www.mine.org/dir1/index1.htm
  775.     would cause the server to send back a "302" response to the client's
  776.     browser whenever a request for "whatgot" arrives.  This 302 response,
  777.     would instruct the client's browser to automatically request
  778.           http://www.mine.org/dir1/index1.htm.
  779.  
  780.    The above could be accomplished with an entry in ATTRIBS.CFG; such as:
  781.         Realm: redir1
  782.         rule: whatgot
  783.         redirect: moved= http://www.mine.org/dir1/index1.htm
  784.  
  785.    "Local" redirection is handled solely by SRE-http, and involves
  786.    directly modifying the "request selector."
  787.    SRE-http has a number of methods of specifying "local redirection",
  788.    such as the DEFAULT, AUTO_NAME, NOEXT_TYPE variables, and the
  789.    use of entries (in ALIASES.IN) of the form:
  790.          whatgot   dir1/index.htm.
  791.    Local redirections actually involve textual substitution (after SRE-http
  792.    has recieved the request). Among other advantages, this gives you quite a
  793.    bit of control over how "SRE-http facilities, and external procedures"
  794.    percieve the request.
  795.  
  796.    Note that the above could be accomplished with an entry in ATTRIBS.CFG; 
  797.    such as:
  798.         Realm: redir2
  799.         rule: whatgot
  800.         redirect: internal = dir1/index1.htm
  801.  
  802.   Notes:
  803.  
  804.    * A CAUTION on local redirection and partial urls:
  805.        When using aliases for "local redirection", partial URL resolution by
  806.        the client's browser may have unexpected consequences. See the
  807.        discussion of "local  vs remote redirection" in INITFILT.DOC for details!
  808.  
  809.    * On Using HTACCESS files for redirection:
  810.        In addition to the use of the ALIASES.IN, the REDIRECTFILE parameter
  811.        of HTACCESS files can be used for "directory specific" redirections
  812.        (see the description of the HTACCESS_FILE variable, in INITFILT.DOC,
  813.        for more details).
  814.  
  815.     * Compared to Don Meyer's GOHTTP filter:
  816.          * GOHTTP's use of "aliases" corresponds to SRE-http's use of
  817.            "virtual directories",
  818.          * GOHTTP's use of "redirection" (via the REDIRECT.LST files)
  819.            corresponds to  SRE-http's use of "aliases".
  820.  
  821. * <a name="CUSTOMIZE">        Can I customize SRE-http responses.    </a>
  822.  
  823.   In a number of circumstances, SRE-http will generate an error or status
  824.   response. For example, if a request file does not exist, or if a client
  825.   does not have access rights to a file, SRE-http will send a somewhat terse
  826.   response (but at least it's not a totally terse "401 Unauthorized"
  827.   displayed all by itself)!
  828.  
  829.   Currently, you can customize a few of these responses (for details,
  830.   see the descriptions in INITFILT.DOC):
  831.  
  832.      No file found:
  833.        The NOT_FOUND_URL parameter can be assigned a
  834.        short string, which will be displayed in the middle of a
  835.        generic message.  Alternatively, you specify a special
  836.        "not found" response file (typically, an HTML document
  837.        that you create)
  838.  
  839.      Logon denied:
  840.         SRE-http can either reprompt the client for a different username
  841.         and password, or it can send her a custom written response
  842.         file.  This file's name is set with the LOGON_FAIL_FILE.
  843.  
  844.      Access to a server resource denied:
  845.           If a request is denied due to insufficient "SEL-specific" privileges,
  846.           SRE-http can either reprompt the client for a different username,
  847.           or it can send her a custome written response file.  This default
  848.           name of this file is set with the ACCESS_FAIL_FILE parameter.
  849.           In addition, you can specify "SEL-specific accesss failure response
  850.           files" -- see the descriptions of the ACCESS_FILE (in SREHTTP.HTM,
  851.           or in the sample IN_FILES.DOC) for details on this advanced
  852.           option.
  853.  
  854.    ! And if you want to really get fancy, you can use the CUSTOMIZ addon 
  855.      to customize, on a client specific basis, the appearance of your pages !
  856.  
  857.  
  858. * <a name="WILDCARD">      How does SRE-http deal with multiple 
  859.                            "wildcard" matches.                     </a>
  860.  
  861.    When SRE-http attempts to match a selector to an "alias", "virtual 
  862.    directory",  or "access control entry", it is possible that several entries
  863.    will be "wildcard" matches.  Depending on the action, several different
  864.    rules are used (in all cases, if an exact match exists, it's always used):
  865.  
  866.    *VIRTUAL Directories: The longest "abbreviation match" is used:
  867.           Example: If the selector is FOOD/FRUIT/ORANGES.HTM
  868.           and VIRTUAL.IN contains:
  869.                 /FOOD    D:\SNACKS\*
  870.                 /FOOD/FRUIT   E:\HEALTHY*
  871.           then  the /FOOD/FRUIT entry will be used (since both match, but
  872.           /FOOD/FRUIT is longer then /FOOD
  873.  
  874.    *ACCESS control, PUBLIC_URLS, and ALIASES: A multiple wildcard match algorithim is used.
  875.       Example: If the selector is FOOD/FRUIT/ORANGES.HTM
  876.      Then the following all match; with earlier entries used first.
  877.      That is, if more then one of these entries appears in ACCESS.IN,
  878.      then the one earlier in the list is used.
  879.                 FOOD/FRUIT/*HTM
  880.                 FOOD/FRUIT/*
  881.                 FOOD/*IT/*HTM
  882.                 FOOD/*.HTM
  883.                 FOOD*
  884.       (these entries can appear in any order in this file, with no
  885.        effect on precedence).
  886.  
  887.      Furthermore, ACCESS, PUBLIC_URLS, and ALIAS matching suport "multiple replacements".
  888.      For example, an entry (in ALIASES.IN) of:
  889.         school/*/personal/*/pictures*  arg1=*:arg2=*
  890.      And a request of:
  891.         school/grade8/personal/killebrew/pictures/family.jpg
  892.      would yield:
  893.          arg1=grade8;arg2=killebrew
  894.      
  895.    * ATTRIBS.CFG: Same as above 2.
  896.         Depending on the "action", either an "abbreviation match" or a 
  897.         "wildcard match" is attempted.
  898.        
  899.  
  900.    * RECORDALL, and others
  901.     A "single wildcard" algorithim is used (you can NOT include more
  902.     then one * character).  Using the above example, the following
  903.     entries are used (with earlier ones have precedence).
  904.                 FOOD/FRUIT/*
  905.                 FOOD/*.HTM          (more characters after the *)
  906.                 FOOD/*
  907.       (these 4 entries can appear in any order in this file, with no
  908.        effect on precedence).
  909.  
  910.   For further details, see the various "sample" configuration files shipped
  911.   with SRE-http.
  912.  
  913.  
  914. * <a name="THANKYOU"> How can I send a "thank you" note after 
  915.                        a browser is finished downloading a file?          </a>
  916.  
  917.   In Nestcape (and probably MSIE)  a response header of the form:
  918.      refresh: 4 ; url=/adir/afile.ext
  919.   will cause the cleint's browser to obtain  /adir/afile.ext 4 seconds after 
  920.   the current file (or other resource)  has been obtained -- and this works for
  921.   any content-type (html documents, gifs, .zip files, etc.).
  922.  
  923.   So, how one can instruct SRE-http to include such a response header?
  924.  
  925.   Answer:  It's easy -- use the Advanced-options! 
  926.  
  927.   Basically:
  928.  
  929.     1) in ACCESS.IN; specify an "advanced options" file for the selector(s) 
  930.        for which you wish some kind of "thank you" note to be sent.
  931.  
  932.        Note: You can use the intermediate configurator to add these "advanced 
  933.             options files" to "selector specific" entries in ACCESS.IN. 
  934.  
  935.     2) Create these "advanced options" files (as specified in the ACCESS.IN)
  936.         --  they should be in or under the SRE-http data directory 
  937.             (i.e.; \goserve\data)..
  938.  
  939.     3) Include in the advanced options files entries of the form:
  940.          HEADER ADD Refresh: 5 ; url=/adir/afile.ext
  941.        where the 5 can be any time (in seconds) to pause, and 
  942.        /adir/afile.ext is a selector for netscape to grab after this pause.
  943.        Actually, the advanced options file can contain just this entry; no 
  944.        other entries need appear (for further details, see ADV_OPTS.DOC). 
  945.  
  946.  
  947.   You can also use "pre-send" documents -- say,an html document that states  
  948.   "you asked for x, wait a minute and I'll give it to you". To do this:
  949.     1) create a link  to a "pre-send" html document
  950.     2) include, in this "pre-send" document, a line in the <HEAD> section of 
  951.        the form:
  952.           <meta  HTTP-EQUIV="Refresh" Content="9 ; URL=/adir/afile.ext" >
  953.        where 9 is the pause, and /adir/afile.ext is the file to be downloaded.
  954.  
  955.     You can  even combine a "pre-send" and "thank you" notes by appropriately 
  956.     defining (in ACCESS.IN) an advanced-options file for /adir/afile.ext.
  957.  
  958.  
  959.  
  960. *<a name="HITS">         How can I record the number of hits I get?     </a>
  961.  
  962.   SRE-http provides a wide variety of tools for recording the number
  963.   of hits you recieve. These include:
  964.  
  965.      1) The RECORD_ALL_FILE. The RECORD_ALL_FILE is used to record
  966.         the number of times ALL of your files are requested (on a
  967.         file-by-file basis).  It does NOT record individual requests, nor
  968.         does it place a "number of hits" line into a requested document.
  969.         The RECORD_OPTION parameter of SRE-http is used to
  970.         turn this option on or off.
  971.      2) The COUNTER_FILE is used to record, and display, total hits
  972.         for explicit files. The COUNTER_FILE is accessed by the
  973.         REPLACE HITS SRE-http "server side include"
  974.         keyphrase (there are several variants of this keyphrase).
  975.      3) The SENDFILE_FILE is used to record files that are
  976.         transfered with SRE-http's SENDFILE facility.
  977.      4) COUNTER.RXX is used to track hits requests on a file-specific
  978.         basis, and can record individual requests (as well as
  979.         total requests). COUNTER.RXX  can be invoked as a server
  980.         side include (using a  INTERPRET COUNTER.RXX  xxx
  981.         keyphrase), or it can be invoked by  SENDFILE.
  982.         Lastly, the output of COUNTER.RXX is highly configurable.
  983.      5) XCOUNT.CMD is a CGI-BIN script that generates
  984.         a simple odometer for specific files (it's meant to be
  985.         included as an in-line image).
  986.         JCOUNT.CMD is similar, but is called using an
  987.          #EXEC xxx style  server side include (both of
  988.         these are courtesy of Don Meyer).
  989.      6) The GOAUDIT.80 file contains tons of stuff, you can use it
  990.         (but you'll have to wade through a lot of verbiage).
  991.      7) SRE-http supports the common-log audit files, and there are
  992.         lots of tools out there for analyzing common-log files.
  993.  
  994.      For details on the above choices, see SREHTTP.HTM, INITFILT.DOC, and
  995.      COUNTER.DOC.  Power users will probably like COUNTER.RXX the best,
  996.      (and when used with SENDFILE, COUNTER.RXX can be used with any type
  997.      of file, not just HTML documents).
  998.  
  999.      One last point: A nice feature of the COUNTER_FILE and
  1000.      RECORD_ALL_FILE is the ability to NOT augment the counter when
  1001.      repetitive requests  (from the same client) are recieved --
  1002.      check out the descriptions of the HIT_CACHE_LEN, HIT_CACHE_DURATION,
  1003.      and HIT_OWNER_SUPPRESS variables in INITFILT.DOC
  1004.      (note that COUNTER.RXX  has similar features).
  1005.  
  1006.  
  1007.  
  1008. * <a name="SPEEDUP">        How can I speed up throughput?      </a>
  1009.  
  1010.   The best way to speed up throughput is to use the SREPROXY
  1011.   variant of SRE-http. SREPROXY is a "proxy-like" front end
  1012.   for SRE-http.  It can detect "cached" resources, and
  1013.   respond to them quickly (without needing to check the various
  1014.   SRE-http aliases, access controls, etc.) 
  1015.   
  1016.   Note that these cached resources do NOT refer to the GoServe cache 
  1017.   but to the http/1.1 style "proxy caches" (that may be cached by any
  1018.   proxy anywhere on the web).  Since SREPROXY is not a http/1.1  
  1019.   (or even http/1.0) proxy, we call it "proxy-like"; but since
  1020.   it only talks to one server, adherence to spec is not necessary.
  1021.  
  1022.    Alternatively, if you are running a simple site (non-fancy ssis,
  1023.    not a lot of scripts, etc); then the SRELITE variant of SRE-http
  1024.    can be several times faster.
  1025.  
  1026.   For other speed up hints, see the introduction to INITFILT.DOC
  1027.  
  1028.  
  1029.  
  1030.  
  1031. * <a name="MEDIATYPE">      How do I define new MIME media types?       </a>
  1032.  
  1033.   There are several ways of defining resource specific mimetypes.
  1034.   More specifically, there are several ways of tell SRE-http what
  1035.   Content-type response header to send to the client.
  1036.  
  1037.   a) defining "file extension" mime types.
  1038.  
  1039.      By default, SRE-http maps file extensions to mime types. For 
  1040.      example, .HTM and .HTML files are assumed to be text/html
  1041.      resources, and .GIF files are assumed to be image/gif
  1042.      resources.
  1043.   
  1044.      To:
  1045.         * define a new file-extension-to-mimetype mapping, 
  1046.         * to map a non-standard extension to a standard MIME media type,
  1047.         * or to redefine one of the default mappings, 
  1048.      just edit the MEDIATYP.RXX file located in the GoServe directory 
  1049.  
  1050.       ... the default version of MEDIATYP.RXX contains detailed
  1051.           instructions.
  1052.  
  1053.      Notes: 
  1054.        * The MEDIATYPE_FILE_ALWAYS parameter (described in INITFILT.DOC)
  1055.          is used to selectively suppress checking of MEDIATYP.RXX.
  1056.        * The default list of extension-to-mimetype mappings is 
  1057.          contained in the MEDIATYP.SRF file located in SRE-http's
  1058.          LIB subdirectory. Ambitious webmasters can change
  1059.          this file (and then recompile using MAKELIB.CMD).
  1060.        * You can define host-specific entries in MEDIATYP.RXX.
  1061.  
  1062.    b) defining selector specific mime types.
  1063.       
  1064.       The ACCESS.IN (or ATTRIBS.CFG) file can be used to define selector 
  1065.       specific mimetypes. In particular, you can can set a MIME "advanced
  1066.       option"; either by including an Option: Mime entry in ATTRIBS.CFG, or
  1067.       specifying a selector-specific advanced options that contains
  1068.       a Option: Mime  entry.
  1069.       For the details, see ADV_OPTS.DOC.
  1070.  
  1071.      Notes:
  1072.        * you can modify ACCESS.IN and ATTRIBS.CFG using SRE-http's intermediate 
  1073.          configurator.
  1074.  
  1075.    c) defining the mimetype in the URL.
  1076.       When you code a link in your HTML documents, you can use the
  1077.       !SENDAS special prefix to tell SRE-http what mimetype to use
  1078.       for the desired resource.  This can be useful if you want to
  1079.       use a special mimetype. For example, to allow clients to either
  1080.       an HTML document, or to view its source code:
  1081.         <a href="foobar.htm"> View our latest FOOBAR instructions?</a>
  1082.                 or
  1083.         <a href="!SENDAS_TEXT_PLAIN/foobar.htm">see the foobar.htm source code</a>?
  1084.  
  1085.       For details on the use of this "special prefix", see SREHTTP.HTM.
  1086.  
  1087.   Note:
  1088.    *  You may also wish to define a subset of text/html resources to be "server
  1089.       side include capable".  To do this, you need to set the SSI_SHTML_ONLY
  1090.       variable to 'YES', and edit the SSI_EXTENSIONS variable (located in
  1091.       INIT_STA.80).
  1092.    *  Methods b and c will override both the default mimetype assignation
  1093.       (as specified in MEDIATYP.SRF), and the MEDIATYP.RXX "extension-to-
  1094.       mimetype" assignment of mimetype.
  1095.    *  Method c overrides b.  Thus, using a !SENDAS_type_subtype is the ultimate
  1096.       means of dictating what the Content-type response header will be (assuming 
  1097.       you aren't invoking a server-side script).
  1098.       
  1099.  
  1100. * <a name="RELOADS">      How can I prevent NetScape from reloading files 
  1101.                           too frequently?              </a>
  1102.  
  1103.   Certain browsers (NetScape 2.x seems to be the most stringent about this)
  1104.   are quite serious about reloading "expired" documents WHENEVER you
  1105.   refresh them.   That is, not only will such documents be loaded afresh
  1106.   upon the first request of a session, but even if you "back button" to
  1107.   it, Netscape will reload it!
  1108.  
  1109.   There are many cases where SRE-http (actually, GoServe by default) will
  1110.   return a document with an "immediate expire" (i.e.; documents
  1111.   with server side includes, and results of CGI-bin scripts).  Hence,
  1112.   this "feature" of NetScape can be quite annoying.
  1113.  
  1114.   To alleviate this annoyance, you can set the FIX_EXPIRE variable to
  1115.   a "time delay".  When this time delay is greater then 0, the
  1116.   expiration date will be augmented (correctly accounting for
  1117.   new-dates and GMT).  This eliminates the over zealous refresh
  1118.   activity of NetScape, but retains the "don't keep this
  1119.   temporary file around forever" notion.
  1120.  
  1121.   Further details are contained in the description of the FIX_EXPIRE
  1122.   variable in INITFILT.DOC.
  1123.  
  1124.  
  1125. *<a name="ADDONS">            What are the SRE-http addons?       </a>
  1126.  
  1127.    As an alternative to the CGI-BIN script interface, one can
  1128.    write REXX routines that are called directly by SRE-http,
  1129.    without the somewhat convoluted use of environment strings
  1130.    that CGI-BIN scripts depend on.
  1131.  
  1132.    Currently, there are several addons available for SRE-http.
  1133.    A few of these addons are:
  1134.       FORUM: A  "news-group and list-server" discussion-group package
  1135.         BBS: A full featured "web based bulletin board system"
  1136.    GETAFILE: A  directory displayer, with user-settable display features
  1137.     GOSWISH: A front-end (and more) to the freeware SWISH search engine.
  1138.  
  1139.    These addons can be obtained from the SRE-http home page at
  1140.    http://www.srehttp.org/apps/
  1141.  
  1142.    You can also run PERL scripts as SRE-http addons -- for the details,
  1143.    see SRE-http's PERL.DOC file.
  1144.  
  1145.  
  1146. * <a name="MULTITHR">           How is SRE-http multithreaded.       </a>
  1147.  
  1148.    Both GoServe and SRE-http are multi-threaded. GoServe uses 3 threads for its
  1149.    own internal workings, and then allocates a temporary thread to each request. 
  1150.    That is, when a request arrives, GoServe will launch SRE-http in its
  1151.    own thread.  After SRE-http has responded to the request, it exits and
  1152.    the thread dies.
  1153.  
  1154.    In addition to these GoServe threads and the temporary threads, SRE-http 
  1155.    launches a number of "daemons" in their own non-temporary threads; 
  1156.    which will be active until GoServe is stopped.
  1157.    
  1158.    These SRE-http daemons are used for number of operations. The primary uses  
  1159.    are to retain SRE-http configuration information in a readily accessed 
  1160.    format.  For example, the username database, the list of virtual 
  1161.    directories, and the access control entries are all attended to be a 
  1162.    daemon. When SRE-http needs this information, it "asks the daemon"; 
  1163.    thereby avoiding the hassle involved with  reading  the raw configuation 
  1164.    files. In addition, daemons are used for non-time sensitive tasks. 
  1165.    These include "logging", PMPRINTF display, and various  post-filter operations.
  1166.   
  1167.    The following lists the thread identifications that typically will occur
  1168.    (on some very slow or very fast machines, this ordering may be different).
  1169.    You can use a system monitor, such as WATCHCAT, to observe the status of 
  1170.    these threads.
  1171.         1 to 3 : GoServe threads.
  1172.          4     : The first temporary, request specific thread
  1173.          5     : The SRE-http monitor (it launches/maintains the daemons)
  1174.          6     : The front end to PMPRINTF
  1175.          7     : The variable storage thread
  1176.          8     : The access control thread
  1177.          9     : The alias resolution thread
  1178.         10     : The public-urls thread.
  1179.         11     : The username thread
  1180.         12     : The virtual directory thread
  1181.         13     : The SSI-cache thread
  1182.         14     : The postfilter thread
  1183.         15     : SREPROXY: "proxy cache" thread 
  1184.         Other threads are used for :
  1185.            * additional temporary, request specific threads.
  1186.            * other daemons (such as the SRE-Data daemons)
  1187.         
  1188.    
  1189. <hr>-----------------------------------------------------------
  1190.  
  1191. --- End of document.
  1192.  
  1193. <p><A HREF="#top">To top of document </a> </pre></body></html>
  1194.  
  1195.