1 Nov 1999. A Description of SRE-http selector-specific attribute files. This document details the function, structure, and syntax of several of SRE-http's user-configurable files; with special attention to files that are used to set selector-specific attributes. Table of Contents: 1. Introduction 1.1 A note on wildcard matching 1.2 A note on superceding hosts 2. The .IN files 2.1 ACCESS.IN 2.1.i Introduction 2.1.ii Structure of entries 2.1.iii Notes 2.1.iv Examples 2.2 ALIASES.IN 2.2.i Introduction 2.2.ii Structure of entries 2.2.iii Notes 2.2.iv Some Examples 2.2.v Some Cautions 2.3 PUBURLS.IN 2.3.i Introduction 2.3.ii Syntax 2.3.iii Examples 2.4 VIRTUAL.IN 2.4.i Introduction 2.4.ii Basic structure of entries 2.4.iii How virtual directories work 2.4.iv General Notes 2.4.v Using the limitation_list 2.4.vi Specifying remote "target urls" 2.4.vii Match precedence 2.4.viii Examples 3. Specifying selector-specific attributes using realms 3.1 ATTRIBS.CFG 3.1.i Introduction 3.1.ii Syntax 3.1.iii Limitations 3.1.iv Some notes on using realms and subrealms 3.1.v Some notes on superceding realms 3.1.vi Some examples ------------------- 1) Introduction User-configurable, selector-specific attributes are attributes that you (the web site administrator) may wish to set on a request-selector basis. These include access requirements, controls on how SRE-http will process a request, URL redirections, and other remappings. * Definition of "request selector:" The "request selector" is the slightly modified middle portion of the request string sent by a client to a server. For example, a URL of http://your.server/big/dance/price.htm would generate a request string of GET /big/dance/price.htm HTTP/1.0 and the selector would be big/dance/price.htm SRE-http supports two broad methods of specifying these selector-specific attributes: a) by using one of the several .IN files (ACCESS.IN, ALIASES.IN PUBURLS.IN, and VIRTUAL.IN), or b) by defining "realms" using the ATTRIBS.CFG file. For several reasons we recommend use of the latter method (defining "realms"): i) the "mime-like" structure of ATTRIBS.CFG is easier to understand then the more idiosyncratic structure of the .IN files ii) SRE-http's use of realms mirrors how most browsers store access information iii) When used with CFGLIST.CFG, you can use the intermediate-configurator to modify "port and host" specific versions of ATTRIBS.CFG However, since the latter method (the "realms method") was introduced as of ver 1.3f, users upgrading SRE-http may not wish to bother translating their .IN files to the equivalent ATTRIBS.CFG entries (even though this translation is not that complicated). Note that both methods can be used simultaneously (technical note: they both feed into a unified database). However, to avoid accidentally specifing contradictory attributes it is probably best to stick to just one method. On multi-hosts servers, both methods provide 2 means of specifying "host specific" parameters: a) you can specify which "host" an entry is to be applied to, or b) you can specify, in CFGLIST.CFG, auxillary files that contain entries that will be used only with a specified host and port. Please see USE_CFGS.DOC for a description of how to specify these host and port specific files. ------------------- 1.1) A note on wildcard matching In many cases, SRE-http uses a "wildcard" matching algorithim to determine the best match between a request selector and a set of entries (say, a set of possible aliases). This section describes this wildcard matching algorithim. Match precedence and wildcarding: Entries are checked using a "multiple wildcard" algorithim, with multiple substitutions. If several entries can match the selector... 1) Exact matches always take precedence 2) The wildcard match that has the most "early character" matches wins Thus, if your selector is FOOD/FRUIT/ORANGES.HTM then the order (with first being chosen before last) is: FOOD/FRUIT/ORANGES.HTM (the exact match) FOOD/FRUIT/*HTM FOOD/FRUIT/* FOOD/*IT/*HTM FOOD/*.HTM FOOD* (these entries can appear in any order in this file, with no effect on precedence). Special feature: ending the TARGET with a | means "no / or \ can be covered by the final *". Thus, if the selector is: "anim/cats/food.1", then anim/*food.1 >> will yield a match, but anim/*food.1| >> will NOT yield a match (since "cats/" contains a /) The purpose of this feature is to "limit" wildcard matches to a single subdirectory (that is, to prevent matches to items in deeper portions of the directory tree) Some wildcard examples: /BILL/DOG.HTM will match /BILL/DOG.HTM /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/*FOOD/*INDEX.HTM will match /PETS/FOOD/INDEX.HTM, /PETS/CAT/FOOD/INDEX.HTM and /PETS/PUPPY/FOOD/LAB/INDEX.HTM but will NOT match /PETS/CAT/PUREBRED.HTM and /PETS/FOOD/HELLO.HTM /STORE/*.JPG| will match /STORE/RADIO.JPG but will not match /STORE/DEPT1/TV.JPG ------------------- 1.2 A note on superceding hosts Entries in these user-configurable parameter files are either "host specific" or "non-host specific". Host specific entries are only checked for requests that are to a particular host, non-host specific entries are used for "almost" all requests. SRE-http will use a "best match" algorithim (described above) to determine which entry to use. For several of these files, (ATTRIBS.CFG, ALIASES.IN, ACCESS.IN, and VIRTUAL.IN) this algorithim is a function of whether the "host" (to which a request was directed) is a "strict-superceding", a "superceding", or a "non-superceding" host. Basically, Strict Superceding host: "Host-specific" entries are checked. Non-host specific entries are NOT checked. Superceding host: "Host-specific" entries are checked. If there are ANY matching host-specific entries, then the best matching host-specific entries is used. If there are no matching host-specific entries, then the non-host specific entries are checked. In other words, if there are ANY matching host-specific entries, the non-host specific entries will NOT be checked (host specific entries trump non-host specific entries). Non-superceding hosts, Both "host-specific" and "non-host specific" entries are checked. The best match from this combined set of entries is used. Thus, a non-host specific entry can be used in preference to a host-specific entry (host specific entries do NOT trump non-host specific entries). The type of host is defined by the form of the host_nickname: a) Strict-superceding hosts have "host_nicknames" that start with a _!! For example: _!!TREES b) Superceding hosts have "host_nicknames" that start with a _! For example: _!FOREST c) Otherwise, it is a non-superceding host For example: RURAL 1.2.i. An example: 1) IF: _!FOREST is the host-nickname for forest.mysite.org 2) AND: the following entries are defined in ACCESS.IN _!FOREST// BBS/* PRIV1 BBS/AREA12/* PRIV2 B* PRIV3 3) THEN: a request for http://forest.mysite.org/bbs/area12/foo.bar 4) WILL REQURE: PRIV1 privileges 5) THIS IS BECAUSE: the _!FOREST// BBS/* PRIV1 entry "supercedes" the "better matching" non-host specific entry of BBS/AREA12/* PRIV2 Or: 1) IF: the host-nickname was RURAL (a non-superceding host), 2) THEN: a PRIV2 privilege would be required (since BBS/AREA12/* is a better match to bbs/area12/foo.bar). Or: 1) IF: the host-nickname was _!!TREES (a strict-superceding host), 2) THEN: a request for http://forest.mysite.org/bell/hello.txt 3) WILL NOT match any entries (implicitly requiring a SUPERUSR privilege) 4) HOWEVER: if the host_nickname was RURAL 5) THEN: a PRIV3 privilege would be required, since the B* PRIV3 non-host specific entry is a match. ------------------- 2. The .IN files. In this section, the four ".IN" files are described in detail. Note that these files can be editied using your favorite text editor, or with SRE-http's "intermediate configurator" (/CONFIGUR.HTM). Notes: * in most cases, the following descriptions can also be used for "host and port specific .IN" files -- with the exception that the "HOST_NICK//" parameter should NOT be used in entries that appear in "host and port specific" files. ------------------- 2.1. ACCESS.IN ACCESS.IN is used to control access, and to assign various attributes. 2.1.i)Introduction The ACCESS.IN file is used to control access to your server's resource on a selector specific basis. This access control is based on a comparison of a client's "privileges" and the privileges assigned to a selector. ACCESS.IN is also used to set several selector-specific attributes, including: *) A variety of "permissions" *) An "access failure file" *) The realm to which this resource belongs *) The name of an advanced options file ------------------- 2.1.ii) Structure of entries Each entry should be a space delimited list containing: HOST_NICK// ASEL RES_PRIVS , PERM_LIST , REALM , FAIL_FILE , ADVOPT_FILE SRE-http will attempt to (exact or wildcard) match the request selector with one of the ASEL fields in these entries. HOST_NICK//) Optional. Used to identify "host specific" entries. If a HOST_NICK is present, then the entry is only used with requests to hosts having this HOST_NICK "host nickname". If a request is to a specified host (for which a HOST_NICK has been defined); then "host-specific" entries are checked first. NOTE: If the host is a "superceding host", then non-host specific entries are checked ONLY if no host-specific match is found. ASEL) Required. The ASEL should be a (possibly wildcarded) request selector SRE-http will compare ASEL against the request selector, and use the entry with the best-matching ASEL. RES_PRIVS) Optional. The RES_PRIVS should be a (space delimited) list. It can contain 2 forms of "resource privileges": ONE_OF -- the client has to have "one of" these ONE_OF privileges MUST_HAVE -- the client "must have" all of the MUST_HAVE privileges To specify a MUST_HAVE privilege, add a & character at the beginning. Otherwise, it is assumed to be a ONE_OF privilege (in other words, ONE_OF is the default form) For example, the list: SALMON &TROUT HALIBUT means that the client must have a TROUT privilege, as well as either a SALMON or HALIBUT privilege (note that the TROUT privilege is necessary but NOT sufficient!) There are a few special "ONE_OF" privileges: * YES and NO YES and * mean "allow everyone in" (given MUST_HAVE privs are ok) NO means "only superusers" Notes on RES_PRIVS: * If there are no ONE_OF conditions, it is assumed that the "ONE_OF conditions are automatically satisfied" (the same can be said if there are no MUST_HAVE conditions). * If a REALM is specified, and a realm-specific resource privilege list exists for this REALM, then it (the realm-specific resource privilege list) will be appended to the "selector specific" RES_PRIVS list (see the description of !REALM below for details). * If the combination of a RES_PRIVS list, and a "realm-specific resource privileges" list is empty (that is, neither is specified), then access IS allowed. That is (assuming you never use !REALM entries): RES_PRIVS=' ' is the same as RES_PRIVS='*' * If none of these entries matches the selector, and ALLOW_ACCESS is not equal to "YES", then access is NOT allowed (SUPERUSERS and INHOUSE users possibly excepted). * If the ADD_RESOURCE_NAME='YES', then the "action" portion of the request selector is added to the resource privilege list. * Caution: when including entries of the form: SECRETS/* ADMIN1 and NODIR_EXT='DIR', then a request generated by http://foo.bar.net/secrets will NOT match the SECRETS/* .. entry. * See ADDPRIVS.DOC for a discussion of how client's are granted transient privileges. PERM_LIST) Optional. The PERM_LIST is optional (there MUST be comma seperating the RES_PRIVS and the PERM_LIST) Permissions are used to modify how SRE-http processes the request. Permissions include: NO_SSI : Suppress server side includes. YES_SSI : Check HTML documents for server side includes (this overrides NO_SSI) NO_SSP : Suppress server side processing. NO_CODE : Suppress SELECT and INTERPRET CODE ssi-keyphrases. NO_CODE is a subset of NO_SSP (that is, if NO_SSP is present, then NO_CODE is irrelevant) CACHE : Always allow caching of this selector by proxies (and by SREPROXY) This does NOT enable caching by the GoServe cache. CACHE* : As above, but ALSO allow GoServe's caching of this selector. If the GoServe cache is not enabled, CACHE* and CACHE do the same thing. Note: if logon controls or access controls are in place, then by default caching is disabled. Use of CACHE or CACHE* allows one to override this default rule. NOCACHE: Do NOT cache this selector. NOCACHE overrides CACHE and CACHE*. It also overrides PROXY_CACHE settings, but does not override the cachable status of PUBLIC_URLs. PUT : Allow PUT method requests to "copy information to" the directory represented by this selector (also used by GET_URL and PUT_FILE facilities) DELETE : Allow DELETE method request to "delete" the file represented by this selector. NO_HTACCESS: Suppress the HTACCESS method. NO_ALIAS : Suppress SRE-http "aliasing." NO_VIRTUAL : Suppress virtual directory lookup. NO_POSTFILTER: Suppress post-filter processing (such as common-log auditing, and augmentation of the SRE-http RECORD_ALL file). The last three (NO_VIRTUAL, NO_ALIAS, and NO_POSTFILTER) are meant to be used to avoid unnecessary processing. Note that NO_VIRTUAL is ignored by CGI-BIN scripts and SRE-http addons (you can use the virtual directory's limitation_lists instead). REALM) Optional. (there must be a comma between the REALM and the PERM_LIST) The REALM is optional -- it identifies which "realm" this selector "belongs" to.. The REALM is displayed as a SEL-specific realm whenever SRE-http needs to "re prompt" the client for a new username/password (as when the user's first username/password did not contain sufficient privileges to access the selector). If you don't specify REALM: * If you've set the REALM_1ST_PRIV parameter (in SREFILTR.80) then the first resource privilege is used as the realm name * otherwise, the THE_REALM variable (set in INITFILT.80) is used Semi-Obsolete: Special !REALM entries in this file can be used to specify "realm specific resource privileges list" (see below for details). FAIL_FILE) Optional. (there must be a comma between the FAIL_FILE and the REALM). The FAIL_FILE (sometimes refered to as the ACCESS_FAILURE_FILE) is optional . If the client does not have sufficient privileges (as defined by the RES_PRIVS), then the FAIL_FILE is used as a "response file". Basically, the FAIL_FILE "overrides" the ACCESS_FAIL_FILE parameter that is set in INITFILT.80. Note that the FAIL_FILE should be one of: -1: If no access, do NOT ask for authorization. Useful when combined with "dynamic privileges" 0 or blank : use generic access_fail_file (or send an authorization response) filename.ext : a fully qualified file name. Actually, the ACCESS_FAIL_FILE parameter can suppress use of this FAIL_FILE -- see initfilt.doc for details. ADVOPT_FILE) Optional. (you must precede it with a comma) The ADVOPT_FILE is optional -- if you do specify it, SRE-http allows you to specify several selector-specific "advanced options", including: * customization of the response header, * execution of a rexx program before sending a file (sort of "mid-filter" hook), * suppression of SSI features (such as headers and footers) -- * sel specific mime type * string replacement (used with HTML documents) The ADVOPT_FILE should be a relative file name, though it may point to a subdirectory (it will be interpreted relative to the the SRE-http ADDON directory). For more details, see ADV_OPTS.DOC ------------------- 2.1.iii) Notes Semi-obsolete option: additional, REALM-specific, resource privileges We no longer recommend use of this option -- see section III (the selector-attributes documentation) for a better way to define "realms". Each realm can have associated with it a list of "realm specific resource privileges". If available, this (space delimited) list is added to the the RES_PRIVS list of all selectors that "belong" to this realm. The syntax of these special entries is: !REALM realm_name realm_privilege_list Note that realm_name should match a REALM specified in several (or one) of the sel-specific entries. See below for some examples of realm-specific resource privilege_lists. NOTE: Currently, these !realm entires are NOT host specific! Hence, on multi host systems we HIGHLY recommend using the host nickname as part of the realm_name (and, hence, in corresponding REALM fields). / and \ : They are treated the same (all / are converted to \) A Leading \ (or /) is stripped. ------------------- 2.1.iv) Examples Only superusers have access to the SYSTEM subdirectory SYSTEM\* NO Only inhouse and superusers have access to the PRIVATE directory PRIVATE\* INHOUSE Everyone has access to the PUBLIC\ directory, but documents in the public directory can not contain SELECT or INTERPRET CODE keyphrases. PUBLIC\* * , NO_CODE Requests, to the host with nickname SWEETSHOP, for selectors that match RECORDS/*, requires INHOUSE privileges SWEETSHOP// RECORDS/* INHOUSE , , ADMIN_REALM The client has to have "one of" VENUS,MARS, or MERCURY privlieges, and "must have" an EARTH privilege, to access the PLANETS/INNER directory. If the client does not have these privilegs, D:\WWW\NOPLANET.HTM is returned (given that ACCESS_FAIL_FILE<>0). PLANETS/INNER/* MERCURY VENUS &EARTH MARS , , , d:\www\NOPLANET.HTM Allow uploads and deletes in the Uploads directory UPLOADS/* * , DELETE PUT Wildcards all requests for getafile. Add a privilege list if you want to limit its use GETAFILE* These wildcard the message box facility. Add a privilege list if desired .. MESSAGE* !ASKMESS* Control access to the SECRET2 message box. All other message boxes are open to everyone with VIEWMESS privileges. !VIEWMESS?messbox=secret2* INHOUSE !VIEWMESS* VIEWMESSAGES Gives selectors pointing to the GUEST subdirectory (or virtual directory) a limited purview GUEST/* * , NO_SSI NO_SSP , GUEST_REALM Use the NEW.CTL "advanced options file" with all selectors that point to NEWSTUFF (and below). Note that there are no permissions specified, and no FAIL_FILE. NEWSTUFF/* * , , EXPERIMENTAL , , NEW.CTL Allow caching of GIF files in (or under) the IMG directory; and don't bother checking aliases or the virtual directories, and don't do postfilter stuff IMGS/*.GIF * , CACHE NO_ALIAS NO_VIRTUAL NO_POSTFILTER Let goserve cache GIF files in (or under) the IMG directory. This is especially useful if you have NOT checked the "call filter anyways" option of goserve (since if the filter is not called, then post filtering etc. will not be done). IMGS/*.GIF * , CACHE* Give access to a clients with a privilege of MARTIANS, IONIANS or one of the privileges in the "additional resource privilege" list associated with the SPACEMEN realm (see below), access to files in the STELLAR directory STELLAR/* MARTIANS IONIANS , , SPACEMEN This is a catchall: "for all other files, everyone has access" or, you can change the second * to whatever privilege list you want (i.e.; NO, to disallow all access) /* * 2.1.iv.a) Some !REALM examples Note that !REALM entries can appear in any order or location in this file, but there should only be one entry per realm_name. All selectors that belong to the REALM1 realm will have BIGFOOT and SASQUATCH added to their (possibly empty) RES_PRIVS list. That is, the client will be allowed access (to selectors with SEL-specific realm of REALM1) if they have a privilege of BIGFOOT or SASQUATCH (or one the entries in the sel-specific RES_PRIVS list). !REALM REALM1 BIGFOOT SASQUATCH The SPACEMEN realm has "additional resource privileges" of: VULCANS KLINGONS and FERENGI !REALM SPACEMEN VULCANS KLINGONS FERENGI Selectors in the SPACEMEN2 realm requires a FEDERATION privileges as well as "one of" the VULCANS KLINGONS or FERENGI (in addition to selector- specific privileges) !REALM SPACEMEN2 VULCANCS KLINGONS FERENGI &FEDERATION ------------------- 2.2. ALIASES.IN ALIASES.IN is used to specify internal and external redirection. 2.2.i)Introduction Aliases are used to modify and transform the request selector. This includes: Local redirection: Substituting for common "misspellings and abbreviations" Implementing searchable indices. Remote redirection: Redirecting requests for moved URLS Specifying "negotiable" resources (SEMI-OBSOLETE) Setting path for CGI-BIN scripts (SEMI-OBSOLETE) Transferring non-data-directory files. Note: the following descriptions can also be used for "host and port specific ALIASES.IN" files -- with the exception that the "HOST_NICK//" parameter should NOT be used in entries that appear in "host and port specific" files. ------------------- 2.2.ii) Structure of entries Each line is structured as: host_nickname// TARGET REPLACEMENT where host_nickname// is optional. Spaces should seperate these items. The TARGET should have NO embedded spaes. Note that in the TARGET, we convert / to \, and drop any leading / (or \). * Special feature: if a line ends with a ' ,' (a space, then a comma) the next line is treated as a continuation (with intervening spaces removed). SRE-http attempts to (exact or wildcard) match the request selector with each TARGET. ------------------- 2.2.iii. Notes * If a match is found, the request selector is replaced by the REPLACEMENT, with possible "wildcard substitution". * "Wildcard substitution" occurs only if a * appears in the REPLACEMENT and in the TARGET. When this occurs, and the request selector "wildcard" matches the TARGET, a textual substitution will occur in the REPLACEMENT. Specifically, the * in the REPLACEMENT will be removed, and the portion of the request selector "covered" by the * (in the TARGET) will be inserted in its place. Examples, given: Request selector: /CATS/A14.HTM and an alias entry with Target: /CATS/* Replacement: /SHOP1/PETS/FELINES/PUREBRED/* will yield: /SHOP1/PETS/FELINES/PUREBRED/A14.HTM Note that the A14.HTM in the Rquest Selector is "covered" by the * in the Target, and is then used to "replace" the * in the Replacement. * When specifying a "negotiable resource", the REPLACEMENT is optional ------------------- 2.2.iv. Some Examples i) Local redirection: Replace a "misspelling or abbreviation". Example: INDEX INDEX.HTM ii) Implementing searchable indices (using SRE-http's DOSEARCH utility) In this example, CONGRESS.DAT will be searched using the search list returned by the client TESTSRCH.HTM?* DOSEARCH?file=/congress.dat&searchfor=*&delim=$ If ROOTC/ is a virtual directory for C:\USERS\, this will search C:\USERS\JOES.LST LOOKUSER.HTM?* dosearch?file=/ROOTC/JOES.LST&searchfor=*&delim=0 iii) The next 4 examples perform "remote" redirectons. a) This (note use of a full URL, including the http://) causes a "temporary move" (http status code 302) redirection. YAH* http://www.yahoo.com/ b)Specifies the same thing, but the URL that follows need not be comletely specified (if the ip domain is left out, it is assumed to be to be back to your server.) Of course, to be safe one should always specify the full URL (complete with http://) WAH* !TEMP=www.yahoo.com/ c) A "permanent" move (http code 301) otherwise it's the same as example ii. ZAH* !MOVED=http://www.yahoo.com/ d) A "notification of moved resource" -- client recieves a document telling her the resource has been moved, with a link to its new location JOEDIR/CV.HTM !NOTIFY http://college.faraway.edu/FAC/JOE/CV.HTM iv) Specifying a "negotiable resource" To specify a "negotiable resource", just enter the selector that points to the resource, followed by the word !NEGOTIATE. If this match occurs, the TARGET (selector) is assumed to be a variant list, which will then be processed. Example: VARTEST/VAR1.LST !NEGOTIATE (note that REPLACEMENT is not specified; instead, the word !NEGOTIATE shoud appear) Alternatively, you can use a wildcarded "selector" and place the name of the variant-list file after the !NEGOTIATE. Example: MANUAL/* !NEGOTIATE MANUAL/MANUALS.LST would cause the "variant list" in MANUAL/MANUALS.LST to be used for all selectors that match MANUAL/* Caution: If use this "wildcarded construct", the variant list MUST contain an appropriate PATTERN: entry. v) Specifying location of CGI-BIN script. (semi-obsolete: use of a "location" before the /cgi-bin/ is now recommended). Example: SCRIPT10 d:\progs\new would instruct SRE-http to look for SCRIPT10 in d:\PROGS\NEW (rather then the default, "cgi_bin_dir", script directory) vi) A host specific entry (only applies to requests to hosts with a nickname of ZOO) Example: ZOO// TIGERS ANIMALS/FELINES/TIGERS.HTM would only apply to request to a "host" with a ZOO host nickname. vii) Transfering files from anywhere (Semi-obsolete -- virtual directories are now recommended) Example: GETMAP?* !TRANSFER=e:\MAPS\* Note that this example assumes that 1 argument is appended to the selector (say by a FORM of type GET) ------------------- 2.2.v. Some cautions * A CAUTION regarding unwanted aliasing: Unless you explicitly want to "alias" actual files, directories, or "server side program" names... we HIGHLY RECOMMEND that all entries in this file have "targets" that do NOT MATCH pre-existing files, directories, or "actions". {and be especially careful if you are using any wildcard matches) * A CAUTION on local redirection and partial urls: When using aliases for "local redirection", URL resolution by the client's browser may have unexpected consequences. See the discussion of "local vs remote redirection" in INITFILT.DOC for details! ------------------- 2.3. PUBURLS.IN PUBURLS.IN is used to specify publically accessible" resources. 2.3.i) Introduction PUBURLS.IN is used to identify public-urls: which are defined as resources for which access (and logon) controls are not imposed. * See PUBURLS.DOC for a complete description of public-urls. 2.3.ii) Syntax The basic syntax of entries is: host_nickname// candidate_sel anoption filename where: host_nickname is an (optional) host nickname candidate_sel is compared against the request selector anoption can be: LITERAL LITERAL_NORECORD or NORECORD filename is a fully qualified file name (with possible * "wildcard characters") (anoption and filename are both optional) 2.3.iii) Examples INDEX.HTM MAPS/* STORE/AD1.HTM LITERAL STORE/*.GIF NORECORD PICTURE/HELLO.GIF LITERAL_NORECORD D:\PICTS\HELLO.GIF ZOO// HOURS.HTM LITERAL Notes * LITERAL_NORECORD implies "let goserve cache this" (assuming the goserve cache is enabled) * Requests to host ONLY match host specific entries, That is, non-host specific entries WILL NOT match requests to "hosts" (for which a host_nickname is defined). * Public URLS with a LITERAL_NORECORD attribute may be cached by the GoServe cache. ------------------- 2.4. VIRTUAL.IN VIRTUAL.IN is used to specify virtual directories. 2.4.i) Introduction Virtual directories are used to allow access to files not in a default directory. The typical use is to allow requests for documents to be in a subdirectory NOT under the "GoServe data directory". VIRTUAL.IN can also be for several other reasons, including: specifying the location of a cgi-bin script specifying the location of an sre-http add-on specifying where an uploaded file should be placed Lastly, for some cases, virtual directories can be used to allow server mediated access to files on other (remote) servers. ------------------- 2.4.ii) Basic structure of entries Each line in VIRTUAL.IN should have the following structure: host_nickname// SEL_fragment TARGET limitation_list , username:pwd where: * host_nickname// is optional * SEL_fragment is the "beginning portion" of a request selector * TARGET can be a (local) fully qualified directory or a (remote) fully specified URL * the [optional] limitation_list is used to limit the applicability of the entry. If present, it should be a spaced delimited list. Its use is described below. * the [optional] username:password is ONLY used for remote (http://) directories ------------------- 2.4.iii) How virtual directories work The SEL_fragment is compared to the beginning of the request selector (the selector). If an "abbreviation" match occurs, the "fragment" is removed from the "request selector" and replaced with either the (local) target "directory" OR the (remote) target "URL". The limitation_list (if present) is used to control which entries are used, based on whether the request is asking for a document, a server side program, or an upload (see section V below for details). [If this is confusing, the examples in 2.4.vii should help.] ------------------- 2.4.iv) General Notes * If no match is found, a "default directory" is used. In the typical case of a document request on a single host server, the default directory is the GoServe data directory. * If the host is a "superceding host", then non-host specific entries are checked ONLY if no host-specific match is found. * The limitation list can be used to limit the "scope" of the entry. If there is no limitation_list, the entry will be used for all requests. * An asterisk (*) at the end of directory name means "allow access to subdirectories". Note that you should NOT place an asterisk at the end of the SEL_FRAGMENT * Leading and trailing slashes in the SEL_fragment are ignored, and / and \ are treated equivalently. Similarly, trailing slashes in the TARGET directory are ignored. Thus, the following are all equivalent: foobar1/ d:\foobar\* foobar1 d:\foobar* \foobar1\ d:\foobar* * If a Drive is not specified in the TARGET (local) directory, the drive that SRE-http is installed on will be used. * WARNING: The use of "REMOTE urls" is ONLY supported for document requests. It is NOT supported for "server side include" files, such as specified in the INCLUDE and INTERPRET SSI keyphrases. Nor is it supported for server side programs, or upload, requests. * CAUTION: The NO_VIRTUAL permission (in ACCESS.IN) suppresses the use of VIRTUAL directories. That is, when a selector matches an ACCESS.IN entry that contains a NO_VIRTUAL permssion, virtual directory information will NOT be examined! ------------------- 2.4.v) Using the limitation_list The limitation_list is used to limit the scope of a virtual directory entry. For example, you may wish to have some virtual directories apply only to document requests, and some only to upload requests. The limitation_list (if present) should contain any mixture of the following special keywords: !UPLOAD, !CGI-BIN, !ADDONS, and !HTML. !HTML --- use this entry for document requests !CGI-BIN --- use this entry for cgi-bin requests !ADDONS --- use this entry for sre-http addons !UPLOAD --- use this entry for file uploads Note that more than one of these keywords can appear in this "space delimited" limitation list. Including all four entries is the same as not having a limitation list: the entry will be used for all requests. For example: scdemo d:\netdata\macros\scdemo !cgi-bin scdemo d:\netdata\html\scdemo !html The first entry will be used when a request for a cgi-bin script arrives (i.e.; scdemo/cgi-bin/scinit.cmd The second will be used for document requests (i.e.; scdemo/foo1.htm) ------------------- 2.4.vi) Specifying remote "target urls" i) the http:// MUST be present (otherwise SRE-http assumes you are referring to a local directory name) ii) conversion of / does NOT occur for these entries iii) the trailing * option is supported iv) This is NOT a redirect! Rather, SRE-Http will use socket calls to retrieve the resources represented by this URL (on a remote server), strip out the response headers, and treat it as if it came from a local directory. vi) If you specify a username & password (after a comma), a BASIC authorization request header will be added with this username & password. Otherwise, the client's username & password is used (if it is available) ------------------- 2.4.vii) Match precedence Unlike most other SRE-http files, match precedence for virtual directories is based on "abbreviation" matching, not "best matching". That is, * wildcards should not be in the SEL_FRAGMENT. Instead, SRE-Http simply uses the longest SEL_FRAGMENT that is an "abbreviation" for the request selector. ------------------- 2.4.viii) Examples Two examples of "subdirectory access is allowed": (if a selector of: /LOCAL/PROJECTS/BOB/PLANE.HTM is recieved, the file returned will be D:\WORK\PROJECTS\BOB\PLANE.HTM) LOCAL/PROJECTS D:\WORK\PROJECTS* Note: If the * is removed, /LOCAL/PROJECTS/BOB/PLANE.HTM would generate a "no access allowed" error (since access to subdirectory BOB, under WORK\PROJECTS, would not be allowed). (D:\work, with subdirectory access allowed) D\work D:\WORK\* Two examples of "no subdirectory allowed access" (a selector of STATES/AG.HTM would be valid,and would return D:\USA\MAINE\AG.HTM) STATES D:\USA\MAINE (temp on C:, but NO subdirectory access) CTEMP C:\temp Three examples of a remote target URL: (a selector of SERVER2/CANADA.HTM will cause SRE-Http to request /support1/canada.htm from pc2.myorg.net) SERVER2 http://pc2.myorg.net/support1/ (get from the EXPORT directory (and directories underneath EXPORT) on the server at www.ours.org) SITE2 http://www.ours.org/export/* (remote request to a server, using your server's username:password) special\ http://server2.hissite.org/grate/stuff/* , specialask:ernie An example of a host-specific entry: (requests, to hosts with host_nickname of SWEETSHOP, that have selectors beginning with CANDY refer to files in E:\STORE1\PRODUCTS\CANDY and its subdirectories). SWEETSHOP// CANDY E:\STORE1\PRODUCTS\CANDY\* Two examples of limitation lists: (the !addons signals that the ACTION2 "virtual directory" will only be used for requests for sre-http add-ons). ACTION2 e:\programs\task1 !addons For example: /action2/getafile?dir=foodir1 E:\programs\task1\GETAFILE.CMD is executed (as an SRE-Http add-on) /action2/gogo.htm D:\www\action2\gogo.htm would be returned (assuming that the GoServe data directory is D:\www) (the D:\project1 directory (and subdirectories) contain html documents, and sre-http add-on procedures) project1 d:\project1* !HTML !ADDONS ------------------- 3. Specifying selector-specific attributes using realms ATTRIBS.CFG is used to set selector-specific attributes, using a "realm-architecture". In addition, ATTRIBS.CFG can be used to specify user/passwords, and to specify replacement strings. ------------------- 3.1.i)Introduction ATTRIBS.CFG supplements (or replaces) the several user-configurable ".IN" files used by SRE-http. These are ACCESS.IN, ALIASES.IN, PUBURLS.IN, REPSTRGTS.IN, USERS.IN, and VIRTUAL.IN (note that prior to ver 1.3f, ACCESS.IN was named ALL_FILE.CTL). Four of these ".IN" files (ACCESS.IN, ALIASES.IN, PUBURLS.IN, and VIRTUAL.IN) are used to set "selector-specific" attributes (see section 2. for the details). ATTRIBS.CFG integrates these four files using a "realm-architecture"; an architecture that matches how the WWW is organized, and should be easier to work with. The basic idea of this "realm-architecture" is: 1) a server's resources (documents, images, scripts, etc.) can be sorted into "realms" 2) each of these "realms" may have numerous "sub-realms" 3) access to your server's resources can be defined on a "realm" specific basis -- a given client can be granted access to resources in only a subset of your server's "realms". 4) other attributes, such as redirection instructions, and customization of how sre-http will process the request, can be defined on a realm, or subrealm, basis 5) A realm, or a sub-realm, can contain: *) one resource (a single selector), or *) set of similarly named resources (a single, wildcarded selector), or *) several similarly named resources ------------------- 3.1.ii) Syntax Entries in ATTRIBS.CFG consist of a block of several "mime-like" lines, ending with a blank line. Each "mime-like" line has the following structure: action: options Briefly, the following lists (in alphabetical order) the available "actions." advopt_file -- specify an advanced options file failure -- specify an access failure file host -- specify which host this entry is to be used for include -- include a host/port specific set of entries limitlist -- specify a limitation list (used with redirect: dir=) option -- specify an advanced option permissons -- specify sre-http "permissions" port -- specify which server port this entry is to be used for privs -- specify client privileges (used with USER) pwd -- specify a password (used with USER) realm -- the realm (subrealm) name of this entry (REQIURED) redirect -- url redirection, or virtual directory assignment requires -- resources privileges needed for access rule -- selectors (possibly *'ed) to assign to this realm (REQUIRED) replace -- specify a replacement variable with -- specify a replacement string (used with REPLACE) user -- specify a user name Note that a "block" must contain one of: INCLUDE -- an "include file" block REALM and RULE -- a "realm definition" REPLACE and WITH -- a "replacement rule USER and PWD -- a username/password The following describes these actions in greater detail: advopt_file: Specify an "advanced" options file. Syntax: advopt_file: file_name file_name should be a relative file name (it will relative to the SRE-http ADDON directory). For more details on advanced options files, please see section 2.1.ii, or see ADV_OPTS.DOC Notes: * advopt_file complements OPTION: * you can use ADV as an abbreviation for ADVOPT_FILE failure: Specify an "access failure file" Syntax: failure: file_name file_name should be a fully qualified file name, or a special code -- see the discussion of FAIL_FILE in section 2.1.ii for further discussion of access failure files. host: The "host nickname" of the host this entry applies to Syntax: host: host_nickname If not specified, the entry will be used for all requests -- such entries are assumed to refer to a "default" host. For redirect and requires: If the host is a "superceding host", then non-host specific entries are checked ONLY if no host-specific match is found. Note: If you are running a single host site, you do NOT need to use host: include: Include a file of entries, to be assigned to a single host and port. Syntax: include: file_name file_name should be a fully qualified filename The include: action is special -- when it appears in an entry, only host: or port: actions are used, all other actions are ignored. Files "included" should have the same structure as ATTRIBS.CFG, with one exception -- host: and port: actions should not be included (actually, they can be included, but they will be ignored). Basically, the main purpose for include: is to allow each "host" to have its own configuration file. This provides an alternative to the use of host: (and port:) actions. Note: you can also use CFGLIST.CFG to specify "host & port specific ATTRIBS entries". limitlist: Specify a "limitation list". This limitation list is used with redirect: dir=. There are four valid values that can appear in the limitation list: !HTML, !CGI-BIN, !ADDONS, and !UPLOAD. See section 2.4.v for the details on limitation lists. Example: limitlist: !HTML Note: not specifying a limitlist is the same as specifying all four of these values. option: Specify an advanced option Syntax: option: an_advanced_option The advanced_option can be any of the SRE-http advanced options, as described in ADV_OPTS.DOC. You can specify multiple option: lines -- with one option per line. Examples: option: set fix_expire 0.5 option: ssi_no_footer option: REPLACE_RULES=== Note that option: complements advopt_file: permissions: Specify the "permissions" to use for selectors that belong to this realm. Syntax: permisson: permission_list permission_list is a spaced delimited list of SRE-http "permissions". Currently available permissions include: NO_SSI YES_SSI NO_SSP NO_CODE CACHE CACHE* PUT DELETE NO_HTACCESS NO_ALIAS NO_VIRTUAL NO_POSTFILTER For details on how to use permissions, see the discussion of PERM_LIST in section 2.1.ii Notes: * Sub-realms can inherit the PERMISSIONS values of their parent subrealm (or grandparent, etc.). * The NO_POSTFILTER permission, when used with a PUBLIC realm, is equivalent to specifying a NORECORD (or LITERAL_NORECORD) attribute in a PUBURLS.IN entry (see 2.3.iii for details) port: Specify which port this entry applies to. Syntax: port: nnn where nnn is the port number your server is running on. If a port: entry does not appear, the default (80) is assumed. If you always run your web server on the standard http port (port 80), then you will never need to use port: privs: Specify user (client) privileges Syntax: privs: privlist Specify a set of "client privileges" to be assigned to a user. You MUST also specify a username and a password (using the user: and pwd: actions). Privlist is a space delimited list of privileges. * "secret" privileges should start with a ?. * see USERS.DOC for details on replacement rules. * you can specify host and port usernames (using the HOST: and PORT: actions) pwd: Specify a password Syntax: pwd: a_password Specify a password for a user of site. You MUST also specify a username (using the user: action). * a_password may be case sensitive (depending on the authorization mechanism used by the client) * the PRIVS: action is also used with user: and pwd: * see USERS.DOC for details on replacement rules. * you can specify host and port usernames (using the HOST: and PORT: actions) replace: xxx Specify a replacement rule. Syntax: replace: xxx Replacement rules are used with server side includes. Notes: * replace MUST be used in conjunction with a WITH: action * see REPSTRGS.DOC for details on replacement rules. * you can specify host and port specific replacement rules (using the HOST: and PORT: actions) * spaces are stripped from xxx. In other words: replace: myvar1 and replace:myvar1 and replace: myvar1 are equivalent. realm: The realm_name, or realm_name plus subrealm_name, idenfies this "entry". Syntax: realm: realm_name C or realm: realm_name.subrealm_name C Notes: * PUBLIC is a "special" realm_name -- it signifies "open access" resources * In order to define a subrealm, you MUST define its "main realm" * Subrealms can be more then 1 deep. Thus, FOO.BAR.UP is legitimate. * When SRE-http returns an authorization request to a client, it will use the "main realm". For example, if a request matches R1.S3.T4, then R1 is the realm reported to the client. * the C is optional. If present, this realm (or realm.subrealm) is a "superceding" realm. Otherwise, it is a normal realm (see section 3.1.v for a discussion of superceding realms) requires: Identify the resource privileges a client needs to access this realm. Syntax: requires: priv_list priv_list is a space delimited list of "resource privileges". Note that subrealms MUST inherit the "resource privileges" of their main realm -- you can not specify different sets of resource privileges for different subrealms under the same "main realm" Thus: requires can NOT be used in subrealm entries! For further discussion of "resource privileges", see the discussion of RES_PRIVS in section 2.1.ii. Notes: * For the PUBLIC realm, REQUIRES is ignored (an implicit REQUIRES: * is used). * Reiterating: Sub-realms inherit the REQUIRES values of their parent realm. You can NOT set sub-realm specific REQURES redirect: Redirect or redefine a request Syntax redirect: mode = xxx mode can be: dir -- a "virtual directory". XXX is a fully qualified directory. It can contain one wildcard at the end. For more details, please see the dicussion of virtual directories in section 2.4. internal -- "an alias". XXX is a selector, which can contain multiple wildcard (*) characters. For more details, please see the discussion of "local redirection" in section 2.2. literal -- a "literal" transfer. XXX is a fully qualified file name, which can contain multiple wildcard (*) characters. When used with a PUBLIC realm, literal is equivalent to using a LITERAL (or LITERAL_NORECORD) modifier in a PUBURLS.IN entry (see section 2.3.iii) Otherwise, LITERAL is equivalent to using a !TRANSFER=xxx in an ALIASES.IN entry (see section 2.2.iv for the details) negotiate -- identifies a "negotiable resource". This resource contains content-negotiation information. XXX is usually empty, but in certain cases it can point to a special listing file. See 2.2.iv for details on content-negotiation. perm -- "a permanent redirection" (301). XXX is a local or fully qualified URI. It may contain mulitple wildcards. For more details, please see the discussion of external redirection in section 2.2. temp -- "a temporary redirection" (302). XXX is a local or fully qualified URI. It may contain mulitple wildcards For more details, please see the discussion of external redirection in section 2.2. Redirect notes: * There can be at most ONE (or none) redirect: actions per entry. * The url in a redirect: perm (or redirect: temp) can be local, or it can be fully specified (starting with http://). * The following synonyms can be also be used: ALIAS: xxx instead of REDIRECT: INTERNAL = xxx LITERAL: xxx instead of REDIRECT: LITERAL= xxx VIRTUAL: xxx instead of REDIRECT: DIR=xxx MOVE: xxx instead of REDIRECT: PERM=xxx TEMPMOVE: xxx instead of REDIRECT: TEMP = xxx rule: Specify matching rules for idenfitying selectors that belong to this realm. Syntax: rule: a_selector a_selector may contain multiple wildcard (*) characters. Some simple examples include: rule: /xxx/yyy/foo.htm rule: /zzz/* Note that one can define rule: several times within a single entry -- multiple rule actions are cumulative. Thus, several different "selector matching rules" can be used to identify resources belonging to a given realm (or to a given subrealm) Please see section 1.1 for a discussion of how SRE-http uses wildcards when "matching selectors to a rule". user: Specify a user. Syntax: user: username Specify a username for this site. You MUST also specify a password (using the pwd: action). * the PRIVS: action is also used with user: and pwd: * see USERS.DOC for details on replacement rules. * you can specify host and port usernames (using the HOST: and PORT: actions) with: Specify the string used in a replacement rule. Syntax: with: a string Replacement rules are used with server side includes. "A string" can be a string of any length; it can contain html entities and spaces. Notes: * replace MUST be used in conjunction with a REPLACE: action * see REPSTRGS.DOC for details on replacement rules. * you can specify host and port specific replacement rules (using the HOST: and PORT: actions) ------------------- 3.1.iii) Limitations The following "selector-specific" attributes can NOT be set using ATTRIBS.CFG, but can be set using one of the ".IN" files (filenames in parenthesis indicate where these can be set): i) location of a cgi-bin script (ALIASES.IN) ii) specifying a "remote" virtual directory (VIRTUAL.IN) iii) multi-line replacements (REPSTRGS.IN) ------------------- 3.1.iv) Some notes on using realms and subrealms Underlying the logic of the "realm" and "subrealm" architecture is that browsers store authorization information by "realm within a host" (host being a named IP address). * When SRE-http returns an authorization request to a client, it will use the "main realm". For example, if a request matches R1.S3.T4, then R1 is the realm reported to the client. SRE-http mirrors this fact by forcing all "subrealms" of a "realm" to have the same set of "resource privileges". Thus, sub-realms are used primarily to specify other attributes, such as redirections and permissions. In particular, permissions are defined recursively; if no permissions were granted a subrealm, it will search "down the realm/sub-realm tree" for a set of permissions. For example, suppose the FOO, FOO.BAR, and FOO.BAR.UP have been defined. FOO is the "main realm", and FOO.BAR and FOO.BAR.UP are subrealms of FOO. Suppose that FOO was defined with no permissions, FOO.BAR with the NO_SSI and NO_VIRTUAL permissions, and FOO.BAR.UP with no permissions. Then, FOO.BAR.UP will "inherit" the permissions of FOO.BAR (in this case, NO_SSI and NO_VIRTUAL) However, FOO will NOT "inherit" these permissions, since FOO is the parent of FOO.BAR. Note that "redirections", "failure files", and "advanced options" are NOT inherited -- you have to explicitly define them when needed. One useful trick is to have a "dummy" realm entry, within which you define the resource privileges, and a set of sub-realms where you actually specify the selectors (this is akin to using a !REALM entry in ACCESS.IN). For example: Realm: MYREALM Rule: 0 Requires: priva privd privq Realm: Myrealm.set1 Rule: foo/* etc. Note the effect of "Rule: 0 " -- no selector will match this rule; but the resource privileges (specified in the REQUIRES: line) will be inherited by MYREALM.SET1, etc. 3.1.v) Some notes on superceding realms The set of "superceding realms" (and "superceding subrealms") supercede all other "selector specific" information. SRE-http will first try and match a selector to the rules for superceding realms. If a match is found (using the usual "best matching" rules), the information for this realm or subrealm is used. That is, non-superceding realms and subrealms, and entries from the .IN files, are NOT checked! The successful use of superceding realms means that rather then calling four separate daemons (for public url info, access control info, alias info, and virtual directory info), only one daemon is called. Since this reduces queue and semaphore related overhead, and reduces the number of "best match searchs" from four to one, throughput should be improved. However, the fact that public url info, access control info, alias info, and virtual directory info are independently specified allows a certain dynamism. For example, an alias can change a selector, and this changed selector can then match a virtual directory entry. Since such dynamics would either greatly complicate, (or render useless) this one lookup, the use of this "one daemon" is limited to information specified in "superceding realms". Given that there are more then zero superceding realms defined, SRE-http will: a) compare the selector to the rules belonding to the set of superceding realms (and superceding subrealms). b) if any match it found, use the "public url, etc." information specified in the "best matching" superceding realm (or superceding subrealm). c) if no match is found, check the rest of the selector specific entries (that is, check all non-superceding realms specified in ATTRIBS.CFG, and all the entries in the PUBURLS.IN, etc. files). In other words (in a fashion similar to superceding hosts), a match to a superceding realm "trumps" all other (possibly better) matches in non- superceding realms (and in the .IN files). This does reduce the dynamism of sre-http -- since realm definitions are more constrained then definitions made in the .IN files. For example, the preceding example of "virtual directory from a modified selector" can not be implemented within a single realm. In addition, if there is no match to a "superceding realm", the time required to search the superceding realms confers no benefit (that is, it worsens throughput). . Therefore, it is recommended that... ** if you use superceding realms, use them as much as possible ** (which implies careful migration of information from the .IN files to ATTRIBS.CFG). Notes: * if no superceding realms are defined, then this daemon is not called -- hence non-use of this feature should have minimal impact. However, you can fully disable the use of superceding realms by setting NO_SUPERCEDING_REALMS=1 (in SREFMON.CMD) -- this reduces extra processing even more then defining no superceding realms. * the use of superceding realms is orthogonal to the use of superceding hosts; you need not worry about perverse interactions. * when the above description mentions the .IN files and the ATTRIBS.CFG file, it also implies "host specific" versions of these files. * NOT all realms defined in ATTRIBS.CFG are superceding. * Caution: In most cases the rules for a superceding realm will always be used in preference to other rules. However, certain lookups (such as some virtual directory lookups by addons, and PUB_URL lookups after a GoServe cache hit) do not give this special treatment to superceding realms. Therefore, it is safest to structure your realm rules so that selectors would match superceding realms even if they (the realms) weren't superceding. * A sub realm may be a superceding "subrealm" even if its parent realm is non-superceding (and vice versa). ------------------- 3.1.vi) Some examples: realm: r1 rule: blendgif.htm mkgiftxt.htm redirect: moved=http://www.srehttp.org/apps/ realm: r2 rule: temp/* redirect: dir=h:\temp\* options: set fix_expire .5 realm: public rule: pubfiles/* realm: public.1 rule: morepubfiles/* permissions: no_postfilter redirect: literal=f:\pubs\* realm: r2 C host: danny requires: * rule: temp/* redirect: dir=f:\temp\* limitlist: !HTML !ADDON ; note:redirect: sel= is synonymous with redirect: internal= realm: magic port: 8080 rule: foo/* redirect: sel=foobar/* realm: send1 rule: scores/yankees literal: e:\baseball\yanks.txt realm: r2.3 host: danny rule: yahoo redirect: move = http://www.yahoo.com realm: r3 rule: *srehttp.faq realm: r3.a C rule: srehttp_faq redirect: internal=/samples/srehttp.faq permissions: yes_ssi realm: r4 rule: config2.* requires: superuser permissions: no_aliase no_dogs redirect: temp=http:/www.srehttp.org/config2.* realm: r5.a.1 rule: /inhouse/foobar.htm permissions: no_ssi realm:r4.b rule: config3.* advanced: foo.ctl permissions: no_virtual option: ssi_no_header option: ssi_no_footer realm:r4.a.2 rule: config4.* realm: manual rule: /manual/* negotiate: mans/manual1.lst realm: intr rule: intro.txt negotiate: option: set content_md5 1 realm r5 rule: /inhouse/* requires: inhouse host: goons include: d:\goserve\cfgs\goon2,cfg user: dan1 pwd: wow privs: a1 a2 a1a host: _!forest user: joe2 pwd: me1 privs: a1a a2a replace: contactme with: this is the default contact host: _!forest replace: contactme with: this is the contact for the forest site