In order to allow the introduction of hit-metering and usage-limiting
   without requiring a protocol revision, and to ensure a reasonably
   close approximation of accurate counts, the negotiation of metering
   and usage-limiting is done hop-by-hop, not end-to-end.  If one
   considers the "tree" of proxies that receive, store, and forward a
   specific response, the intent of this design is that within some
   (possibly null) "metering subtree", rooted at the origin server, all
   proxies are using the hit-metering and/or usage-limiting requested by
   the origin server.

   Proxies at the leaves of this subtree will insert a "Cache-control:
   s-maxage=0" directive, which forces all other proxies (below this
   subtree) to check with a leaf of the metering subtree on every
   request.  However, it does not prevent them from storing and using
   the response, if the revalidation succeeds.

   No proxy is required to implement hit-metering or usage-limiting.
   However, any proxy that transmits the Meter header in a request MUST
   implement every unconditional requirement of this specification,
   without exception or amendment.

   This is a conservative design, which may sometimes fail to take
   advantage of hit-metering support in proxies outside the metering
   subtree.  However, it is likely that without the reliability offered
   by a conservative design, managers of origin servers with
   requirements for accurate approximations will not take advantage of
   any hit-metering proposal.

   The hit-metering/usage-limiting mechanism is designed to avoid any
   extra network round-trips in the critical path of any client request,
   and (as much as possible) to avoid excessively lengthening HTTP
   messages.

   The Meter header is used to transmit both negotiation information and
   numeric information.

   A formal specification for the Meter header appears in section 5; the
   following discussion uses an informal approach to improve clarity.

3.1 Implementation of the "metering subtree"

   The "metering subtree" approach is implemented in a simple,
   straightforward way by defining the new "Meter" header as one that
   MUST always be protected by a Connection header in every request or
   response.  I.e., if the Meter header is present in an HTTP message,
   that message:




 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      1. MUST contain "Connection: meter", and MUST be handled
         according to the HTTP/1.1 specification of the Connection
         header.

      2. MUST NOT be sent in response to a request from a client
         whose version number is less than HTTP/1.1.

      3. MUST NOT be accepted from a client whose version number is
         less than HTTP/1.1.

   The reason for the latter two restrictions is to protect against
   proxies that might not properly implement the Connection header.
   Otherwise, a subtree that includes an HTTP/1.0 proxy might
   erroneously appear to be a metering subtree.

      Note: It appears that for the Connection header mechanism to
      function correctly, a system receiving an HTTP/1.0 (or lower-
      version) message that includes a Connection header must act as if
      this header, and all of the headers it protects, ought to have
      been removed from the message by an intermediate proxy.

      Although RFC2068 does not specifically require this behavior, it
      appears to be implied.  Otherwise, one could not depend on the
      stated property (section 14.10) that the protected options "MUST
      NOT be communicated by proxies over further connections."  This
      should probably be clarified in a subsequent draft of the HTTP/1.1
      specification.

      This specification does not, in any way, propose a modification of
      the specification of the Connection header.

   From the point of view of an origin server, the proxies in a metering
   subtree work together to obey usage limits and to maintain accurate
   usage counts.  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.  Similarly, when a proxy in the
   subtree receives a usage report, it ensures that the hits represented
   by this report are summed properly and reported to the origin server.

   When a proxy forwards a hit-metered or usage-limited response to a
   client (proxy or end-client) not in the metering subtree, it MUST
   omit the Meter header, and it MUST add "Cache-control: s-maxage=0" to
   the response.