Cache-control: max-age=3600
       Connection: meter
       Etag: "abcde"
       Expires: Sun, 06 Nov 1994 08:49:37 GMT
       Meter:u=3,r=6,e

7 Interactions with content negotiation

   This section describes two aspects of the interaction between hit-
   metering and "content-negotiated" resources:

      1. treatment of responses carrying a Vary header (section
         7.1).

      2. treatment of responses that use the proposed Transparent
         Content Negotiation mechanism (section 7.2).

7.1 Treatment of responses carrying a Vary header

   Separate counts should be kept for each combination of the headers
   named in the Vary header for the Request-URI (what [4] calls "the
   selecting request-headers"), even if they map to the same entity-tag.
   This rule has the effect of counting hits on each variant, if there
   are multiple variants of a page available.

      Note: This interaction between Vary and the hit-counting
      directives allows the origin server a lot of flexibility in
      specifying how hits should be counted.  In essence, the origin
      server uses the Vary mechanism to divide the requests for a
      resource into arbitrary categories, based on the request- headers.
      (We will call these categories "request-patterns".) Since a proxy
      keeps its hit-counts for each request-pattern, rather than for
      each resource, the origin server can obtain separate statistics
      for many aspects of an HTTP request.




 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   For example, if a page varied based on the value of the User-Agent
   header in the requests, then hit counts would be kept for each
   different flavor of browser. But it is in fact more general than
   that; because multiple header combinations can map to the same
   variant, it also enables the origin server to count the number of
   times (e.g.) the Swahili version of a page was requested, even though
   it is only available in English.

   If a proxy does not support the Vary mechanism, then [4] says that it
   MUST NOT cache any response that carries a Vary header, and hence
   need not implement any aspect of this hit-counting or usage-limiting
   design for varying resources.

       Note: this also implies that if a proxy supports the Vary
       mechanism but is not willing to maintain independent hit-counts
       for each variant response in its cache, then it must follow at
       least one of these rules:

          1. It must not use the Meter header in a request to offer
             to hit-meter or usage-limit responses.

          2. If it does offer to hit-meter or usage-limit responses,
             and then receives a response that includes both a Vary
             header and a Meter header with a directive that it
             cannot satisfy, then the proxy must not cache the
             response.

       In other words, a proxy is allowed to partially implement the
       Vary mechanism with respect to hit-metering, as long as this has
       no externally visible effect on its ability to comply with the
       Meter specification.

   This approach works for counting almost any aspect of the request
   stream, without embedding any specific list of countable aspects in
   the specification or proxy implementation.

7.2 Interaction with Transparent Content Negotiation

   [A description of the interaction between this design and the
   proposed Transparent Content Negotiation (TCN) design [6] will be
   made available in a later document.]

8 A Note on Capturing Referrals

   It is alleged that some advertisers want to pay content providers,
   not by the "hit", but by the "nibble" -- the number of people who
   actually click on the ad to get more information.





 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   Now, HTTP already has a mechanism for doing this: the "Referer"
   header. However, perhaps it ought to be disabled for privacy reasons