home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / srev13h.zip / caching.doc < prev    next >
Text File  |  2001-03-27  |  14KB  |  328 lines
  1. 27 June 1999: SRE-http and caching.
  2.  
  3. SRE-http ver 1.3h supports several forms of caching.  This document outlines
  4. what levels of caching may apply to  a request, and what you can do
  5. to increase (or decrease) the extent to which caches answer requests.
  6.  
  7. Hint: The appendix discusses how to configure the "cache relevant"
  8.       response headers used by SRE-http.
  9.  
  10.  
  11. There are several different sorts of caches that may apply. In decreasing 
  12. universality these include:
  13.  
  14. 1) Proxy server caches.
  15.    For purposes of this discussion, a "proxy server" is any intermediate
  16.    site, somewhere on the web, that may handle a request issued by a client.  
  17.    These sites may store responses, and use these cached responses the next
  18.    time the same request is recieved. When such a stored response is used,
  19.    the origin server is typically not contacted (the origin server does not
  20.    know that the proxy delivered content to a client).
  21.  
  22.       ** Perhaps the principal advantage of http/1.1 (over http/1.0) is the 
  23.       ** attention given to making the web proxy-cache friendly.
  24.    
  25.    The appendix discusses how to configure the response headers used by
  26.    SRE-http to "talk to proxy servers".
  27.    
  28.         
  29. 2) The GoServe cache.
  30.    The GoServe cache consists of a list that matches selectors (the local
  31.    portion of a URI) to filenames. When a request for the same selector
  32.    arrives, GoServe can resolve the request by sending the matched file
  33.    (and a few http/1.0 response headers).  As an option, the GoServe cache
  34.    can "run the filter anyways", which allows the filter to perform post-filter
  35.    actions (such as auditing).
  36.  
  37. 3) The SREPROXY cache.
  38.    SREPROXY is a front-end to SRE-http.  SREPROXY maintains a cache that matches
  39.    selectors to files. These files may be temporary files (say, as generated
  40.    by adding SSI's to an HTML document). In addition, SREPROXY can resolve a 
  41.    few "dynamic" SSIs (such as the current time), and can do a limited amount
  42.    of access control.
  43.  
  44.  
  45. 4) The SSI and !DIR caches.
  46.    SREFILTR (the main filter) maintains a cache for SSI documents (that contains
  47.    "partially compiled" server side includes) and a cache for !DIR requests 
  48.    (that contains directory listing).  These are used when a matching selector 
  49.    is recieved. Note that the SSI cache is often times used as a base to which 
  50.    dynamic SSIs are added; where "dynamic SSIs" refers to information that 
  51.    changes on a request specific basis (i.e; the current time, the client's 
  52.    IP address, and output from INTERPRET SSIs).
  53.  
  54.  
  55. The basic notion behind the use of a cache is to reduce  processing
  56. requirements and bandwidth demands.  Proxy caches are highly effective at
  57. both -- when successful, no communication with the origin server is 
  58. necessary. The GoServe cache does not save bandwidth, but can reduce
  59. server load considerably (by skipping the "call the filter to resolve this
  60. request" step).  SREPROXY is similar -- although it is a filter that has
  61. to be called, it's much smaller and faster then the regular (SREFILTR) 
  62. filter.  Lastly, the SSI and !DIR caches can save a lot of processing for
  63. SSI-including and directory-listing "processor intensive" resources.
  64.  
  65.    
  66. Each of these caches has advantages and disadvantages. 
  67.  
  68.  Proxy Caches:
  69.     Advantages
  70.       * Very fast response times
  71.       * Can completely eliminate load on your server 
  72.       * Helps reduce internet traffic
  73.     Disadvantages
  74.       * Should not be used with actively changing, or access controlled,
  75.         resources
  76.       * Should not be used when accurate auditing is important
  77.  
  78.   GoServe Cache
  79.     Advantages:
  80.       * Response times are very fast (compared with SREFILTR)
  81.       * Minimizes load on your server 
  82.     Disadvantages:
  83.       * Should not be used with actively changing, or access controlled,
  84.         resources
  85.       * Currently, the GoServe cache is http/1.0, but not http/1.1,
  86.         compliant.
  87.  
  88.    SREPROXY cache:
  89.     Advantages:
  90.       * Response times are fast
  91.       * Can reduce load (since SREPROXY is smaller then SREFILTR)
  92.       * Can be used with changing and access controlled resources
  93.       * No loss of functionality -- when in doubt, SREFILTR is used
  94.     Disadvantages:
  95.       * Introduces another round of processing -- if a request does not
  96.         match a cached entry, the net result is to diminish response time.
  97.       * On occasion, a stale response may be returned 
  98.  
  99.     SSI and !DIR caches:
  100.       Advantages:
  101.         * Fully functional -- changes are immediately detected
  102.         * Greatly reduces processing for a subset of otherwise processing
  103.           intensive requests.
  104.       Disadvantages:
  105.         * On rare occassions, stale requests may be returned
  106.  
  107.  
  108. It should be stressed that these caches are not mutually exclusive.  In fact, 
  109. a typical scenario would have the three higher caches (proxy servers, GoServe, 
  110. and SREPROXY) examining a request, which may then be resolved via the use of   
  111. the SSI (or !DIR) cache.  Thus, optimal performance is acheived by using each   
  112. cache in a complementary fashion.
  113.  
  114. The following discusses some tricks and techniques you can use. In addition,
  115. the appendix discusses the "cache relevant" response headers used by SRE-http.
  116.  
  117. Proxy Servers:
  118.  
  119.   * If you have a very dynamic site of non-access controlled resources, 
  120.     transparency concerns may override the desire for faster throughput.
  121.     That is, you might want to suppress all proxy caching.
  122.     This can be accomplished by setting proxy_cache=0 (in INIT_STA.80)
  123.     Alternatively, you can use proxy_cache to "force revalidation."
  124.     See the appendix for more details, or  see the description of the 
  125.     PROXY_CACHE variable in INITFILT.DOC.
  126.  
  127.   * SRE-http will automatically supress proxy caching whenever access controls
  128.     (such as CHECKLOG and ALLOW_ACCESS), or dynamic SSIs, apply to the resource.  
  129.     If  desired, you can explicitily allow these resources to be cached -- just
  130.     include a CACHE (or CACHE*) "permission" in a selector-specific entry
  131.     in ACCESS.IN (or in ATTRIBS.CFG). Alternatively, resources listed 
  132.     as PUBLIC URLS (using PUBURLS.IN or ATTRIBS.CFG) are assumed to 
  133.     be cachable by proxy caches.
  134.  
  135.   * See HITMETER.DOC for hints on how to resolve problems associated
  136.     with accurate metering of hits when proxy servers may be active.
  137.  
  138. GoServe cache:
  139.    
  140.   * If you do enable the GoServe cache, be aware that it uses an http/1.0
  141.     response algorithim.  Thus, your site will sometimes return http/1.1
  142.     responses, and sometimes http/1.0 responses.  Although this is not
  143.     fatal, it may have strange impacts (and it's somewhat asthetically 
  144.     displeasing). 
  145.  
  146.     Therefore, SRE-http will only use the GoServe cache (that is, allow a
  147.     request to be cached by GoServe) when a CACHE* permission exists.
  148.  
  149.     Alternatively, resources listed as LITERAL_NORECORD PUBLIC URLS 
  150.     (in PUBLURL.IN) are assumed to be cachable by the GoServe cache.
  151.  
  152.    * In general, we recommend using the GoServe cache only for resources that
  153.      you do not care to audit (such as backgrounds and icons).  In this vein,
  154.      we recommend checking the "do not call filter" GoServe caching option.
  155.  
  156.    * Future releases of GoServe may upgrade the GoServe cache, so that it 
  157.      returns  appropriate http/1.1 response headers.
  158.  
  159.    * The GoServe cache ignores TE: request headers.
  160.  
  161. SREPROXY:
  162.  
  163.    * If your site is highly access controlled, or consists primarily of dynamic
  164.      HTML documents (with lots of SSIs') or addons/cgi-bin scripts, then use 
  165.      of SREPROXY may hurt (increase) response times.
  166.    * NUSTATUS contains an option that will display simple statistics on
  167.      the proportion of requests satisfied by SREPROXY.
  168.    * SREPROXY.DOC contains a detailed discussion on how to use SREPROXY.
  169.    * If SREPROXY detects a TE: GZIP request header, it will NOT resolve
  170.      the request.
  171.  
  172.  
  173. SSI and !DIR caches:
  174.  
  175.    * There is almost no reason not to use these caches....
  176.      the exceptions being:
  177.         i) You have lots of HTML documents, and not much extra disk space
  178.        ii) Your documents change rapidly (have lots of dynamic SSIs).
  179.       iii) HTML files are contantly being edited, added, and removed.
  180.  
  181.  
  182.  
  183.                         -----------------------------
  184.  
  185. Appendix: Cache relevant response headers used by SRE-http
  186.  
  187.  
  188. There are several ways to effect the "cache relevant" response headers returned
  189. by SRE-http:
  190.    a) the setting of the PROXY_CACHE variable (in INIT_STA.80)
  191.    b) the setting of the FIX_EXPIRE variable (in INITFILT.80)
  192.    c) the use of PUBLIC_URLS
  193.    d) the use of the NOCACHE, CACHE and CACHE* selector-specific permissions
  194.    e) the use of selector-specific advanced options to specify an explicit
  195.       response header.
  196.  
  197.    Note that these are used for "normal" responses -- cgi scripts and 
  198.    addons may override these rules, and provide their own headers.
  199.  
  200. This listing goes from general to more specific -- with the setting of PROXY_CACHE
  201. controlling default behavior, whearas specification of selector-specific
  202. advanced options can be used to override these defaults.
  203.  
  204.  
  205. I) PROXY_CAHCE:
  206.   PROXY_CACHE can take 4 basic values, which yields the following  
  207.   "default" response headers.
  208.  
  209.    0= disallow caching 
  210.       If this is a dynamic file (i.e.; contains dynamic ssi's)
  211.            Cache-control: no-cache
  212.       otherwise
  213.            Cache-control: private
  214.    1= allow caching
  215.            Cache-control: public
  216.  
  217.    2= allow caching, with revalidation
  218.            Cache-control: public,max-age=0
  219.       If this is a dynamic resource (i.e.; an HTML document with SSIs),
  220.       the following "stronger form" is used instead:
  221.            Cache-control: public,max-age=0, must-revalidate
  222.  
  223.    3=  allow proxy caching with revalidation, full caching by private caches
  224.        (private caches include the "browser's cache")
  225.            Cache-control:public,s-maxage=0
  226.  
  227. I.1) A modification: If PROXY_CACHE=n_mmmmm, where n=0,1,2, or 3, and mmm is
  228.     a integer number of seconds, then the following modifications occur:
  229.       1:    Cache-control: public,max-age=mmmmm
  230.       2:    Cache-control: public,max-age=mmmmm,   or
  231.             Cache-control: public,max-age=mmmmm, must-revalidate
  232.       3:    Cache-control:public,s-maxage=mmmmm
  233.  
  234. II) PUBLIC_URL
  235.   
  236.    If this selector is a "PUBLIC_URL" (i.e.; belongs to a PUBLIC realm, as
  237.    specified in ATTRIBS.CFG), then rule I is ignored. Instead:
  238.        Cache-control: public,s-maxage=mmmmm
  239.    where mmmmm either is 0, or the mmmmm value from the proxy_cache variable.
  240.     
  241. II.1) A Modification: If the PUBLIC_URL is a "literal" public_url, then 
  242.       use the following "re-validate in 1 day" header:
  243.         Cache-control: public, max-age=86400
  244.  
  245. III) If a NOCACHE, CACHE or CACHE* permission is used, then the I and II
  246.      rules are ignored. Instead, use the following:
  247.     
  248.      NOCACHE: use
  249.         Cache-control: no-cache
  250.         Pragma: nocache
  251.  
  252.     CACHE:  use 
  253.        Cache-control: public,s-maxage=mmmmm  
  254.           (mmmmm is from proxy_cache)
  255.         
  256.     CACHE*: use 
  257.        Cache-control: public
  258.    
  259.    Note:
  260.       *  only one of these should be specified. Should a mistake occur, with
  261.          more then one specified, then  NOCACHE overrides CACHE*, and CACHE* 
  262.          overrides CACHE.   
  263.  
  264.  
  265. IV) FIX_EXPIRE
  266.  
  267.    If Fix_expire is specified, and this is a "dynamic" response, then 
  268.           Expires: current_time+fix_expire
  269.    is also added.
  270.    if FIX_EXPIRE is not specified, and either
  271.          i) PROXY_CACHE=0,2 or 3
  272.         ii) a NOCACHE permission is specified
  273.    then
  274.            Expires: current_time
  275.    is also added.
  276.    Note that using "Expires: current_time" implies "immediate expiration"
  277.  
  278.  
  279. V) Advanced options
  280.  
  281.    If you specify a header as a "selector specific" advanced option, then 
  282.    the matching header will be suppressed, and the header you specify will be 
  283.    used instead. 
  284.    This allows you to fine tune your "cache relevant" response headers.
  285.  
  286.    For example:
  287.      Header add Cache-control: public,max-age=100000
  288.      means: 
  289.              "ignore rules I,II, and III; and use 
  290.              Cache-control: public, max-age=100000"
  291.  
  292.      Header add Expire: Mon, 20 June 1998 10:11:12 GMT
  293.      means:
  294.         "ignore rule IV, and use"
  295.              Expires: Mon, 20 June 1998 10:11:12 GMT
  296.         (a date in the past means "immediate expiriation")
  297.  
  298. Notes:
  299.    * Summarizing the more important Cache-control directives:
  300.               
  301.        NO-CACHE: never cache this response
  302.        PUBLIC: this can be cached in a public place (a proxy server cache)
  303.        PRIVATE: this can be cached by user-agents, or other "client side"
  304.                 caches
  305.        MAX-AGE: after this response is this many seconds old, all caches 
  306.                 must re-validate
  307.        S-MAXAGE: after this response is this many seconds old, proxy (non-
  308.                  private) caches must re-validate this response. Private
  309.                  caches can ignore this directive.
  310.       MUST-REVALIDATE: a strong re-validation (discourages caches from
  311.                        tolerating stale responses)
  312.  
  313.     Revalidation typically means sending a If-modified-since
  314.     request to the origin server; which SRE-http can quickly
  315.     answer if there has been on change.
  316.  
  317.     For further details, please see the http/1.1 specification
  318.  
  319.   *  http/1.1 proxies will always use a Cache-control: response header instead
  320.      of an expires: response header.  http/1.0 proxies will typically
  321.      ignore a cache-control response header.
  322.  
  323.   *  resources subject to content negotatiation will often add a Vary: header.
  324.      The Vary header lists the request headers that MUST match (in addition
  325.      to the URI); such as the Accept and  Accept-Language request headers.
  326.  
  327.  
  328.