SREhttp/2 Manual|| SSIs|| SSIcache || Edit SSI_VARS.CFG SSI_VARS

## SREhttp/2: Defining Server Side Include Variables SREhttp/2 allows you to define several kinds of string variables that can be used in HTML documents subject to Server Side Includes. These variables are defined in the `SSI_VARS.CFG` configuration file(s).

Notes: | The SSI_VARS.CFG files (like all SREhttp/2 configuration files) are text files SREhttp/2 uses a default SSI_VARS.CFG file (typically located in the SREHTTP2\CFG directory). SREhttp/2 also uses host-specific versions of SSI_VARS.CFG (typically located in subdirectories under the SREHTTP2\CFG directory) (see HOSTDATA.HTM for more details on SREhttp/2's `host-specific parameter files`). You can use the SREhttp/2 configurator to modify parameters in any of the SSI_VARS.CFG files.

#### Basic Syntax

SSI_VARS.CFG consists of one-line entries. Each entry has the form:
`name new_string`
where

`name` | The `name` should be a short variable name with no embedded spaces. There are 3 reserved variable names: `HEADER, FOOTER,` and `REPLACE` All other names refer to variables used in `<!-- REPLACE xx -->` SSI keyphrases.
`new_string` | The new string to use. The interpretation of new string depends on the `name`.

`name` can refer to one of the following types of variables:

1. `<!-- REPLACE name -->` SSI (server side include) keyphrases.
2. Automatic HEADER and FOOTER insertion
3. Replacement-rules
4. Lifespan of hit-cache entries

<!-- REPLACE name --> SSI keyphrases.
  The `new_string` should be a one-line string (of arbitrary length) to be used when the corresponding `<!-- REPLACE name -->` SSI keyphrase is encountered (in an HTML document subject to server side includes).

  Example:
  `PHONEME Contact Joe for more info!`
  When a
  `<!-- REPLACE PHONEME -->`
  occurs in your HTML file, it is replaced by,
  `Contact Joe for more info!`

  - `newstring` may contain up to nine %n (n=1,2,..,or 9) " argument placeholders.
    These are used when a
    `<!-- REPLACE xxx var1 var2 ...var9 >` is found
    Example:
    `ANNOUNCE1 Today's special is: %1`
    when your html document contains:
    `<-- REPLACE ANNOUNCE1 Apples -->`
    then the following is used:
    `Today's special is: Apples`

  - If you define mulltiple lines with the same name, the values will be concatenated.
    Example:

                MYADDRESS   My address is: <br>
                MYADDRESS   1800 M St NW. <br>
                MYADDRESS    Washington, DC. 20035 <br>

    Note the addition of the <br> element -- HTML ignores CRLFs!

  - The `name` may contain dots (see examples below)

  - You can use the REPLACE selector-specific SSI-suppression option to suppress use of <!-- REPLACE xxx --> keyphrases.
  - You can use `SREH2_VALUE(label,,hostnickname)` to look these values up, on a host-specific basis (use `DEFAULT` as hostnickname to lookup the default (non-host-specific) values).

HEADER and FOOTER
  The new_string is inserted as a HEADER (or FOOTER).

  HEADERs are inserted after the (first) <BODY> statement in an HTML document.
  FOOTERS are inserted before the (last) </BODY> statement in an HTML document
  If the document lacks a <BODY> or a </BODY>, then the HEADER (or FOOTER) will not be used.

  - If you define mulltiple `HEADER` or `FOOTER` entries, the values will be concatenated.
    Example:

                FOOTER  Contact info: <br>
                FOOTER  <A href="mailto:hostmaster@foo.net">The HostMaster</A>

  - You can use the HEADER and FOOTER SSI-suppresion selector-specific-options to suppress insertion of headers and footers.

Replacement rules
  `REPLACE` is used to define global replacement rules.

  Global replacement rules are used to perform textual substituion on HTML documents subject to server side includes. Although only attempted on these `SSI` HTML documents, the `REPLACE` entries are not `server side includes`. Rather, they are textual replacements that occur throughout the document, regardless of the placement of HTML elements.

  Basically, REPLACE can be useful as a way of changing values across a wide range of documents (they emulate style sheets), or as a shorthand for longer actions.

  Each `REPLACE` entry should have the syntax:
  `REPLACE old_string==newstring`
  which means all occurences of old_string will be replaced by newstring.

  #### Notes:

  - `==` is used to divide the old and new strings.
  - spaces are not stripped from `newstring`.
    Spaces are stripped from the beginning of `old_string`
    Option: To includes leading spaces at the start of `old_string`, start `old_string` with `==`.
    The `==` will be stripped and the leading spaces will be retained.
    Example: `replace == ABC ==, ABC,`
    Thus:

                replace $x==THIS is X
             will have different effects then:
                replace == $x== THIS is X

    (the latter requires a space before the x, and will add a space before the `THIS`)
  - the match of `old_string` is case insensitive; but the `newstring` case will be maintained.
  - Not only will the original document be subject to `REPLACE` rules, so will all subsequent server side includes.
  - To specify an == in a new or old string, use URL-encoding (`==` is `%2b%2b`).
    Note that you can specify = by using a single = sign.
  - If any selector-specific REPLACE rules are defined they will be used instead of these `host-specific REPLACE rules`.
  - You can use the REPLACE_RULES selector-specific SSI-suppression option to suppress use of <!-- REPLACE xxx --> keyphrases.
  - Multiple lines starting with `REPLACE` rules define a set of replacement rules. Hence, replacement_rules can not span multiple lines.
  - Example:

           REPLACE ${==<-- $ customiz
           REPLACE }==  -->

    This will transform
    `Customization is ${set1.var1}`
    into
    `Customization is <!-- $ customiz set1.var1 -->`

Lifespan of Hit Cache entries
  The `hit cache` is used by the `<!-- Replace HITS -->` SSI keyphrase. In particular, it used to suppress augmentation of a counter when a resource is read repetitively by the same client. That is, if a client reloads a URI several times in a few minutes, then the Hit Cache will prevent this hit-counter from being augmented.

  You can specify a lifespan in seconds, by setting the !HIT_DURATION variable (make sure to start with the !). If a request, by this client for this URI, has occurred within the last !HIT_DURATION seconds, then the hit counter will not be incremented (the current value of the hit counter will be returned).

  Set this to 0 to disable this option (in which case all requests for the resource will cause the counter to increment).

  Example:

         !HIT_DURATION 20

  means augment HIT counter only if most recent request from this client was more then 20 seconds ago

  #### Notes

  - `hit-cache` uses the client's IP address when checking how recently the client requested this resource. When multiple client's share a single IP address (say, when they lie behind a proxy server), use of this `hit-cache` will inappropriately suppress augmentation.
  - `hit-cache` tracks up to 250 URIs. To change this limit, see the `num_hit_track` parameter in `SREH2INI.RXX`.