Note: please remember that hit-counts and usage-counts are
      associated with individual responses, not with resources.  A cache
      entry that, over its lifetime, holds more than one response is
      also not a "response", in this particular sense.

   Let R be a cached response, and V be the value of the Request-URI and
   selecting request-headers (if any, see section 14.43 of the HTTP/1.1
   specification [4]) that would select R if contained in a request.  We
   define a "use" of R as occurring when the proxy returns its stored
   copy of R in a response with any of the following status codes: a 200
   (OK) status; a 203 (Non-Authoritative Information) status; or a 206
   (Partial Content) status when the response contains byte #0 of the
   entity (see section 5.4 for a discussion of Range requests).

      Note: when a proxy forwards a client's request and receives a
      response, the response that the proxy sends immediately to the
      requesting client is not counted as a "use".  I.e., the reported
      count is the number of times the cache entry was used, and not the
      number of times that the response was used.

   We define a "reuse" of R as as occurring when the proxy responds to a
   request selecting R with a 304 (Not Modified) status, unless that
   request is a Range request that does not specify byte #0 of the
   entity.

5.3.1 Counting rules for hit-metering

   A proxy participating in hit-metering for a cache response R
   maintains two counters, CU and CR, associated with R. When a proxy
   first stores R in its cache, it sets both CU and CR to 0 (zero).
   When a subsequent client request results in a "use" of R, the proxy
   increments CU.  When a subsequent client request results in a "reuse"
   of R, the proxy increments CR.  When a subsequent client request
   selecting R (i.e., including V) includes a "count" Meter directive,
   the proxy increments CU and CR using the corresponding values in the
   directive.

   When the proxy sends a request selecting R (i.e., including V) to the
   inbound server, it includes a "count" Meter directive with the
   current CU and CR as the parameter values.  If this request was
   caused by the proxy's receipt of a request from a client, upon
   receipt of the server's response, the proxy sets CU and CR to the




 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   number of uses and reuses, respectively, that may have occurred while
   the request was in progress.  (These numbers are likely, but not
   certain, to be zero.)  If the proxy's request was a final HEAD-based
   report, it need no longer maintain the CU and CR values, but it may
   also set them to the number of intervening uses and reuses and retain
   them.

5.3.2 Counting rules for usage-limiting

   A proxy participating in usage-limiting for a response R maintains
   either or both of two counters TU and TR, as appropriate, for that
   resource.  TU and TR are incremented in just the same way as CU and
   CR, respectively.  However, TU is zeroed only upon receipt of a
   "max-uses" Meter directive for that response (including the initial
   receipt).  Similarly, TR is zeroed only upon receipt of a "max-
   reuses" Meter directive for that response.

   A proxy participating in usage-limiting for a response R also stores
   values MU and/or MR associated with R. When it receives a response
   including only a max-uses value, it sets MU to that value and MR to
   infinity.  When it receives a response including only a max-reuses
   value, it sets MR to that value and MU to infinity.  When it receives
   a response including both max-reuses and max-reuses values, it sets
   MU and MR to those values, respectively.  When it receives a
   subsequent response including neither max-reuses nor max-reuses
   values, it sets both MU and MR to infinity.

   If a proxy participating in usage-limiting for a response R receives
   a request that would cause a "use" of R, and TU >= MU, it MUST
   forward the request to the server.  If it receives a request that
   would cause a "reuse" of R, and TR >= MR, it MUST forward the request
   to the server.  If (in either case) the proxy has already forwarded a
   previous request to the server and is waiting for the response, it
   should delay further handling of the new request until the response
   arrives (or times out); it SHOULD NOT have two revalidation requests
   pending at once that select the same response, unless these are Range
   requests selecting different subranges.

   There is a special case of this rule for the "max-uses" directive: if
   the proxy receives a response with "max-uses=0" and does not forward
   it to a requesting client, the proxy should set a flag PF associated
   with R. If R is true, then when a request arrives while if TU >= MU,
   if the PF flag is set, then the request need not be forwarded to the
   server (provided that this is not required by other caching rules).
   However, the PF flag MUST be cleared on any use of the response.