sreLite2 -- an http/1.1 server for OS/2
Abstract	sreLite2 ver 1.10 is an http www server for OS/2. It is freeware, and requires the SRE2003 Internet Server.

Contents:

Features of sreLite2 include:

• On-line configuration
• Support for both "basic" and "digest" authentication
• Access controls on a resource specific basis. In other words, some portions of your web site can be open to the public, some portion can be open to all registered users, and other portions can be open to specified subsets of these registered users.
• Support for multi-hosting
• A directory specific "default" document can be returned when the request does not specify a filename.
• Support for the ~ shorthand for a "users-home" directory.
• Directory-specific customized "404" responses can be sent.
• Optional automatic directory listing when no "default" document can be found.
• A "list of best matches" can be sent instead of a "404" response
• GET, POST, and HEAD are supported
• Full support for cgi-bin/1.1, with support for PERL scripts.
• Support for a quicker (though proprietary) script protocol.
• Range requests are understood
• On-the-fly GZIP transfer-encoding
• Server side imagemaps are supported (using an included addon)
• Server side push (for multi-part documents) is supported
• Support for most of the NCSA server side include options, including #EXEC
• Requests can be recorded in a common log file, or by your own custom procedure.

Note

sreLite2 is based on the SRELite "GoServe filter". Although the feature set is similar, the configuration files (USERS.IN and SRELITE2.CFG) are somewhat different. Also, unless explicitily indicated, SRE-http addons will NOT run under sreLite2 In other words, migrating from SRELite to SRELite/2 will require some hands on tinkering.

Do you have an up to date version of SRE2003? If not, get it and install it (http://sre2003.srehttp.org/)

1. Open up an OS/2 prompt.
2. Unzip srelite2.zip to an empty temporary directory, You can get unzip from http://www.srehttp.org/pubfiles/unzip.exe
3. Change directories (CD) to this no-longer empty temporary directory
4. Run the install.cmd program from an os/2 prompt (the install program will ask you several questions)
5. Start SRE2003.CMD (from an OS/2 prompt)

Notes:

More Notes:

Alternatively, you can modify these files by using the on-line configuration tools accessible through the INDEX.SHT page (on the /SRE2K/sre2003 sub- directory of your "data directory").

By default, these configuration tools are:

1. only accessible from a browser running on the server machine
   You can change i by modifying the SECURITY_LEVEL parameter.

2. require a superuser privilege. For example, you could use the username and password that the sreLite2 installer asked you to provide.
   Although we do not recommend it... you can change ii by modifying the SEL_REQUIRES parameter of SRELITE2.CFG.

Notes:

1. edit SRELITE2.CFG, and/or USERS.IN
2. issue, as a client with SUPERUSER privileges, a /!RESET command.
   or
   issue a /STATUSL? command, and hit the "reset privileges" link at the bottom of the screen.
3. Parameter reset occurs immediately, username/password reset may take > a few seconds.

The following parameters are contained in sre2003.CFG.

... For more details,see SRECFG1.HTM
... For most sites, the most important parameters are: sel_requires, aliases, superusers, and default_requires.

SRELite2 supports a moderately complex set of access controls rules.
The basic notion is:

1. a selector can be assigned a set of required privileges.
2. client can be granted a set of client-privileges
3. If a selector has a set of required privilege, the client can access it only if one of her client privileges appears in the set of required privileges.
   Note that just one match is required, the client does NOT have to match all of the "required privileges"
4. on a multi host system, a selector is also associated with a host

Client privileges are assigned using the SUPERUSERS and INHOUSEIPS parameters, and using the USERS.IN file.

1. The client's IP address is compared to to the SUPERUSERS parameter. If it appears in this parameter, the client is granted a SUPERUSER privilege.
2. The client's IP address is then compared to the INHOUSEIPS parameters. If one of them matches, the client is granted
   • i) a INHOUSE privilege
   • ii) all the privileges associated with the matching INHOUSEIPS entry
3. Lastly, the username and password (supplied by the client in an Authorization request header) is compared to entries in the USERS.IN. If a matching username is found, and this username's password also matches, the client is assigned a USERS privilege, as well as all the privileges associated with the matching entry.

