2. When it forwards a conditional HEAD on the resource
         instance on behalf of one of its clients.

      3. When it must generate a conditional GET to satisfy a
         client request because the max-uses limit has been
         exceeded.

      4. Upon expiration of a metering timeout associated with a
         cache entry that has a non-zero hit-count.

      5. When it removes the corresponding non-zero hit-count entry
         from its storage for any reason including:

            - the proxy needs the storage space for another
              hit-count entry.

            - the proxy is not able to store more than one response
              per resource, and a request forwarded on behalf of a
              client has resulted in the receipt of a new response
              (one with a different entity-tag or last-modified
              time).

         Note that a cache might continue to store hit-count information
         even after having deleted the body of the response, so it is
         not necessary to report the hit-count when deleting the body;
         it is only necessary to report it if the proxy is about to
         "forget" a non-zero value.

   (Section 5.3 explains how hit-counts become zero or non-zero.)

   If the usage report is being sent because the proxy is about to
   remove the hit-count entry from its storage, or because of an expired
   metering timeout:

      - The proxy MUST send the report as part of a conditional
        HEAD request on the resource instance.






 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      - The proxy is not required to retry the HEAD request if it
        fails (this is a best-efforts design).  To improve
        accuracy, however, the proxy SHOULD retry failed HEAD
        requests, subject to resource constraints.

      - The proxy is not required to serialize any other operation
        on the completion of this request.

      Note: proxy implementors are strongly encouraged to batch several
      HEAD-based reports to the same server, when possible, over a
      single persistent connection, to reduce network overhead as much
      as possible.  This may involve a non-naive algorithm for
      scheduling the deletion of hit-count entries.

   If the usage count is sent because of an arriving request that also
   carries a "count" directive, the proxy MUST combine its own (possibly
   zero) use and reuse counts with the arriving counts, and then attempt
   to forward the request.

   However, the proxy is not required to forward an arriving request
   with a "count" directive, provided that:

      - it can reply to the request using a cached response, in
        compliance with other requirements of the HTTP
        specification.

      - such a response does not exceed a max-uses limit.

      - it is not required to forward the request because of an
        expired metering timeout.

   If an arriving request carries a "count" directive, and the proxy no
   longer has a cache entry for the resource, the proxy MUST forward the
   "count" directive.  (This is, in any case, what a proxy without a
   suitable cache entry would normally do for any valid request it
   receives.)

3.6 Subdivision of usage-limits

   When an origin server specifies a usage limit, a proxy in the
   metering subtree may subdivide this limit among its children in the
   subtree as it sees fit.

   For example, consider the situation with two proxies P1 and P2, each
   of which uses proxy P3 as a way to reach origin server S. Imagine
   that S sends P3 a response with






 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997