This section is included for people not wishing to read the entire
   document; it is not a specification for the proposed design, and
   over-simplifies many aspects of the design.

   The goal of this design is to eliminate the need for origin servers
   to use "cache-busting" techniques, when this is done just for the
   purpose of counting the number of users of a resource.  (Cache-
   busting includes techniques such as setting immediate Expiration
   dates, or sending "Cache-control:  private" in each response.)

   The design adds a new "Meter" header to HTTP; the header is always
   protected by the "Connection" header, and so is always hop-by-hop.
   This mechanism allows the construction of a "metering subtree", which
   is a connected subtree of proxies, rooted at an origin server.  Only
   those proxies that explicitly volunteer to join in the metering
   subtree for a resource participate in hit-metering, but those proxies
   that do volunteer are required to make their best effort to provide
   accurate counts.  When a hit-metered response is forwarded outside of
   the metering subtree, the forwarding proxy adds "Cache-control: s-
   maxage=0", so that other proxies (outside the metering subtree) are
   forced to forward all requests to a server in the metering subtree.





 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      NOTE: the HTTP/1.1 specification does not currently define a "s-
      maxage" Cache-control directive.  The HTTP working group has
      decided to add such a directive to the next revision of the
      HTTP/1.1 specification [7].

   The Meter header carries zero or more directives, similar to the way
   that the Cache-control header carries directives.  Proxies may use
   certain Meter directives to volunteer to do hit-metering for a
   resource.  If a proxy does volunteer, the server may use certain
   directives to require that a response be hit-metered.  Finally,
   proxies use a "count" Meter directive to report the accumulated hit
   counts.

   The Meter mechanism can also be used by a server to limit the number
   of uses that a cache may make of a cached response, before
   revalidating it.

   The full specification includes complete rules for counting "uses" of
   a response (e.g., non-conditional GETs) and "reuses" (conditional
   GETs).  These rules ensure that the results are entirely consistent
   in all cases, except when systems or networks fail.

1.3 Terminology

   This document uses terms defined and explained in the HTTP/1.1
   specification [4], including "origin server," "resource," "hop-by-
   hop," "unconditional GET," and "conditional GET."  The reader is
   expected to be familiar with the HTTP/1.1 specification and its
   terminology.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in RFC 2119 [1].

2 Overview

   The design described in this document introduces several new features
   to HTTP:

      - Hit-metering: allows an origin server to obtain reasonably
        accurate counts of the number of clients using a resource
        instance via a proxy cache, or a hierarchy of proxy caches.

      - Usage-limiting: allows an origin server to control the
        number of times a cached response may be used by a proxy
        cache, or a hierarchy of proxy caches, before revalidation
        with the origin server.





 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   These new non-mandatory features require minimal new protocol
   support, no change in protocol version, relatively little overhead in
   message headers.  The design adds no additional network round-trips
   in any critical path that directly affects user-perceived latency
   (see section 4.3 for an analysis).

   The primary goal of hit-metering and usage-limiting is to obviate the
   need for an origin server to send "Cache-control: s-maxage=0" with
   responses for resources whose value is not likely to change
   immediately.  In other words, in cases where the only reason for
   contacting the origin server on every request that might otherwise be
   satisfied by a proxy cache entry is to allow the server to collect
   demographic information or to control the number of times a cache
   entry is used, the extension proposed here will avoid a significant