but simply to collect demographic information.  Some cache-busting is
   also done to provide different advertising images to appear on the
   same page (i.e., each retrieval of the page sees a different ad).

   This proposal supports a model similar to that of publishers of
   hard-copy publications: such publishers (try to) report to their
   advertisers how many people read an issue of a publication at least
   once; they don't (try to) report how many times a reader re-reads an
   issue. They do this by counting copies published, and then try to
   estimate, for their publication, on average how many people read a




 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   single copy at least once. The key point is that the results aren't
   exact, but are still useful. Another model is that of coding
   inquiries in such a way that the advertiser can tell which
   publication produced the inquiry.

1.1 Goals, non-goals, and limitations

   HTTP/1.1 already allows origin servers to prevent caching of
   responses, and evidence exists [9] that at least some of the time,
   this is being done for the sole purpose of collecting counts of the
   number of accesses of specific pages.  Some of this evidence is
   inferred from the study of proxy traces; some is based on explicit
   statements of the intention of the operators of Web servers.
   Information collected this way might or might not be of actual use to
   the people who collect it; the fact is that they want to collect it,
   or already do so.

   The goal of this proposal is to provide an optional performance
   optimization for this use of HTTP/1.1.

   This specification is:

      - Optional: no server or proxy is required to implement it.

      - Proxy-centered: there is no involvement on the part of
        end-client implementations.

      - Solely a performance optimization: it provides no
        information or functionality that is not already available
        in HTTP/1.1.  The intent is to improve performance overall,
        and reduce latency for almost all interactions; latency
        might be increased for a small fraction of HTTP
        interactions.

      - Best-efforts: it does not guarantee the accuracy of the
        reported information, although it does provide accurate
        results in the absence of persistent network failures or
        host crashes.

      - Neutral with respect to privacy: it reveals to servers no
        information about clients that is not already available
        through the existing features of HTTP/1.1.

   The goals of this specification do not include:

      - Solving the entire problem of efficiently obtaining
        extensive information about requests made via proxies.





 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      - Improving the protection of user privacy (although our
        proposal may reduce the transfer of user-specific
        information to servers, it does not prevent it).

      - Preventing or encouraging the use of log-exchange
        mechanisms.

      - Avoiding all forms of "cache-busting", or even all
        cache-busting done for gathering counts.

   This design has certain potential limitations:

      - If it is not deployed widely in both proxies and servers,
        it will provide little benefit.

      - It may, by partially solving the hit-counting problem,
        reduce the pressure to adopt more complete solutions, if
        any become available.

      - Even if widely deployed, it might not be widely used, and
        so might not significantly improve performance.

   These potential limitations might not be problems in actual practice.

1.2 Brief summary of the design