RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      Note: the "PF" flag is so named because this feature is useful
      only for caches that could issue a "prefetch" request before an
      actual client request for the response.  A proxy not implementing
      prefetching need not implement the PF flag.

5.3.3 Equivalent algorithms are allowed

   Any other algorithm that exhibits the same external behavior (i.e.,
   generates exactly the same requests from the proxy to the server) as
   the one in this section is explicitly allowed.

      Note: in most cases, TU will be equal to CU, and TR will be
      equal to CR.  The only two cases where they could differ are:

         1. The proxy issues a non-conditional request for the
            resource using V, while TU and/or TR are non-zero, and
            the server's response includes a new "max-uses" and/or
            "max-reuses" directive (thus zeroing TU and/or TR, but
            not CU and CR).

         2. The proxy issues a conditional request reporting the
            hit-counts (and thus zeroing CU and CR, but not TU or
            TR), but the server's response does not include a new
            "max-uses" and/or "max-reuses" directive.

      To solve the first case, the proxy has several implementation
      options

         - Always store TU and TR separately from CU and CR.

         - Create "shadow" copies of TU and TR when this situation
           arises (analogous to "copy on write").

         - Generate a HEAD-based usage report when the
           non-conditional request is sent (or when the
           "max-uses=0" is received), causing CU and CR to be
           zeroed (analogous in some ways to a "memory barrier"
           instruction).

      In the second case, the server implicitly has removed the
      usage-limit(s) on the response (by setting MU and/or MR to
      infinity), and so the fact that, say, TU is different from CU
      is not significant.

      Note: It may also be possible to eliminate the PF flag by
      sending extra HEAD-based usage-report requests, but we
      recommend against this; it is better to allocate an extra bit
      per entry than to transmit extra requests.




 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


5.4 Counting rules: interaction with Range requests


   HTTP/1.1 allows a client to request sub-ranges of a resource.  A
   client might end up issuing several requests with the net effect of
   receiving one copy of the resource.  For uniformity of the results
   seen by origin servers, proxies need to observe a rule for counting
   these references, although it is not clear that one rule generates
   accurate results in every case.

   The rule established in this specification is that proxies count as a
   "use" or "reuse" only those Range requests that result in the return
   of byte #0 of the resource.  The rationale for this rule is that in
   almost every case, an end-client will retrieve the beginning of any
   resource that it references at all, and that it will seldom retrieve
   any portion more than once.  Therefore, this rule appears to meet the
   goal of a "best-efforts" approximation.

5.5 Implementation by non-caching proxies

   A non-caching proxy may participate in the metering subtree; this is
   strongly recommended.

   A non-caching proxy (HTTP/1.1 or higher) that participates in the
   metering subtree SHOULD forward Meter headers on both requests and
   responses, with the appropriate Connection headers.

   If a non-caching proxy forwards Meter headers, it MUST comply with
   these restrictions:

      1. If the proxy forwards Meter headers in responses, such a
         response MUST NOT be returned to any request except the
         one that elicited it.

      2. Once a non-caching proxy starts forwarding Meter headers,
         it should not arbitrarily stop forwarding them (or else
         reports may be lost).