Notes:

     USERNAME  PASSWORD client_Privilege_list

 where all fields can contain letters (A-Z, a-z), numbers (0-9), and _ characters:

  >  Username is a case insensitive username
     The format of username is one of:
        username                -- username applies to all hosts, including the "Generic" host"
        host_nickname/username  -- username ONLY applies to requests to host_nickname
       /username                -- username ONLY applies to requested to the generic host
  >  Password is possibly case-sensitive (depending on the client's authorization protocol)
     It can contain A-Z, a-z, _, and 0-10.
  >  Client_privilege_list is an optional space delimited list of "privileges".

You can also use a * for either username or password ---

  >> the * character for password means "any password will do".
  >> the * in USERNAME is a wildcard -- it means "any username 
     (say, for this host_nickname)

1. The "host-specific" username. This could be the "generic" host, signified by username.
2. The non-host-specific username.
3. The host-specific wildcard
4. The default wildcard

         TIGER/JONES
         JONES
         TIGER/ *
         * 

         /PAUL
         PAUL
         / *
         *              

In any case, if a username is found, it's password is compared to what the client provided. If the password does not match, then the username is not a match.

   ; this is a comment (starts with ;)
   OUTATOWN SHEP2  INHOUSE
   MASTER1 12ISIE6 SUPERUSER
   user1 1user     Priv1 Priv2
   ANONYMOUS *  PUBLIC
   TIGERS/Jill  cats dogs
   SHOP/*  shopper visitorx
   /BILL PILL SILL
   TIGERS/BILL WILL NILL
   BILL HILL  MILL

CGI-BIN

CGI (Common Gateway Interfact) - BIN is a standard by which server side ("gateway") programs can be invoked. It uses environment variables to pass data, as well as standard input and output.

Client

The Client (sometimes referred to as the requester) is the individual requesting a URL -- where the URL may point to a file, or may invoke a script.
Typically, the request was generated by someone running a Web Browser, and clicking on a link or submitting a FORM.

Default Data Directory

The Default Data Directory is the root directory of your web site -- it (and it's subdirectories) are the usual locations for your HTML documents, images, etc. By default, the sre2003 Data Directory is used as the Default Data Directory.

A simple example might help:

a request selector of MYFILES/PROJECT1/BIGTASK.HTM is recieved

your default data directory is E:\WWW

then, SRElite2 will use E:\WWW\MYFILES\PROJECT1\BIGTASK.HTM

Request selector

When a client sends a request to a server, it contains three components: the method, the selector, and the protocol. For example, in the following request line: GET /FOO1/BAR.HTM HTTP/1.0

1. the http method is: GET
2. the selector is: /FOO1/BAR.HTM:
3. the http protocol is: HTTP/1.0:

Note that if a GET HTTP method was used, the request selector may contain information following a ?
For example... /SHOWINFO?DATABASE=PRICES&ITEM=APPLES

Selector-specific

Selector-specific means a piece of information specific to a request selector. In other words, this means that sreLite will use the value of the request selector to find information (such as the required privileges).

URL: Uniform Resource Identifier (URI), and Uniform Resource Locator (URL)

URIs (which are basically synonymous with URLS) are a scheme for specifying Internet resources using a single line of printable ASCII characters. A URL should contain a protocol, domain name, port number (optional), the location of the resource, and an (optional) option list (following a ?).

Example: http://WWW.SREHTTP.ORG:80/calc/calc.htm

Wildcard matching

Wildcard matching use the * as a wildcard character in a natural fashion.

Examples:

     
         /JOE/*  will match /JOE/FOO.HTM
         /JOAN/SRCH.HTM?*  will match /JOAN/SRCH.HTM?search+me
         /JOAN/SRCH.HTM?*  will NOT match /JOAN/SRCH.HTM
             (/JOAN/SRCH.HTM* will match BOTH these examples)
         /PETS/*INDEX.HTM will match
         /PETS/INDEX.HTM, /PETS/CAT/INDEX.HTM and /PETS/PUPPY/LAB/INDEX.HTM
             but will NOT match
         /PETS/CAT/PUREBRED.HTM

Wildcard matching is used when examining SEL_REQUIRES, ALIASES, and INHOUSEIPS.

Wildcard matching with substitution

Wildcard matching with substitution is similar to wildcard matching. However, rather then being a "many to one" match, it is a "many to many" match.

The basic rule is that both a "target" and a "replacement" should contain * characters. When a wildcard match between the target and a candidate occurs, the "covered portion of the candidate" is inserted into the "replacement". In other words, the * character in the replacement is deleted, and the "covered portion" is inserted.

Example:

If the request selector is: PROJECT/JILLWORK.HTM

and there is an alias of: PROJECT/* /RESEARCH/ONGOING/*

the resulting match is: /RESEARCH/ONGOING/JILLWORK.HTM

The following lists a few useful procedures provided in the sreLite2
procedure library. These complement the procedures in the sre2003
procedure library (as described in SRE2PRC.HTM).

  SREL2_RESET           Reread configuration files
  SREL2_MULT_SEND       Send a multi-part document
  SREL2_GET_USERINFO    Extract information on a user
  SREL2_CHECK_PRIVS     Check a list or privileges against a second list

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

SREL2_CHECK_PRIVS

 Check to see if the user has one of the required privileges.

 Syntax: 
    imatch=srel2_check_privs(privs_to_check,privs_granted)

where:

   privs_to_check : a space delimited list of privileges (as may be specified
                    if a sel_requires entry).

   privs_granted:  the privileges of this user; say, as derived from srel2_get_userinfo
                   (that is, as specified in USERS.IN).

and

  imatch:
     0    -- none of the the names in the userlist have any of the 
             privileges contained in the privs_to_check list
     n    -- the first privilege, in the privs_to_check list, found in privs_granted

Notes:
   *  If privs_granted='', then always return 0
   *  If privs_to_check='', then always return 0
   *   a "*" in Privs_to_check matches anything  (thus, if * is the 3 element in
       privs_to_check, then always return 1, 2, or 3).



SREL2_GET_USERINFO


 Determine username, password, and privileges; given either a list
 of possible usernames, or (more commonly) based on information found
 in an authorization request header 

 Syntax: 
    imatch=srel2_get_userinfo(userlist,authh,host_nick,id_info)

 where:

   userlist:   Optional. 
               The list of users to try finding privileges for.
               The first "existing" user in this list is used
               If blank, then construct a user list (see below)

   If userlist is not specified (which is the usual mode of operation), 
   then the following two variables may be used:

      authh: optional. The authorization header. If not provided, it will
             be looked up

     host_nick: optional. The host nickname. 
                If not provided, it will be looked up.  
                If there is no host nickname for this request, the "generic"
                host is assumed.

   id_info: optional, The id_info (include this to speed up processing a bit)

and

  Imatch:
    ' '    -- No match. This can happen for a number of reasons:
                1) none of the the names in the userlist could be found in the
                   userfile
                  Note that if userlist IS specified, then passwords are NOT checked
                2) userlist was not specified, and
                    a) there was no authorization request header 
                    b) the username in the authorization request header was not
                       found in the userlist, or had a mismatching password
     user_record -- Match found. The user_record contains:
                        username password priv1 ... privn
                     Note that the username indicates which username (in the
                     possibly auto-generated userlist) was matched.

 Notes:


 * When userlist is not specified, a userlist containing 4 usernames is constructed.
   These are derived from the authorization header; and are subject to "password" checking. 
   The 4 names consist of:

     1) The "host-specific" username. 
        For request that are not to host for which a host-nickname exist (that is, for
        requests to the "generic" host), use  /username  (i.e.; preface the username 
        with a /).
     2) The non-host-specific username.
     3) The host-specific wildcard
     4) The default wildcard
     
     Thus, if the host nickname is TIGER and the username is JONES 
     then the following entries will be looked for in the userfile
         TIGER/JONES
         JONES
         TIGER/*
         *

     Or, for a request to the "generic host" (i.e.; if you did NOT specify any
     host nicknames), and the username is PAUL:
         /PAUL
         PAUL
         /*
         *
     
    In any case, if a username is found, it's password is compared to what the
    client provided. If the password does not match, then the username is NOT 
    used (a ' ' is returned).

 * A return of ' ' often means you should send an authorization response
   (i.e.; using sre_auth_response)


SREL2_MULT_SEND:

  Send a piece or a part of a response.
  For the details, see MULTSEND.DOC.


SREL2_RESET:
   Reset the sreLite2 configuration parameters -- re-read sreLite2.CFG,
   USERS.IN, or HOSTINFO.CFG.

   Syntax:
        astat=srel2_reset(not_params,douser,dohost)
    where all the parameters are optional:
        doparams = if not_params<>1, then reread sreLite2 configuration
                   parameters file (sreLite2.CFG)
        douse    =  douser=1, then reread the username file (USERS.IN)
        dohost   =  if dohost=1, then reread the sre2003 host definitions file
                    (HOSTINFO.CFG)

        astat    = if no errors, a 1 is returned
                   Otherwise, 'ERROR an_error_message'

   Example:
         f=srel2_reset()      -- just reread sreLite2 configuration parameters
         f=srel2_reset(,1)    -- configuration parameters and user
         f=srel2_reset(1,,1)  -- reset hostinfo, do NOT reset configuration 

As an component of the sre2003 suite, the disclaimer for SRElite2 is the same. Basically,

Permission to use this program for any purpose is hereby granted without fee, provided that the author's name not be used in advertising or publicity pertaining to distribution of the software without specific written prior permision.

SRELITE2 and related product are NOT guaranteed to be secure.

THIS SOFTWARE PACKAGE IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY.