amount of unnecessary network traffic and latency.

   This design introduces one new "Meter" header, which is used both in
   HTTP request messages and HTTP response messages.  The Meter header
   is used to transmit a number of directives and reports.  In
   particular, all negotiation of the use of hit-metering and usage
   limits is done using this header.  No other changes to the existing
   HTTP/1.1 specification [4] are proposed in this document.

   This design also introduces several new concepts:

      1. The concepts of a "use" of a cache entry, which is when a
         proxy returns its entity-body in response to a conditional
         or non-conditional request, and the "reuse" of a cache
         entry, which is when a proxy returns a 304 (Not Modified)
         response to a conditional request which is satisfied by
         that cache entry.

      2. The concept of a hit-metered resource, for which proxy
         caches make a best-effort attempt to report accurate
         counts of uses and/or reuses to the origin server.

      3. The concept of a usage-limited resource, for which the
         origin server expects proxy caches to limit the number of
         uses and/or reuses.

   The new Meter directives and reports interact to allow proxy caches
   and servers to cooperate in the collection of demographic data.  The
   goal is a best-efforts approximation of the true number of uses
   and/or reuses, not a guaranteed exact count.








 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   The new Meter directives also allow a server to bound the inaccuracy
   of a particular hit-count, by bounding the number of uses between
   reports.  It can also, for example, bound the number of times the
   same ad is shown because of caching.

   Section 7.1 describes a way to use server-driven content negotiation
   (the Vary header) that allows an HTTP origin server to flexibly
   separate requests into categories and count requests by category.
   Implementation of such a categorized hit counting is likely to be a
   very small modification to most implementations of Vary; some
   implementations may not require any modification at all.

2.1 Discussion

   Mapping this onto the publishing model, a proxy cache would increment
   the use-count for a cache entry once for each unconditional GET done
   for the entry, and once for each conditional GET that results in
   sending a copy of the entry to update a client's invalid cached copy.
   Conditional GETs that result in 304 (Not Modified) are not included
   in the use-count, because they do not result in a new user seeing the
   page, but instead signify a repeat view by a user that had seen it
   before.  However, 304 responses are counted in the reuse-count.
   HEADs are not counted at all, because their responses do not contain
   an entity-body.

   The Meter directives apply only to shared proxy caches, not to end-
   client (or other single-user) caches.  Single user caches should not
   use Meter, because their hits will be automatically counted as a
   result of the unconditional GET with which they first fetch the page,
   from either the origin-server or from a proxy cache.  Their
   subsequent conditional GETs do not result in a new user seeing the
   page.

   The mechanism specified here counts GETs; other methods either do not
   result in a page for the user to read, aren't cached, or are
   "written-through" and so can be directly counted by the origin
   server. (If, in the future, a "cachable POST" came into existence,
   whereby the entity-body in the POST request was used to select a
   cached response, then such POSTs would have to be treated just like
   GETs.)  The applicability of hit-metering to any new HTTP methods
   that might be defined in the future is currently unspecifiable.

   In the case of multiple caches along a path, a proxy cache does the
   obvious summation when it receives a use-count or reuse-count in a
   request from another cache.







 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


3 Design concepts